🥇 সাবলীল: কেন আউটপুট বাফার কনফিগার করা গুরুত্বপূর্ণ

আজকাল, ELK স্ট্যাক ছাড়া একটি Kubernetes-ভিত্তিক প্রকল্প কল্পনা করা অসম্ভব, যা ক্লাস্টারের উভয় অ্যাপ্লিকেশন এবং সিস্টেম উপাদানগুলির লগ সংরক্ষণ করে। আমাদের অনুশীলনে, আমরা Logstash এর পরিবর্তে Fluentd এর সাথে EFK স্ট্যাক ব্যবহার করি।

Fluentd হল একটি আধুনিক, সার্বজনীন লগ সংগ্রাহক যেটি আরও বেশি জনপ্রিয়তা অর্জন করছে এবং ক্লাউড নেটিভ কম্পিউটিং ফাউন্ডেশনে যোগদান করেছে, যে কারণে এটির বিকাশ ভেক্টরটি কুবারনেটসের সাথে একত্রে ব্যবহারের উপর দৃষ্টি নিবদ্ধ করে।

Logstash এর পরিবর্তে Fluentd ব্যবহার করার বিষয়টি সফ্টওয়্যার প্যাকেজের সাধারণ সারমর্মকে পরিবর্তন করে না, তবে, Fluentd এর বহুমুখীতার ফলে এর নিজস্ব নির্দিষ্ট সূক্ষ্মতা দ্বারা চিহ্নিত করা হয়।

উদাহরণস্বরূপ, যখন আমরা একটি ব্যস্ত প্রজেক্টে লগিংয়ের উচ্চ তীব্রতার সাথে EFK ব্যবহার করা শুরু করি, তখন আমরা এই সত্যের মুখোমুখি হয়েছিলাম যে কিবানাতে কিছু বার্তা বারবার বহুবার প্রদর্শিত হয়েছিল। এই প্রবন্ধে আমরা আপনাকে বলব কেন এই ঘটনাটি ঘটে এবং কীভাবে সমস্যাটি সমাধান করা যায়।

নথির নকলের সমস্যা

আমাদের প্রকল্পগুলিতে, Fluentd একটি ডেমনসেট হিসাবে মোতায়েন করা হয় (কুবারনেটস ক্লাস্টারের প্রতিটি নোডে একটি উদাহরণে স্বয়ংক্রিয়ভাবে চালু হয়) এবং /var/log/containers-এ stdout কন্টেইনার লগগুলি পর্যবেক্ষণ করে। সংগ্রহ এবং প্রক্রিয়াকরণের পরে, JSON নথির আকারে লগগুলি ইলাস্টিকসার্চে পাঠানো হয়, ক্লাস্টার বা স্বতন্ত্র আকারে উত্থাপিত হয়, প্রকল্পের স্কেল এবং কার্যকারিতা এবং ত্রুটি সহনশীলতার প্রয়োজনীয়তার উপর নির্ভর করে। কিবানা গ্রাফিকাল ইন্টারফেস হিসাবে ব্যবহৃত হয়।

একটি আউটপুট বাফারিং প্লাগইন সহ Fluentd ব্যবহার করার সময়, আমরা এমন একটি পরিস্থিতির সম্মুখীন হয়েছিলাম যেখানে ইলাস্টিক সার্চের কিছু নথিতে হুবহু একই বিষয়বস্তু ছিল এবং শুধুমাত্র শনাক্তকারীর মধ্যে পার্থক্য ছিল৷ আপনি একটি উদাহরণ হিসাবে Nginx লগ ব্যবহার করে এটি একটি বার্তা পুনরাবৃত্তি যাচাই করতে পারেন। লগ ফাইলে, এই বার্তাটি একটি একক অনুলিপিতে বিদ্যমান:

127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -

যাইহোক, ইলাস্টিক সার্চে বেশ কিছু নথি রয়েছে যাতে এই বার্তাটি রয়েছে:

