🥇 روانی: آؤٹ پٹ بفر کو ترتیب دینا کیوں ضروری ہے

آج کل، ELK اسٹیک کے بغیر Kubernetes پر مبنی پروجیکٹ کا تصور کرنا ناممکن ہے، جو کلسٹر کے ایپلیکیشنز اور سسٹم کے اجزاء دونوں کے لاگ کو محفوظ کرتا ہے۔ ہماری مشق میں، ہم Logstash کے بجائے Fluentd کے ساتھ EFK اسٹیک استعمال کرتے ہیں۔

Fluentd ایک جدید، یونیورسل لاگ کلیکٹر ہے جو زیادہ سے زیادہ مقبولیت حاصل کر رہا ہے اور اس نے کلاؤڈ نیٹیو کمپیوٹنگ فاؤنڈیشن میں شمولیت اختیار کی ہے، یہی وجہ ہے کہ اس کا ترقیاتی ویکٹر Kubernetes کے ساتھ مل کر استعمال کرنے پر مرکوز ہے۔

Logstash کے بجائے Fluentd استعمال کرنے کی حقیقت سافٹ ویئر پیکج کے عمومی جوہر کو تبدیل نہیں کرتی ہے، تاہم، Fluentd کی خصوصیت اس کی اپنی مخصوص باریکیوں سے ہوتی ہے جو اس کی استعداد کے نتیجے میں ہوتی ہے۔

مثال کے طور پر، جب ہم نے ایک مصروف پروجیکٹ میں لاگنگ کی بہت زیادہ شدت کے ساتھ EFK کا استعمال شروع کیا، تو ہمیں اس حقیقت کا سامنا کرنا پڑا کہ کبانا میں کچھ پیغامات کئی بار بار بار دکھائے گئے۔ اس مضمون میں ہم آپ کو بتائیں گے کہ یہ رجحان کیوں ہوتا ہے اور اس مسئلے کو کیسے حل کیا جائے۔

دستاویز کی نقل کا مسئلہ

ہمارے پروجیکٹس میں، Fluentd کو ڈیمون سیٹ کے طور پر تعینات کیا جاتا ہے (کوبرنیٹس کلسٹر کے ہر نوڈ پر ایک مثال میں خودکار طور پر لانچ کیا جاتا ہے) اور /var/log/containers میں stdout کنٹینر لاگز کی نگرانی کرتا ہے۔ جمع کرنے اور پروسیسنگ کے بعد، JSON دستاویزات کی شکل میں لاگز ElasticSearch کو بھیجے جاتے ہیں، جو کلسٹر یا اسٹینڈ اکیلی شکل میں اٹھائے جاتے ہیں، یہ پروجیکٹ کے پیمانے اور کارکردگی اور غلطی کو برداشت کرنے کے تقاضوں پر منحصر ہے۔ کبانہ کو گرافیکل انٹرفیس کے طور پر استعمال کیا جاتا ہے۔

آؤٹ پٹ بفرنگ پلگ ان کے ساتھ Fluentd استعمال کرتے وقت، ہمیں ایک ایسی صورتحال کا سامنا کرنا پڑا جہاں ElasticSearch میں کچھ دستاویزات میں بالکل ایک جیسا مواد تھا اور صرف شناخت کنندہ میں فرق تھا۔ آپ تصدیق کر سکتے ہیں کہ یہ ایک پیغام کی تکرار ہے 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" -

تاہم، ElasticSearch میں کئی دستاویزات ہیں جن میں یہ پیغام موجود ہے:

