වර්තමානයේ, පොකුරේ යෙදුම් සහ පද්ධති සංරචක යන දෙකෙහිම ලඝු-සටහන් සුරකින ELK තොගය නොමැතිව Kubernetes මත පදනම් වූ ව්‍යාපෘතියක් සිතාගත නොහැකිය. අපගේ භාවිතයේදී, අපි Logstash වෙනුවට Fluentd සමඟ EFK තොගය භාවිතා කරමු.
Fluentd යනු නවීන, විශ්වීය ලොග් එකතුකරන්නෙකු වන අතර එය වඩ වඩාත් ජනප්‍රිය වෙමින් පවතින අතර Cloud Native Computing Foundation හා සම්බන්ධ වී ඇත, එම නිසා එහි සංවර්ධන දෛශිකය Kubernetes සමඟ ඒකාබද්ධව භාවිතය කෙරෙහි අවධානය යොමු කර ඇත.
Logstash වෙනුවට Fluentd භාවිතා කිරීමේ කාරණය මෘදුකාංග පැකේජයේ සාමාන්‍ය සාරය වෙනස් නොකරයි, කෙසේ වෙතත්, Fluentd එහි බහුකාර්යතාව හේතුවෙන් එහි විශේෂිත සූක්ෂ්මතාවයන් මගින් සංලක්ෂිත වේ.
උදාහරණයක් ලෙස, අපි ලොග් කිරීමේ ඉහළ තීව්‍රතාවයක් සහිත කාර්යබහුල ව්‍යාපෘතියක EFK භාවිතා කිරීමට පටන් ගත් විට, කිබානා හි සමහර පණිවිඩ කිහිප වතාවක් නැවත නැවතත් ප්‍රදර්ශනය වීම අපට මුහුණ දීමට සිදු විය. මෙම සංසිද්ධිය සිදුවන්නේ ඇයි සහ ගැටළුව විසඳන්නේ කෙසේද යන්න මෙම ලිපියෙන් අපි ඔබට කියමු.
ලේඛන අනුපිටපත් කිරීමේ ගැටලුව
අපගේ ව්‍යාපෘතිවල, Fluentd DaemonSet ලෙස යොදවා ඇත (කුබර්නෙටස් පොකුරේ එක් එක් නෝඩය මත එක් අවස්ථාවක ස්වයංක්‍රීයව දියත් කෙරේ) සහ /var/log/containers හි stdout බහාලුම් ලොග් නිරීක්ෂණය කරයි. එකතු කිරීම සහ සැකසීමෙන් පසුව, ව්‍යාපෘතියේ පරිමාණය සහ කාර්ය සාධනය සහ දෝෂ ඉවසීමේ අවශ්‍යතා මත පදනම්ව, JSON ලේඛන ආකාරයෙන් ලොග්, පොකුරු හෝ ස්වාධීන ආකාරයෙන් මතුකර ElasticSearch වෙත යවනු ලැබේ. Kibana චිත්රක අතුරුමුහුණත ලෙස භාවිතා කරයි.
ප්‍රතිදාන බෆරින් ප්ලගිනයක් සමඟ 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"ඉලාස්ටික් සෙවුමට request_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 ප්‍රතිදාන බෆරය ප්‍රමාණවත් ප්‍රමාණයකින් සහ ඒ සමගම නියමිත කාලය තුළ නිෂ්කාශනය කිරීමට කළමනාකරණය කරන්න.
පහත සාකච්ඡා කර ඇති පරාමිතිවල අගයන් ප්‍රතිදාන ප්ලගීන වල බෆරින් භාවිතා කිරීමේ එක් එක් විශේෂිත අවස්ථාවන්හි තනි බව සඳහන් කිරීම වටී, ඒවා බොහෝ සාධක මත රඳා පවතී: සේවා අනුව ලොගයට පණිවිඩ ලිවීමේ තීව්‍රතාවය, තැටි පද්ධති ක්‍රියාකාරිත්වය, ජාලය. නාලිකා පැටවීම සහ එහි කලාප පළල. එමනිසා, එක් එක් අවස්ථාව සඳහා සුදුසු නමුත් අනවශ්‍ය නොවන, දිගු සෙවීම් අන්ධ ලෙස වළක්වා, බෆර සැකසුම් ලබා ගැනීම සඳහා, ඔබට ක්‍රියාත්මක වන විට 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_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 පරාමිතිය මඟින් සකසා ඇති කාලයට වඩා වැඩි කාලයක් ගත වූ බවයි. මෙය නිදොස් කිරීමේ තොරතුරු වන අතර request_timeout පරාමිතියේ අගය තෝරාගැනීමේදී අපි එය භාවිතා කරමු.
සාමාන්‍ය තේරීම් ඇල්ගොරිතම පහත පරිදි වේ:
- අවශ්‍ය ප්‍රමාණයට වඩා (තත්පර සිය ගණනක්) සහතික කළ අගයකට request_timeout සකසන්න. සැකසුම අතරතුර, මෙම පරාමිතිය නිවැරදිව සැකසීම සඳහා ප්රධාන නිර්ණායකය වනුයේ කල් ඉකුත් වීමේ හිඟය පිළිබඳ අනතුරු ඇඟවීම් අතුරුදහන් වීමයි.
- slow_flush_log_threshold threshold ඉක්මවීම පිළිබඳ පණිවිඩ සඳහා රැඳී සිටින්න. elapsed_time ක්ෂේත්‍රයේ ඇති අනතුරු ඇඟවීමේ පාඨය බෆරය හිස් කළ සැබෑ වේලාව පෙන්වයි.
- නිරීක්ෂණ කාල සීමාව තුළ ලබා ගත් උපරිම ගත වූ_කාල අගයට වඩා වැඩි අගයකට ඉල්ලීම_කාලසීමාව සකසන්න. අපි request_timeout අගය elapsed_time + 50% ලෙස ගණනය කරමු.
- ලොගයෙන් දිගු බෆර් ෆ්ලෂ් පිළිබඳ අනතුරු ඇඟවීම් ඉවත් කිරීමට, ඔබට slow_flush_log_threshold හි අගය ඉහළ නැංවිය හැක. අපි මෙම අගය elapsed_time + 25% ලෙස ගණනය කරමු.
මෙම පරාමිතීන්ගේ අවසාන අගයන්, කලින් සඳහන් කළ පරිදි, එක් එක් සිද්ධිය සඳහා තනි තනිව ලබා ගනී. ඉහත ඇල්ගොරිතම අනුගමනය කිරීමෙන්, නැවත නැවත පණිවිඩ යැවීමට හේතු වන දෝෂය ඉවත් කිරීමට අපට සහතික වේ.
ඉහත විස්තර කර ඇති පරාමිතිවල අගයන් තේරීමේ ක්‍රියාවලියේදී පණිවිඩ අනුපිටපත් කිරීමට තුඩු දෙන දිනකට දෝෂ ගණන වෙනස් වන ආකාරය පහත වගුවේ දැක්වේ:
node-1
node-2
node-3
node-4
පෙර පසු
පෙර පසු
පෙර පසු
පෙර පසු
බෆරය ෆ්ලෂ් කිරීමට අසමත් විය
1749/2
694/2
47/0
1121/2
නැවත උත්සාහ කිරීම සාර්ථක විය
410/2
205/1
24/0
241/2
ව්‍යාපෘතිය වර්ධනය වන විට ලැබෙන සැකසුම් වලට අදාළත්වය නැති විය හැකි බවත්, ඒ අනුව, ලොග් ගණන වැඩි වන බවත් සඳහන් කිරීම වටී. ප්‍රමාණවත් නොවන කාල සීමාවේ මූලික සලකුණ වන්නේ දිගු බෆර ෆ්ලෂ් එකක් පිළිබඳ පණිවිඩ Fluentd ලොගය වෙත නැවත පැමිණීමයි, එනම් slow_flush_log_threshold threshold ඉක්මවීමයි. මෙතැන් සිට, request_timeout පරාමිතිය ඉක්මවා යාමට පෙර කුඩා ආන්තිකයක් තවමත් පවතී, එබැවින් මෙම පණිවිඩ වලට නියමිත වේලාවට ප්‍රතිචාර දැක්වීම සහ ඉහත විස්තර කර ඇති ප්‍රශස්ත සැකසුම් තේරීමේ ක්‍රියාවලිය නැවත කිරීම අවශ්‍ය වේ.
නිගමනය
Fluentd ප්‍රතිදාන බෆරය සියුම්ව සකස් කිරීම EFK තොගය වින්‍යාස කිරීමේ ප්රධාන අදියරයන්ගෙන් එකකි, එහි ක්‍රියාකාරිත්වයේ ස්ථායිතාව සහ දර්ශකවල ලේඛන නිවැරදිව ස්ථානගත කිරීම තීරණය කරයි. විස්තර කර ඇති වින්‍යාස ඇල්ගොරිතම මත පදනම්ව, පුනරාවර්තන හෝ පාඩු නොමැතිව, සියලුම ලඝු-සටහන් නිවැරදි අනුපිළිවෙලට ElasticSearch දර්ශකයට ලියා ඇති බවට ඔබට සහතික විය හැක.
අපගේ බ්ලොග් අඩවියේ වෙනත් ලිපිද කියවන්න:
මූලාශ්රය: www.habr.com