اڄڪلهه، ELK اسٽيڪ کان سواء ڪوبرنيٽس تي ٻڌل منصوبي کي تصور ڪرڻ ناممڪن آهي، جيڪو ڪلستر جي ايپليڪيشنن ۽ سسٽم جي اجزاء جي لاگ محفوظ ڪري ٿو. اسان جي مشق ۾، اسان استعمال ڪندا آهيون EFK اسٽيڪ سان Fluentd بدران Logstash.
Fluentd هڪ جديد، آفاقي لاگ ڪليڪٽر آهي جيڪو وڌ کان وڌ مقبوليت حاصل ڪري رهيو آهي ۽ Cloud Native Computing Foundation ۾ شامل ٿيو آهي، اهو ئي سبب آهي جو ان جو ڊولپمينٽ ویکٹر Kubernetes سان گڏ استعمال ڪرڻ تي مرکوز آهي.
Logstash جي بدران Fluentd استعمال ڪرڻ جي حقيقت سافٽ ويئر پيڪيج جي عام جوهر کي تبديل نٿو ڪري، جڏهن ته، Fluentd ان جي پنهنجي مخصوص nuances سان منسوب ڪيو ويو آهي ان جي استحڪام جي نتيجي ۾.
مثال طور، جڏهن اسان EFK استعمال ڪرڻ شروع ڪيو هڪ مصروف منصوبي ۾ لاگنگ جي وڏي شدت سان، اسان کي ان حقيقت سان منهن ڏيڻو پيو ته ڪيبانا ۾ ڪجهه پيغام ڪيترائي ڀيرا بار بار ڏيکاريا ويا. هن آرٽيڪل ۾ اسان توهان کي ٻڌايو ته هي رجحان ڇو ٿئي ٿو ۽ ڪيئن مسئلو حل ڪجي.
دستاويز جي نقل جو مسئلو
اسان جي پروجيڪٽن ۾، Fluentd هڪ DaemonSet طور مقرر ڪيو ويو آهي (خودڪار طور تي شروع ڪيو ويو آهي هڪ مثال ۾ ڪبرنيٽس ڪلستر جي هر نوڊ تي) ۽ مانيٽر ڪري ٿو stdout ڪنٽينر لاگ ان /var/log/containers. گڏ ڪرڻ ۽ پروسيسنگ کان پوءِ، لاگز JSON دستاويزن جي صورت ۾ موڪليا ويندا آهن ElasticSearch ڏانهن، ڪلستر يا اسٽينڊل فارم ۾ اٿاريو ويندو آهي، منصوبي جي پيماني تي ۽ ڪارڪردگي ۽ غلطي رواداري جي گهرج تي منحصر هوندو آهي. Kibana گرافڪ انٽرفيس طور استعمال ڪيو ويندو آهي.
جڏهن هڪ آئوٽ بفرنگ پلگ ان سان Fluentd استعمال ڪري رهيا آهيون، اسان هڪ اهڙي صورتحال کي منهن ڏنو جتي ElasticSearch ۾ ڪجهه دستاويز بلڪل ساڳيو مواد هئا ۽ صرف سڃاڻپ ڪندڙ ۾ اختلاف هئا. توھان تصديق ڪري سگھوٿا ته اھو ھڪڙو پيغام آھي ورجائي استعمال ڪندي نينگڪس لاگ استعمال ڪندي مثال طور. لاگ فائل ۾، هي پيغام هڪ واحد ڪاپي ۾ موجود آهي:
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"اهي ڊيڄاريندڙ تڏهن ٿين ٿا جڏهن ElasticSearch درخواست جو جواب واپس نه ٿو ڪري سگهي درخواست_timeout پيراميٽر طرفان بيان ڪيل وقت اندر، جنهن ڪري اڳتي هلي بفر جو ٽڪرو صاف نه ٿو ڪري سگهجي. ان کان پوء، 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 فيلڊ ويلز تفويض ڪري ٿو. اهڙي طرح پيغامن جون ڪاپيون ظاهر ٿينديون آهن.
Kibana ۾ اهو هن طرح نظر اچي ٿو:
مسئلا حل ڪرڻ
ھن مسئلي کي حل ڪرڻ لاء ڪيترائي اختيار آھن. انهن مان هڪ ميکانيزم آهي جيڪو fluent-plugin-elasticsearch پلگ ان ۾ ٺاهيو ويو آهي هر دستاويز لاءِ هڪ منفرد هيش ٺاهڻ لاءِ. جيڪڏهن توهان هن ميکانيزم کي استعمال ڪندا آهيو، ElasticSearch اڳتي وڌڻ واري مرحلي ۾ ورهاڱي جي سڃاڻپ ڪندو ۽ نقل ٿيل دستاويزن کي روڪيندو. پر اسان کي اهو سمجهڻ گهرجي ته مسئلو حل ڪرڻ جو هي طريقو تحقيق سان جدوجهد ڪري ٿو ۽ وقت جي کوٽ سان غلطي کي ختم نٿو ڪري، تنهنڪري اسان ان جي استعمال کي ڇڏي ڏنو.
اسان هڪ بفرنگ پلگ ان Fluentd آئوٽ پٽ تي استعمال ڪريون ٿا لاگ نقصان کي روڪڻ لاءِ مختصر مدت جي نيٽ ورڪ جي مسئلن جي صورت ۾ يا وڌ ۾ وڌ لاگنگ جي شدت. جيڪڏهن ڪنهن سبب جي ڪري ElasticSearch انڊيڪس ۾ هڪ دستاويز کي فوري طور تي لکڻ جي قابل ناهي، دستاويز قطار ۾ رکيل آهي ۽ ڊسڪ تي ذخيرو ٿيل آهي. تنهن ڪري، اسان جي صورت ۾، مسئلي جي ماخذ کي ختم ڪرڻ لاءِ جيڪو مٿي بيان ڪيل غلطي جي طرف وٺي ٿو، اهو ضروري آهي ته بفرنگ پيرا ميٽرز لاءِ صحيح قدرون مقرر ڪيون وڃن، جنهن تي فلوئنٽ آئوٽ بفر ڪافي سائيز جو هوندو ۽ ساڳئي وقت مقرر ڪيل وقت ۾ صاف ٿيڻ جو انتظام ڪريو.
اهو نوٽ ڪرڻ جي قابل آهي ته هيٺ ڏنل پيرا ميٽرن جا قدر انفرادي آهن هر مخصوص صورت ۾ آئوٽ پلگ ان ۾ بفرنگ استعمال ڪرڻ جي، ڇاڪاڻ ته اهي ڪيترن ئي عنصر تي ڀاڙين ٿا: خدمتن جي ذريعي لاگ ڏانهن پيغام لکڻ جي شدت، ڊسڪ سسٽم جي ڪارڪردگي، نيٽورڪ چينل لوڊ ۽ ان جي بينڊوڊٿ. تنهن ڪري، بفر سيٽنگون حاصل ڪرڻ لاءِ جيڪي هر فرد جي ڪيس لاءِ موزون هجن، پر بيڪار نه هجن، ڊگهي ڳولها کان پاسو ڪندي، توهان ڊيبگنگ معلومات استعمال ڪري سگهو ٿا جيڪا 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 جي وچ ۾ ڪنيڪشن قائم ٿيل آهي.
ڪُل بفر جي ماپ جو اندازو لڳائي سگهجي ٿو پيرا ميٽرز que_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 ميگا بائيٽ کان وڌيڪ سيٽ ڪريو ٿا، ته پوءِ 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" هي پيغام ڪنهن به طريقي سان سسٽم جي آپريشن تي اثر انداز نٿو ڪري ۽ مطلب ته بفر فلش وقت سست_فلش_log_threshold پيراميٽر جي ترتيب کان وڌيڪ وقت ورتو. هي معلومات ڊيبگنگ آهي ۽ اسان ان کي استعمال ڪندا آهيون جڏهن درخواست_timeout پيٽرولر جي قيمت کي چونڊيو.
عام چونڊ الورورٿم هن ريت آهي:
- مقرر ڪريو request_timeout ھڪ قدر تي جنھن جي ضمانت ڏني وئي آھي ضروري کان وڌيڪ آھي (سيڪن جا سيڪنڊ). سيٽ اپ دوران، هن پيٽرولر جي صحيح سيٽنگ لاء بنيادي معيار وقت ختم ٿيڻ جي گهٽتائي لاء ڊيڄاريندڙن جي غائب ٿي ويندي.
- slow_flush_log_threshold جي حد کان وڌڻ بابت پيغامن جو انتظار ڪريو. ڊيڄاريندڙ متن elapsed_time فيلڊ ۾ ڏيکاريندو حقيقي وقت بفر صاف ڪيو ويو.
- مقرر ڪريو request_timeout ھڪڙي قدر تي جيڪو وڌ ۾ وڌ گذري ويل وقت کان وڌيڪ آھي جيڪو مشاهدي جي مدت دوران حاصل ڪيو ويو آھي. اسان حساب ڪريون ٿا request_timeout قدر elapsed_time + 50%.
- لاگ مان ڊگھي بفر فلش بابت ڊيڄاريندڙن کي ختم ڪرڻ لاءِ، توھان وڌائي سگھوٿا slow_flush_log_threshold جو قدر. اسان حساب ڪريون ٿا هن قيمت کي elapsed_time + 25%.
انهن پيراگرافن جي آخري قدر، جيئن اڳ بيان ڪيو ويو آهي، هر ڪيس لاء انفرادي طور تي حاصل ڪيا ويا آهن. مٿي ڏنل الگورٿم تي عمل ڪندي، اسان ان غلطي کي ختم ڪرڻ جي ضمانت ڏني آهي جيڪا بار بار پيغامن جي ڪري ٿي.
هيٺ ڏنل جدول ڏيکاري ٿو ته هر روز غلطين جو تعداد، پيغامن جي نقل ڪرڻ جي ڪري، مٿي بيان ڪيل پيٽرولن جي قدرن کي چونڊڻ جي عمل ۾ تبديليون:
نوڊ-1
نوڊ-2
نوڊ-3
نوڊ-4
اڳي پوءِ
اڳي پوءِ
اڳي پوءِ
اڳي پوءِ
بفر کي ڦهلائڻ ۾ ناڪام ٿيو
1749/2
694/2
47/0
1121/2
ٻيهر ڪوشش ڪامياب
410/2
205/1
24/0
241/2
اهو اضافي طور تي نوٽ ڪرڻ جي قابل آهي ته نتيجو سيٽنگون پنهنجو لاڳاپو وڃائي سگھن ٿيون جيئن پروجيڪٽ وڌندو آهي ۽، مطابق، لاگن جو تعداد وڌائي ٿو. ناکافي وقت ختم ٿيڻ جي بنيادي نشاني آهي پيغامن جي واپسي هڪ ڊگهي بفر فلش بابت Fluentd لاگ ڏانهن، اهو آهي، سست_فلش_log_threshold جي حد کان وڌيڪ. ھن نقطي کان، اڃا تائين ھڪڙو ننڍڙو مارجن آھي ان کان اڳ جو request_timeout پيٽرولر وڌايو وڃي، تنھنڪري ضروري آھي ته انھن پيغامن جو بروقت جواب ڏيو ۽ مٿي بيان ڪيل بھترين سيٽنگون چونڊڻ جي عمل کي ورجايو.
ٿڪل
Fluentd آئوٽ پُٽ بفر کي ٺيڪ ڪرڻ EFK اسٽيڪ کي ترتيب ڏيڻ جي بنيادي مرحلن مان هڪ آهي، ان جي آپريشن جي استحڪام کي طئي ڪرڻ ۽ انڊيڪسز ۾ دستاويزن جي صحيح جڳهه کي طئي ڪرڻ. بيان ڪيل تشڪيل جي الگورتھم جي بنياد تي، توھان پڪ ڪري سگھو ٿا ته سڀئي لاگس درست ترتيب ۾ ElasticSearch انڊيڪس ڏانھن لکيا ويندا، بغير ورجائي يا نقصان جي.
اسان جي بلاگ تي ٻيا مضمون پڻ پڙهو:
جو ذريعو: www.habr.com