نن ورځ ، د ELK سټیک پرته د کبرنیټس میشته پروژې تصور کول ناممکن دي ، کوم چې د کلسټر دواړه غوښتنلیکونو او سیسټم اجزاو لاګ خوندي کوي. زموږ په تمرین کې، موږ د Logstash پرځای د Fluentd سره د EFK سټیک کاروو.
Fluentd یو عصري، یونیورسل لاګ راټولونکی دی چې ډیر او ډیر شهرت ترلاسه کوي او د کلاوډ اصلي کمپیوټر بنسټ سره یوځای شوی، له همدې امله د دې پراختیا ویکتور د Kubernetes سره په ګډه کارولو تمرکز کوي.
د Logstash پر ځای د Fluentd کارولو حقیقت د سافټویر کڅوړې عمومي جوهر نه بدلوي، په هرصورت، Fluentd د خپل ځانګړي ځانګړتیاوو لخوا مشخص شوی چې د هغې د استقامت پایله ده.
د مثال په توګه، کله چې موږ د EFK کارول په یوه بوخته پروژه کې د لوړې شدت سره د ننوتلو سره پیل کړل، موږ د دې حقیقت سره مخ شو چې په کبانا کې ځینې پیغامونه څو څو ځله ښودل شوي. پدې مقاله کې به موږ تاسو ته ووایو چې ولې دا پدیده پیښیږي او څنګه د ستونزې حل کول.
د سند د نقل کولو ستونزه
زموږ په پروژو کې، Fluentd د ډیمون سیټ په توګه ګمارل کیږي (په اتوماتيک ډول د کوبرنیټس کلستر په هر نوډ کې په یوه مثال کې پیل کیږي) او په /var/log/containers کې د stdout کانټینر لاګونه څاري. د راټولولو او پروسس کولو وروسته، د JSON اسنادو په بڼه لاګونه ElasticSearch ته لیږل کیږي، په کلستر یا سټایلون بڼه کې پورته شوي، د پروژې پیمانه او د فعالیت او غلطی زغملو اړتیاو پورې اړه لري. کیبانا د ګرافیکي انٹرفیس په توګه کارول کیږي.
کله چې د محصول بفرینګ پلگ ان سره 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" -په هرصورت، په 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"
}
}برسېره پردې، له دوو څخه زیات تکرار کیدی شي.
پداسې حال کې چې د فلوینډ لاګونو کې د دې ستونزې حل کول، تاسو کولی شئ د لاندې منځپانګې سره لوی شمیر اخطارونه وګورئ:
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 ساحې ارزښتونه ورکوي. دا څنګه د پیغامونو کاپي ښکاري.
په کبانا کې دا داسې ښکاري:
ستونزه حل کول
د دې ستونزې د حل لپاره څو انتخابونه شتون لري. یو له دوی څخه هغه میکانیزم دی چې د هر سند لپاره د ځانګړي هش رامینځته کولو لپاره د 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 ترمنځ اړیکه جوړه شوې.
د بفر ټوله اندازه د پیرامیټرونو قطار_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 به دا ونه مني، ځکه چې راتلونکی کڅوړه به ډیره لویه وي. نو له همدې امله، که تاسو اړتیا لرئ چې بفر نور هم زیات کړئ، نو دا به غوره وي چې د قطار اعظمي اوږدوالی قطار_limit_length زیات کړئ.
کله چې بفر ډیریږي او یوازې د وخت پای ناکافي پیغام پاتې کیږي، تاسو کولی شئ د request_timeout پیرامیټر زیاتول پیل کړئ. که څه هم، که تاسو ارزښت له 20 ثانیو څخه زیات وټاکئ، لاندې اخطارونه به په فلوینډ لاګونو کې څرګند شي:
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" دا پیغام په هیڅ ډول د سیسټم په عملیاتو اغیزه نه کوي او پدې معنی چې د بفر فلش وخت د سست_فلش_لوګ_تریشول پیرامیټر لخوا ټاکل شوي څخه ډیر وخت نیسي. دا د ډیبګ کولو معلومات دي او موږ دا کاروو کله چې د request_timeout پیرامیټر ارزښت غوره کړو.
د عمومي انتخاب الګوریتم په لاندې ډول دی:
- د غوښتنې_ مهال ویش د اړتیا څخه ډیر تضمین شوي ارزښت ته تنظیم کړئ (سلګونه ثانیې). د تنظیم کولو په جریان کې ، د دې پیرامیټر درست ترتیب لپاره اصلي معیار به د وخت نشتوالي لپاره د اخطارونو ورکیدل وي.
- د سست_فلش_لوګ_د حد څخه د تیریدو په اړه پیغامونو ته انتظار وکړئ. په تېر شوي_time ډګر کې د خبرتیا متن به ریښتیني وخت وښیې چې بفر پاک شوی و.
- د غوښتنې_timeout ارزښت ته وټاکئ چې د مشاهدې دورې په جریان کې ترلاسه شوي اعظمي تیر شوي وخت ارزښت څخه ډیر وي. موږ د request_timeout ارزښت د تېر شوي_time + 50٪ په توګه محاسبه کوو.
- د لاګ څخه د اوږد بفر فلشونو په اړه اخطارونه لرې کولو لپاره ، تاسو کولی شئ د سست_فلش_لوګ_threshold ارزښت لوړ کړئ. موږ دا ارزښت د تیر شوي_ وخت + 25٪ په توګه محاسبه کوو.
د دې پیرامیټونو وروستي ارزښتونه، لکه څنګه چې مخکې یادونه وشوه، په انفرادي توګه د هرې قضیې لپاره ترلاسه کیږي. د پورته الګوریتم په تعقیب سره، موږ تضمین شوي یو چې هغه تېروتنه له منځه یوسو چې د تکرار پیغامونو لامل کیږي.
لاندې جدول ښیي چې څنګه هره ورځ د غلطیو شمیره، د پیغامونو د نقل کولو المل کیږي، د پورته بیان شوي پیرامیټونو ارزښتونو غوره کولو پروسې کې بدلونونه:
نوډ-1
نوډ-2
نوډ-3
نوډ-4
مخکې وروسته
مخکې وروسته
مخکې وروسته
مخکې وروسته
د بفر فلش کولو کې پاتې راغلی
1749/2
694/2
47/0
1121/2
بیا هڅه بریالۍ شوه
410/2
205/1
24/0
241/2
دا د یادونې وړ هم ده چې پایله شوي تنظیمات ممکن خپل تړاو له لاسه ورکړي ځکه چې پروژه وده کوي او په وینا یې د لاګونو شمیر ډیریږي. د ناکافي وخت پای ته رسیدو لومړنۍ نښه د Fluentd لاګ ته د اوږد بفر فلش په اړه د پیغامونو بیرته راستنیدل دي، دا د سست_فلش_لوګ_تریشولډ حد څخه ډیر دی. له دې ځایه، لاهم یو کوچنی حاشیه شتون لري مخکې لدې چې د غوښتنې_timeout پیرامیټر ډیر شي ، نو دا اړینه ده چې په وخت سره دې پیغامونو ته ځواب ووایی او د پورته بیان شوي غوره تنظیماتو غوره کولو پروسه تکرار کړئ.
پایلې
د Fluentd محصول بفر ښه تنظیم کول د EFK سټیک تنظیم کولو یو له اصلي مرحلو څخه دی ، د دې عملیاتو ثبات او په شاخصونو کې د اسنادو سم ځای په ځای کول ټاکل. د بیان شوي ترتیب کولو الګوریتم پراساس ، تاسو ډاډه اوسئ چې ټولې لاګونه به په سم ترتیب کې د ElasticSearch شاخص ته ولیکل شي ، پرته له تکرار یا زیانونو.
زموږ په بلاګ کې نورې مقالې هم ولولئ:
سرچینه: www.habr.com