{
  "_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"

یہ انتباہات اس وقت ہوتی ہیں جب ElasticSearch کسی درخواست کا جواب ریکوسٹ_ٹائم آؤٹ پیرامیٹر کے ذریعے متعین وقت کے اندر واپس نہیں کر سکتا، یہی وجہ ہے کہ فارورڈ شدہ بفر فریگمنٹ کو صاف نہیں کیا جا سکتا۔ اس کے بعد، Fluentd دوبارہ ElasticSearch کو بفر کے ٹکڑے بھیجنے کی کوشش کرتا ہے اور متعدد کوششوں کے بعد، آپریشن کامیابی سے مکمل ہوتا ہے:

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"

تاہم، ElasticSearch منتقل شدہ بفر کے ہر ٹکڑے کو منفرد سمجھتا ہے اور انڈیکسنگ کے دوران انہیں منفرد _id فیلڈ ویلیوز تفویض کرتا ہے۔ پیغامات کی کاپیاں اس طرح ظاہر ہوتی ہیں۔

کبانہ میں یہ اس طرح لگتا ہے:

حل

اس مسئلے کو حل کرنے کے کئی اختیارات ہیں۔ ان میں سے ایک وہ طریقہ کار ہے جو ہر دستاویز کے لیے ایک منفرد ہیش بنانے کے لیے fluent-pluin-elasticsearch پلگ ان میں بنایا گیا ہے۔ اگر آپ اس طریقہ کار کو استعمال کرتے ہیں، تو ElasticSearch آگے بڑھنے کے مرحلے پر تکرار کو پہچان لے گی اور نقلی دستاویزات کو روکے گی۔ لیکن ہمیں اس بات کو ذہن میں رکھنا چاہیے کہ مسئلہ کو حل کرنے کا یہ طریقہ تفتیش کے ساتھ جدوجہد کرتا ہے اور وقت کی کمی کے ساتھ غلطی کو ختم نہیں کرتا، اس لیے ہم نے اس کا استعمال ترک کر دیا۔

ہم قلیل مدتی نیٹ ورک کے مسائل یا لاگنگ کی شدت میں اضافے کی صورت میں لاگ نقصان کو روکنے کے لیے Fluentd آؤٹ پٹ پر بفرنگ پلگ ان کا استعمال کرتے ہیں۔ اگر کسی وجہ سے ElasticSearch فوری طور پر انڈیکس میں دستاویز لکھنے سے قاصر ہے، تو دستاویز کو قطار میں لگا کر ڈسک پر محفوظ کیا جاتا ہے۔ لہذا، ہمارے معاملے میں، اس مسئلے کے ماخذ کو ختم کرنے کے لیے جو اوپر بیان کی گئی غلطی کی طرف لے جاتا ہے، بفرنگ پیرامیٹرز کے لیے درست اقدار کا تعین کرنا ضروری ہے، جس پر Fluentd آؤٹ پٹ بفر کافی سائز کا ہو گا اور ایک ہی وقت میں مختص وقت میں صاف کرنے کا انتظام.

یہ بات قابل غور ہے کہ ذیل میں زیر بحث پیرامیٹرز کی قدریں آؤٹ پٹ پلگ ان میں بفرنگ استعمال کرنے کے ہر مخصوص معاملے میں انفرادی ہوتی ہیں، کیونکہ وہ بہت سے عوامل پر منحصر ہیں: سروسز کے ذریعے لاگ پر پیغامات لکھنے کی شدت، ڈسک سسٹم کی کارکردگی، نیٹ ورک چینل لوڈ اور اس کی بینڈوتھ۔ لہٰذا، بفر سیٹنگز حاصل کرنے کے لیے جو ہر انفرادی کیس کے لیے موزوں ہیں، لیکن بے کار نہیں، لمبی لمبی تلاشوں سے پرہیز کرتے ہوئے، آپ ڈیبگنگ معلومات استعمال کر سکتے ہیں جو Fluentd آپریشن کے دوران اپنے لاگ پر لکھتا ہے اور نسبتاً تیزی سے درست اقدار حاصل کر سکتا ہے۔

اس وقت جب مسئلہ ریکارڈ کیا گیا تھا، ترتیب اس طرح نظر آتی تھی:

 <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 size chunk_limit_size کو 32 میگا بائٹس سے زیادہ پر سیٹ کرتے ہیں، تو ElasticSeacrh اسے قبول نہیں کرے گا، کیونکہ آنے والا پیکٹ بہت بڑا ہوگا۔ لہذا، اگر آپ کو بفر کو مزید بڑھانے کی ضرورت ہے، تو بہتر ہے کہ زیادہ سے زیادہ قطار کی لمبائی queue_limit_length کو بڑھایا جائے۔

جب بفر اوور فلو ہونا بند ہو جاتا ہے اور صرف ٹائم آؤٹ ناکافی پیغام باقی رہ جاتا ہے، تو آپ request_timeout پیرامیٹر کو بڑھانا شروع کر سکتے ہیں۔ تاہم، اگر آپ قیمت کو 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 لاگ پر ایک طویل بفر فلش کے بارے میں پیغامات کی واپسی ہے، یعنی، slow_flush_log_threshold کی حد سے تجاوز کرنا۔ اس مقام سے، درخواست_ٹائم آؤٹ پیرامیٹر سے تجاوز کرنے سے پہلے تھوڑا سا مارجن باقی ہے، اس لیے ضروری ہے کہ ان پیغامات کا بروقت جواب دیا جائے اور اوپر بیان کردہ بہترین ترتیبات کو منتخب کرنے کے عمل کو دہرایا جائے۔

حاصل يہ ہوا

Fluentd آؤٹ پٹ بفر کو ٹھیک کرنا EFK اسٹیک کو ترتیب دینے کے اہم مراحل میں سے ایک ہے، اس کے آپریشن کے استحکام اور اشاریہ جات میں دستاویزات کی درست جگہ کا تعین کرنا۔ بیان کردہ کنفیگریشن الگورتھم کی بنیاد پر، آپ یقین کر سکتے ہیں کہ تمام لاگز درست ترتیب میں ElasticSearch انڈیکس میں لکھے جائیں گے، بغیر تکرار یا نقصان کے۔

ہمارے بلاگ پر دیگر مضامین بھی پڑھیں:

ماخذ: www.habr.com

Fluentd: آؤٹ پٹ بفر کو ترتیب دینا کیوں ضروری ہے۔

دستاویز کی نقل کا مسئلہ

حل

حاصل يہ ہوا

ہمارے بلاگ پر دیگر مضامین بھی پڑھیں:

نیا تبصرہ شامل کریں جواب منسوخ کریں