{
  "_index": "test-custom-prod-example-2020.01.02",
  "_type": "_doc",
  "_id": "HgGl_nIBR8C-2_33RlQV",
  "_version": 1,
  "_score": 0,
  "_source": {
    "service": "test-custom-prod-example",
    "container_name": "nginx",
    "namespace": "test-prod",
    "@timestamp": "2020-01-14T05:29:47.599052886 00:00",
    "log": "127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00  0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -",
    "tag": "custom-log"
  }
}

{
  "_index": "test-custom-prod-example-2020.01.02",
  "_type": "_doc",
  "_id": "IgGm_nIBR8C-2_33e2ST",
  "_version": 1,
  "_score": 0,
  "_source": {
    "service": "test-custom-prod-example",
    "container_name": "nginx",
    "namespace": "test-prod",
    "@timestamp": "2020-01-14T05:29:47.599052886 00:00",
    "log": "127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00  0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -",
    "tag": "custom-log"
  }
}

তাছাড়া দুইটির বেশি পুনরাবৃত্তি হতে পারে।

Fluentd লগগুলিতে এই সমস্যার সমাধান করার সময়, আপনি নিম্নলিখিত বিষয়বস্তু সহ প্রচুর সংখ্যক সতর্কতা দেখতে পাবেন:

2020-01-16 01:46:46 +0000 [warn]: [test-prod] failed to flush the buffer. retry_time=4 next_retry_seconds=2020-01-16 01:46:53 +0000 chunk="59c37fc3fb320608692c352802b973ce" error_class=Fluent::Plugin::ElasticsearchOutput::RecoverableRequestFailure error="could not push logs to Elasticsearch cluster ({:host=>"elasticsearch", :port=>9200, :scheme=>"http", :user=>"elastic", :password=>"obfuscated"}): read timeout reached"

এই সতর্কতাগুলি ঘটে যখন ইলাস্টিক সার্চ অনুরোধ_টাইমআউট প্যারামিটার দ্বারা নির্দিষ্ট সময়ের মধ্যে একটি অনুরোধের উত্তর দিতে পারে না, যে কারণে ফরোয়ার্ড করা বাফার খণ্ডটি সাফ করা যায় না। এর পরে, Fluentd আবার ইলাস্টিক সার্চে বাফার ফ্র্যাগমেন্ট পাঠানোর চেষ্টা করে এবং নির্বিচারে সংখ্যক প্রচেষ্টার পরে, অপারেশনটি সফলভাবে সম্পন্ন হয়:

2020-01-16 01:47:05 +0000 [warn]: [test-prod] retry succeeded. chunk_id="59c37fc3fb320608692c352802b973ce" 
2020-01-16 01:47:05 +0000 [warn]: [test-prod] retry succeeded. chunk_id="59c37fad241ab300518b936e27200747" 
2020-01-16 01:47:05 +0000 [warn]: [test-dev] retry succeeded. chunk_id="59c37fc11f7ab707ca5de72a88321cc2" 
2020-01-16 01:47:05 +0000 [warn]: [test-dev] retry succeeded. chunk_id="59c37fb5adb70c06e649d8c108318c9b" 
2020-01-16 01:47:15 +0000 [warn]: [kube-system] retry succeeded. chunk_id="59c37f63a9046e6dff7e9987729be66f"

যাইহোক, ইলাস্টিক সার্চ প্রতিটি স্থানান্তরিত বাফার খণ্ডকে অনন্য হিসাবে বিবেচনা করে এবং সূচীকরণের সময় তাদের অনন্য _id ক্ষেত্রের মান নির্ধারণ করে। এভাবেই মেসেজের কপি দেখা যায়।

কিবানায় এটি এইরকম দেখায়:

সম্ভাষণ

