Hautdesdaags ass et onméiglech e Kubernetes-baséiert Projet virzestellen ouni den ELK Stack, dee Logbicher vu béiden Uwendungen a Systemkomponente vum Cluster späichert. An eiser Praxis benotze mir den EFK Stack mat Fluentd anstatt Logstash.
Fluentd ass e modernen, universellen Log Sammler, dee méi a méi Popularitéit gewënnt an an der Cloud Native Computing Foundation ugeschloss ass, dofir ass säin Entwécklungsvektor op d'Benotzung a Verbindung mat Kubernetes fokusséiert.
De Fakt fir Fluentd ze benotzen anstatt Logstash ännert d'allgemeng Essenz vum Softwarepaket net, awer Fluentd ass charakteriséiert duerch seng eege spezifesch Nuancen, déi aus senger Villsäitegkeet entstinn.
Zum Beispill, wa mir ugefaang hunn EFK an engem beschäftegten Projet mat enger héijer Intensitéit vum Logbuch ze benotzen, ware mir mat der Tatsaach konfrontéiert datt zu Kibana e puer Messagen ëmmer erëm e puer Mol ugewise goufen. An dësem Artikel wäerte mir Iech soen firwat dëst Phänomen geschitt a wéi Dir de Problem léist.
De Problem vun Dokument Duplikatioun
An eise Projete gëtt Fluentd als DaemonSet ofgesat (automatesch an enger Instanz op all Node vum Kubernetes Cluster gestart) a kontrolléiert stdout Container Logbicher an /var/log/containers. No der Sammlung an der Veraarbechtung ginn d'Logbicher a Form vun JSON Dokumenter op ElasticSearch geschéckt, a Cluster oder Standalone Form opgeworf, ofhängeg vun der Skala vum Projet an den Ufuerderunge fir Leeschtung a Feelertoleranz. Kibana gëtt als grafesch Interface benotzt.
Wann Dir Fluentd mat engem Output Puffer Plugin benotzt, hu mir eng Situatioun begéint, wou e puer Dokumenter an ElasticSearch genau deeselwechten Inhalt haten an nëmmen am Identifizéierer ënnerscheeden. Dir kënnt verifizéieren datt dëst eng Message-Wiederhuelung ass mam Nginx Log als Beispill. An der Log Datei existéiert dëse Message an enger eenzeger Kopie:
127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -Wéi och ëmmer, et gi verschidde Dokumenter an ElasticSearch déi dëse Message enthalen:
{
"_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"
}
}Ausserdeem kënnen et méi wéi zwee Wiederholungen sinn.
Wärend Dir dëse Problem an de Fluentd Logbicher fixéiert, kënnt Dir eng grouss Zuel vu Warnungen mat dem folgenden Inhalt gesinn:
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"Dës Warnunge geschéien wann ElasticSearch keng Äntwert op eng Ufro bannent der Zäit uginn, déi vum request_timeout Parameter spezifizéiert ass, kann net zréckginn, dofir kann dat fortgeschratt Pufferfragment net geläscht ginn. Duerno probéiert Fluentd de Pufferfragment op ElasticSearch erëm ze schécken an no enger arbiträrer Unzuel vu Versich ass d'Operatioun erfollegräich ofgeschloss:
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"Wéi och ëmmer, ElasticSearch behandelt jiddereng vun den transferéierte Pufferfragmenter als eenzegaarteg a gëtt hinnen eenzegaarteg _id Feldwäerter wärend der Indexéierung zou. Dëst ass wéi Kopie vu Messagen erschéngen.
Zu Kibana gesäit et esou aus:
Problem mat der Problembehandlung
Et gi verschidde Méiglechkeeten fir dëse Problem ze léisen. Ee vun hinnen ass de Mechanismus, deen an de fléissende-Plugin-elasticsearch Plugin gebaut ass fir en eenzegaartegen Hash fir all Dokument ze generéieren. Wann Dir dëse Mechanismus benotzt, erkennt ElasticSearch Widderhuelungen an der Forwardstadium a verhënnert duplizéiert Dokumenter. Awer mir musse berücksichtegen datt dës Methode fir de Problem ze léisen mat der Enquête kämpft an de Feeler net mat engem Manktem un Timeout eliminéiert, also hu mir seng Benotzung opginn.
Mir benotzen e Pufferplugin op der Fluentd-Output fir Logverloscht am Fall vu kuerzfristeg Netzwierkproblemer oder erhéicht Logintensitéit ze vermeiden. Wann aus iergendengem Grond ElasticSearch net fäeg ass en Dokument direkt an den Index ze schreiwen, gëtt d'Dokument an der Schlaang gesat an op Disk gespäichert. Dofir, an eisem Fall, fir d'Quell vum Problem ze eliminéieren, deen zum uewe beschriwwene Feeler féiert, ass et néideg déi richteg Wäerter fir d'Pufferparameter ze setzen, bei deenen de Fluentd Ausgangsbuffer genuch Gréisst ass an gläichzäiteg verwalten an der zougewisen Zäit geläscht ginn.
Et ass derwäert ze bemierken datt d'Wäerter vun de Parameteren, déi hei ënnen diskutéiert ginn, individuell sinn an all spezifesche Fall vu Pufferung an Output Plugins, well se vu ville Faktoren ofhänken: d'Intensitéit vum Schreiwen vun Messagen op de Logbuch duerch Servicer, Disk System Leeschtung, Netzwierk Kanalbelaaschtung a seng Bandbreedung. Dofir, fir Puffer-Astellungen ze kréien, déi fir all eenzel Fall gëeegent sinn, awer net iwwerflësseg, laang Sich blann ze vermeiden, kënnt Dir d'Debugging-Informatioun benotzen, déi Fluentd während der Operatioun a säi Logbicher schreift a relativ séier déi richteg Wäerter kritt.
Zu der Zäit wou de Problem opgeholl gouf, huet d'Konfiguratioun esou ausgesinn:
<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>Wann de Problem léisen, goufen d'Wäerter vun de folgende Parameteren manuell ausgewielt:
chunk_limit_size - d'Gréisst vun de Stécker, an déi Messagen am Puffer opgedeelt sinn.
- flush_interval - Zäitintervall no deem de Puffer geläscht gëtt.
- queue_limit_length - déi maximal Unzuel vu Stécker an der Schlaang.
- request_timeout ass d'Zäit fir déi d'Verbindung tëscht Fluentd an ElasticSearch etabléiert ass.
D'total Puffergréisst kann berechent ginn andeems d'Parameteren queue_limit_length an chunk_limit_size multiplizéiert ginn, wat als "déi maximal Unzuel u Stécker an der Schlaang interpretéiert ka ginn, jidderee vun deenen eng gegebene Gréisst huet." Wann d'Puffergréisst net genuch ass, erschéngt déi folgend Warnung an de Logbicher:
2020-01-21 10:22:57 +0000 [warn]: [test-prod] failed to write data into buffer by buffer overflow action=:blockEt heescht datt de Puffer keng Zäit huet fir an der zougewisener Zäit geläscht ze ginn an d'Donnéeën, déi an de vollen Puffer erakommen, blockéiert ginn, wat zum Verloscht vun engem Deel vun de Logbicher féiert.
Dir kënnt de Puffer op zwou Weeër erhéijen: andeems Dir entweder d'Gréisst vun all Stéck an der Schlaang erhéicht, oder d'Zuel vun de Stécker déi an der Schlaang kënne sinn.
Wann Dir d'Chunk Gréisst chunk_limit_size op méi wéi 32 Megabytes setzt, da wäert ElasticSeacrh et net akzeptéieren, well den erakommende Paket ze grouss ass. Dofir, wann Dir de Puffer weider muss erhéijen, ass et besser déi maximal Schlaanglängt ze erhéijen queue_limit_length.
Wann de Puffer ophält mat iwwerflësseg an nëmmen den Timeout net genuch Message bleift, kënnt Dir ufänken den request_timeout Parameter ze erhéijen. Wéi och ëmmer, wann Dir de Wäert op méi wéi 20 Sekonnen setzt, fänken déi folgend Warnungen an de Fluentd Logbicher op:
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" Dëse Message beaflosst op kee Fall d'Operatioun vum System a bedeit datt d'Pufferfluchzäit méi laang gedauert huet wéi de Slow_flush_log_threshold Parameter festgeluecht. Dëst ass Debugging Informatioun a mir benotze se wann Dir de Wäert vum request_timeout Parameter auswielen.
De generaliséierte Selektiounsalgorithmus ass wéi follegt:
- Set request_timeout op e Wäert garantéiert méi grouss wéi néideg (honnerte vu Sekonnen). Wärend der Konfiguratioun ass den Haaptkriterium fir d'korrekt Astellung vun dësem Parameter d'Verschwannen vun Warnungen fir e Manktem un Timeout.
- Waart op Messagen iwwer Iwwerschreiden vun der slow_flush_log_threshold-Schwell. Den Warnungstext am elapsed_time Feld weist d'Echtzäit wou de Puffer geläscht gouf.
- Set request_timeout op e Wäert méi wéi de maximale elapsed_time Wäert deen während der Observatiounsperiod kritt gëtt. Mir berechnen den request_timeout Wäert als elapsed_time + 50%.
- Fir Warnungen iwwer laang Bufferspülen aus dem Log ze läschen, kënnt Dir de Wäert vun slow_flush_log_threshold erhéijen. Mir berechnen dëse Wäert als elapsed_time + 25%.
D'Finale Wäerter vun dëse Parameteren, wéi virdru festgestallt, ginn individuell fir all Fall kritt. Andeems Dir den uewe genannten Algorithmus befollegt, si mir garantéiert de Feeler ze eliminéieren deen zu widderholl Messagen féiert.
D'Tabell hei ënnen weist wéi d'Zuel vun de Feeler pro Dag, déi zu Duplikatioun vu Messagen féiert, Ännerungen am Prozess vun der Auswiel vun de Wäerter vun den uewe beschriwwenen Parameteren:
node-1
node-2
node-3
node-4
Virun duerno
Virun duerno
Virun duerno
Virun duerno
net fäerdeg de Puffer ze spülen
1749/2
694/2
47/0
1121/2
nei Versuch gelongen
410/2
205/1
24/0
241/2
Zousätzlech ass et derwäert ze notéieren datt déi resultéierend Astellungen hir Relevanz verléieren kënnen wéi de Projet wiisst an deementspriechend d'Zuel vun de Logbicher eropgeet. Dat primär Zeechen vun net genuch Timeout ass de Retour vu Messagen iwwer e laange Pufferflush an de Fluentd Log, dat heescht, d'Slow_flush_log_threshold Schwell iwwerschreiden. Vun dësem Punkt un ass et nach ëmmer e klenge Spillraum ier de Request_timeout Parameter iwwerschratt ass, also ass et néideg fir op dës Messagen fristgerecht ze reagéieren an de Prozess ze widderhuelen fir déi uewe beschriwwen optimal Astellungen ze wielen.
Konklusioun
Fine-tuning de Fluentd Output Puffer ass eng vun den Haaptstadien vun der Konfiguratioun vum EFK Stack, Bestëmmung vun der Stabilitéit vu senger Operatioun an der korrekter Plazéierung vun Dokumenter an Indexen. Baséiert op der beschriwwen Configuratioun Algorithmus, kënnt Dir sécher sinn, datt all Logbicher an der richteger Uerdnung op den ElasticSearch Index geschriwwe ginn, ouni Wiederholungen oder Verloschter.
Liest och aner Artikelen op eisem Blog:
Source: will.com