এই সমস্যা সমাধানের জন্য বিভিন্ন বিকল্প আছে। তাদের মধ্যে একটি হল প্রতিটি নথির জন্য একটি অনন্য হ্যাশ তৈরি করার জন্য ফ্লুয়েন্ট-প্লাগইন-ইলাস্টিকসার্চ প্লাগইনের মধ্যে তৈরি মেকানিজম। আপনি যদি এই পদ্ধতিটি ব্যবহার করেন, ইলাস্টিকসার্চ ফরওয়ার্ডিং পর্যায়ে পুনরাবৃত্তিগুলি সনাক্ত করবে এবং নকল নথিগুলিকে প্রতিরোধ করবে। কিন্তু আমাদের অবশ্যই বিবেচনায় নিতে হবে যে সমস্যা সমাধানের এই পদ্ধতিটি তদন্তের সাথে লড়াই করে এবং সময়সীমার অভাবের সাথে ত্রুটিটি দূর করে না, তাই আমরা এটির ব্যবহার পরিত্যাগ করেছি।

স্বল্প-মেয়াদী নেটওয়ার্ক সমস্যা বা লগিং তীব্রতা বৃদ্ধির ক্ষেত্রে লগ ক্ষতি রোধ করতে আমরা ফ্লুয়েন্টড আউটপুটে একটি বাফারিং প্লাগইন ব্যবহার করি। যদি কোনো কারণে ইলাস্টিক সার্চ অবিলম্বে সূচীতে একটি নথি লিখতে অক্ষম হয়, নথিটি সারিবদ্ধ এবং ডিস্কে সংরক্ষণ করা হয়। অতএব, আমাদের ক্ষেত্রে, সমস্যাটির উত্স নির্মূল করার জন্য যা উপরে বর্ণিত ত্রুটির দিকে পরিচালিত করে, বাফারিং প্যারামিটারগুলির জন্য সঠিক মানগুলি সেট করা প্রয়োজন, যেখানে ফ্লুয়েন্টড আউটপুট বাফার যথেষ্ট আকারের হবে এবং একই সময়ে বরাদ্দ সময়ে সাফ করা পরিচালনা.

এটি লক্ষণীয় যে নীচে আলোচিত পরামিতিগুলির মানগুলি আউটপুট প্লাগইনগুলিতে বাফারিং ব্যবহারের প্রতিটি নির্দিষ্ট ক্ষেত্রে পৃথক, কারণ সেগুলি অনেকগুলি কারণের উপর নির্ভর করে: পরিষেবাগুলির দ্বারা লগে বার্তা লেখার তীব্রতা, ডিস্ক সিস্টেমের কার্যকারিতা, নেটওয়ার্ক চ্যানেল লোড এবং এর ব্যান্ডউইথ। অতএব, বাফার সেটিংস পাওয়ার জন্য যা প্রতিটি পৃথক ক্ষেত্রে উপযুক্ত, কিন্তু অপ্রয়োজনীয় নয়, দীর্ঘ অনুসন্ধানগুলিকে অন্ধভাবে এড়িয়ে চলুন, আপনি ডিবাগিং তথ্য ব্যবহার করতে পারেন যা ফ্লুয়েন্টড অপারেশন চলাকালীন তার লগে লিখে এবং তুলনামূলকভাবে দ্রুত সঠিক মানগুলি পেতে পারে৷

যখন সমস্যাটি রেকর্ড করা হয়েছিল, তখন কনফিগারেশনটি দেখতে এইরকম ছিল:

 <buffer>
        @type file
        path /var/log/fluentd-buffers/kubernetes.test.buffer
        flush_mode interval
        retry_type exponential_backoff
        flush_thread_count 2
        flush_interval 5s
        retry_forever
        retry_max_interval 30
        chunk_limit_size 8M
        queue_limit_length 8
        overflow_action block
      </buffer>

সমস্যাটি সমাধান করার সময়, নিম্নলিখিত পরামিতিগুলির মানগুলি ম্যানুয়ালি নির্বাচন করা হয়েছিল:
chunk_limit_size — খণ্ডগুলির আকার যেখানে বাফারের বার্তাগুলিকে ভাগ করা হয়েছে।

flush_interval — সময়ের ব্যবধান যার পরে বাফার সাফ করা হয়।
queue_limit_length — সারিতে থাকা সর্বোচ্চ সংখ্যা।
request_timeout হল সেই সময় যার জন্য Fluentd এবং ElasticSearch-এর মধ্যে সংযোগ স্থাপন করা হয়।

queue_limit_length এবং chunk_limit_size পরামিতিগুলিকে গুণ করে মোট বাফারের আকার গণনা করা যেতে পারে, যেটিকে "সারিতে সর্বাধিক সংখ্যক খণ্ড, যার প্রতিটির একটি প্রদত্ত আকার রয়েছে" হিসাবে ব্যাখ্যা করা যেতে পারে৷ বাফার আকার অপর্যাপ্ত হলে, নিম্নলিখিত সতর্কতা লগগুলিতে প্রদর্শিত হবে:

2020-01-21 10:22:57 +0000 [warn]: [test-prod] failed to write data into buffer by buffer overflow action=:block

এর মানে হল যে বরাদ্দকৃত সময়ে বাফারের সাফ করার সময় নেই এবং সম্পূর্ণ বাফারে প্রবেশ করা ডেটা ব্লক করা হয়েছে, যা লগগুলির অংশ হারানোর দিকে পরিচালিত করবে।

আপনি দুটি উপায়ে বাফার বাড়াতে পারেন: হয় সারিতে থাকা প্রতিটি খণ্ডের আকার বাড়িয়ে, অথবা সারিতে থাকা খণ্ডের সংখ্যা বাড়িয়ে।

আপনি যদি খণ্ডের আকার chunk_limit_size 32 মেগাবাইটের বেশি সেট করেন, তাহলে ইলাস্টিক সেক্রহ এটি গ্রহণ করবে না, যেহেতু ইনকামিং প্যাকেটটি খুব বড় হবে। অতএব, যদি আপনার বাফারটি আরও বাড়ানোর প্রয়োজন হয়, তবে সর্বোচ্চ সারির দৈর্ঘ্য queue_limit_length বাড়ানো ভাল।

যখন বাফারটি উপচে পড়া বন্ধ হয়ে যায় এবং শুধুমাত্র টাইমআউট অপর্যাপ্ত বার্তা অবশিষ্ট থাকে, আপনি অনুরোধ_টাইমআউট প্যারামিটার বাড়ানো শুরু করতে পারেন। যাইহোক, যদি আপনি মানটি 20 সেকেন্ডের বেশি সেট করেন, তাহলে নিম্নলিখিত সতর্কতাগুলি Fluentd লগগুলিতে প্রদর্শিত হবে:

2020-01-21 09:55:33 +0000 [warn]: [test-dev] buffer flush took longer time than slow_flush_log_threshold: elapsed_time=20.85753920301795 slow_flush_log_threshold=20.0 plugin_id="postgresql-dev"

এই বার্তাটি কোনোভাবেই সিস্টেমের ক্রিয়াকলাপকে প্রভাবিত করে না এবং এর অর্থ হল বাফার ফ্লাশের সময় slow_flush_log_threshold প্যারামিটার দ্বারা সেট করা থেকে বেশি সময় নেয়। এটি ডিবাগিং তথ্য এবং আমরা অনুরোধ_টাইমআউট প্যারামিটারের মান নির্বাচন করার সময় এটি ব্যবহার করি।

সাধারণ নির্বাচন অ্যালগরিদম নিম্নরূপ:

রিকোয়েস্ট_টাইমআউটকে প্রয়োজনের চেয়ে বেশি হওয়ার গ্যারান্টিযুক্ত একটি মান সেট করুন (শত সেকেন্ড)। সেটআপের সময়, এই প্যারামিটারের সঠিক সেটিং এর প্রধান মাপকাঠি হবে সময়সীমার অভাব সম্পর্কে সতর্কতার অদৃশ্য হওয়া।
স্লো_ফ্লাশ_লগ_থ্রেশহোল্ড থ্রেশহোল্ড অতিক্রম করার বিষয়ে বার্তাগুলির জন্য অপেক্ষা করুন৷ elapsed_time ক্ষেত্রের সতর্কতা পাঠ্যটি বাফারটি সাফ করার আসল সময় দেখাবে।
পর্যবেক্ষণ সময়কালে প্রাপ্ত সর্বাধিক অতিবাহিত_সময়ের মানের চেয়ে বেশি একটি মান অনুরোধ_টাইমআউট সেট করুন। আমরা রিকোয়েস্ট_টাইমআউট মানটিকে অতিবাহিত_সময় + 50% হিসাবে গণনা করি।
লগ থেকে দীর্ঘ বাফার ফ্লাশ সম্পর্কে সতর্কতা অপসারণ করতে, আপনি slow_flush_log_threshold এর মান বাড়াতে পারেন। আমরা এই মানটিকে অতিবাহিত_সময় + 25% হিসাবে গণনা করি।

এই পরামিতিগুলির চূড়ান্ত মানগুলি, যেমনটি আগে উল্লেখ করা হয়েছে, প্রতিটি ক্ষেত্রে পৃথকভাবে প্রাপ্ত হয়। উপরোক্ত অ্যালগরিদম অনুসরণ করে, আমরা নিশ্চিত যে ত্রুটিটি বারবার বার্তার দিকে নিয়ে যায়।

নীচের সারণীটি দেখায় কিভাবে প্রতিদিন ত্রুটির সংখ্যা, বার্তাগুলির নকলের দিকে পরিচালিত করে, উপরে বর্ণিত পরামিতিগুলির মান নির্বাচন করার প্রক্রিয়াতে পরিবর্তন হয়:

নোড-1
নোড-2
নোড-3
নোড-4

আগে পরে
আগে পরে
আগে পরে
আগে পরে

বাফার ফ্লাশ করতে ব্যর্থ
1749/2
694/2
47/0
1121/2

পুনরায় চেষ্টা সফল হয়েছে
410/2
205/1
24/0
241/2

এটি অতিরিক্তভাবে লক্ষণীয় যে প্রকল্পের বৃদ্ধির সাথে সাথে ফলাফলের সেটিংসগুলি তাদের প্রাসঙ্গিকতা হারাতে পারে এবং সেই অনুযায়ী, লগের সংখ্যা বৃদ্ধি পায়। অপর্যাপ্ত টাইমআউটের প্রাথমিক চিহ্ন হল Fluentd লগে একটি দীর্ঘ বাফার ফ্লাশ সম্পর্কে বার্তা ফেরত দেওয়া, অর্থাৎ, স্লো_ফ্লুশ_লগ_থ্রেশহোল্ড থ্রেশহোল্ড অতিক্রম করা। এই বিন্দু থেকে, অনুরোধ_টাইমআউট প্যারামিটার অতিক্রম করার আগে এখনও একটি ছোট মার্জিন রয়েছে, তাই এই বার্তাগুলির সময়মত প্রতিক্রিয়া জানানো এবং উপরে বর্ণিত সর্বোত্তম সেটিংস নির্বাচন করার প্রক্রিয়াটি পুনরাবৃত্তি করা প্রয়োজন।

উপসংহার

Fluentd আউটপুট বাফারের ফাইন-টিউনিং হল EFK স্ট্যাক কনফিগার করার প্রধান পর্যায়গুলির মধ্যে একটি, এটির ক্রিয়াকলাপের স্থায়িত্ব এবং সূচীতে নথির সঠিক স্থান নির্ধারণ করা। বর্ণিত কনফিগারেশন অ্যালগরিদমের উপর ভিত্তি করে, আপনি নিশ্চিত হতে পারেন যে সমস্ত লগ ইলাস্টিক সার্চ ইনডেক্সে সঠিক ক্রমে লেখা হবে, পুনরাবৃত্তি বা ক্ষতি ছাড়াই।

এছাড়াও আমাদের ব্লগে অন্যান্য নিবন্ধ পড়ুন:

উত্স: www.habr.com

Fluentd: কেন আউটপুট বাফার কনফিগার করা গুরুত্বপূর্ণ

নথির নকলের সমস্যা

সম্ভাষণ

উপসংহার

এছাড়াও আমাদের ব্লগে অন্যান্য নিবন্ধ পড়ুন:

একটি মন্তব্য জুড়ুন উত্তর বাতিল