Nú á dögum er ómögulegt að ímynda sér Kubernetes-undirstaða verkefni án ELK stafla, sem vistar annála bæði forrita og kerfishluta klasans. Í starfi okkar notum við EFK stafla með Fluentd í stað Logstash.
Fluentd er nútímalegur, alhliða annálasafnari sem nýtur sífellt meiri vinsælda og hefur gengið til liðs við Cloud Native Computing Foundation, sem er ástæðan fyrir því að þróunarvektor hans einbeitir sér að notkun í tengslum við Kubernetes.
Sú staðreynd að nota Fluentd í stað Logstash breytir ekki almennum kjarna hugbúnaðarpakkans, hins vegar einkennist Fluentd af eigin sérstökum blæbrigðum sem stafa af fjölhæfni hans.
Til dæmis, þegar við byrjuðum að nota EFK í annasömu verkefni með mikilli skógarhögg, stóðum við frammi fyrir því að í Kibana voru nokkur skilaboð birt ítrekað nokkrum sinnum. Í þessari grein munum við segja þér hvers vegna þetta fyrirbæri á sér stað og hvernig á að leysa vandamálið.
Vandamálið við fjölföldun skjala
Í verkefnum okkar er Fluentd notað sem DaemonSet (sjálfkrafa ræst í einu tilviki á hverjum hnút í Kubernetes klasanum) og fylgist með stdout gámaskrám í /var/log/containers. Eftir söfnun og vinnslu eru annálarnir í formi JSON skjala sendir til ElasticSearch, aldir upp í klasa eða sjálfstæðu formi, allt eftir umfangi verkefnisins og kröfum um frammistöðu og bilanaþol. Kibana er notað sem grafískt viðmót.
Þegar Fluentd var notað með úttaksbufferunarviðbót, lentum við í aðstæðum þar sem sum skjöl í ElasticSearch höfðu nákvæmlega sama innihald og voru aðeins mismunandi hvað varðar auðkenni. Þú getur staðfest að þetta sé endurtekning skilaboða með því að nota Nginx log sem dæmi. Í annálaskránni eru þessi skilaboð til í einu eintaki:
127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -Hins vegar eru nokkur skjöl í ElasticSearch sem innihalda þessi skilaboð:
{
"_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"
}
}Þar að auki geta verið fleiri en tvær endurtekningar.
Þegar þú lagar þetta vandamál í Fluentd logs geturðu séð fjölda viðvarana með eftirfarandi efni:
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"Þessar viðvaranir eiga sér stað þegar ElasticSearch getur ekki skilað svari við beiðni innan þess tíma sem tilgreint er af færibreytunni request_timeout, sem er ástæðan fyrir því að ekki er hægt að hreinsa framsenda biðminni. Eftir þetta reynir Fluentd að senda biðminni til ElasticSearch aftur og eftir handahófskenndan fjölda tilrauna lýkur aðgerðinni með góðum árangri:
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"Hins vegar, ElasticSearch meðhöndlar hvert af yfirfærðu biðminni sem einstakt og úthlutar þeim einstökum _id reitgildum meðan á flokkun stendur. Svona birtast afrit af skilaboðum.
Í Kibana lítur þetta svona út:
Lausnin
Það eru nokkrir möguleikar til að leysa þetta vandamál. Einn þeirra er vélbúnaðurinn sem er innbyggður í fluent-plugin-elasticsearch viðbótina til að búa til einstakt kjötkássa fyrir hvert skjal. Ef þú notar þetta kerfi mun ElasticSearch þekkja endurtekningar á framsendingarstigi og koma í veg fyrir tvítekin skjöl. En við verðum að taka með í reikninginn að þessi aðferð til að leysa vandamálið er í erfiðleikum með rannsóknina og útilokar ekki villuna með skort á tímamörkum, svo við hættum að nota hana.
Við notum stuðpúðaviðbót á Fluentd úttakinu til að koma í veg fyrir tap á skráningu ef upp koma skammtímavandamál á netinu eða aukinn skráningarstyrkur. Ef ElasticSearch af einhverjum ástæðum getur ekki skrifað skjal samstundis í skrána er skjalið í biðröð og geymt á disknum. Þess vegna, í okkar tilviki, til þess að útrýma upptökum vandamálsins sem leiðir til villunnar sem lýst er hér að ofan, er nauðsynlegt að stilla rétt gildi fyrir biðminni, þar sem Fluentd úttaksbuffinn verður nægilega stór og á sama tíma ná að hreinsa út á tilsettum tíma.
Það er athyglisvert að gildi færibreytanna sem fjallað er um hér að neðan eru einstaklingsbundin í hverju sérstöku tilviki við notkun biðminni í úttaksviðbótum, þar sem þau eru háð mörgum þáttum: styrkleiki þess að skrifa skilaboð í notendaskrána eftir þjónustu, afköst diskkerfisins, netkerfi. rásarálag og bandbreidd hennar. Þess vegna, til að fá biðminni stillingar sem henta hverju einstöku tilviki, en ekki óþarfar, til að forðast langa leit í blindni, geturðu notað villuleitarupplýsingarnar sem Fluentd skrifar í notendaskrá sína meðan á aðgerð stendur og tiltölulega fljótt fengið rétt gildi.
Þegar vandamálið var skráð leit uppsetningin svona út:
<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>Þegar vandamálið var leyst voru gildi eftirfarandi færibreyta valin handvirkt:
chunk_limit_size — stærð klumpanna sem skilaboðum í biðminni er skipt í.
- flush_interval — tímabil þar sem biðminni er hreinsað.
- queue_limit_length — hámarksfjöldi bita í biðröðinni.
- request_timeout er tíminn sem tengingin milli Fluentd og ElasticSearch er komin á.
Hægt er að reikna heildarstærð biðminni með því að margfalda færibreyturnar queue_limit_length og chunk_limit_size, sem má túlka sem „hámarksfjölda bita í biðröðinni, sem hver um sig hefur tiltekna stærð. Ef biðminni er ófullnægjandi mun eftirfarandi viðvörun birtast í annálunum:
2020-01-21 10:22:57 +0000 [warn]: [test-prod] failed to write data into buffer by buffer overflow action=:blockÞað þýðir að biðminni hefur ekki tíma til að hreinsa á tilsettum tíma og gögnin sem fara inn í fullan biðminni eru læst, sem mun leiða til taps á hluta af annálunum.
Þú getur aukið biðminni á tvo vegu: með því að auka annaðhvort stærð hvers hluta í röðinni, eða fjölda bita sem geta verið í röðinni.
Ef þú stillir chunk size chunk_limit_size á meira en 32 megabæti, þá mun ElasticSeacrh ekki samþykkja það, þar sem pakkinn sem kemur inn verður of stór. Þess vegna, ef þú þarft að auka biðminni frekar, er betra að auka hámarkslengd biðröð queue_limit_length.
Þegar biðminni hættir að flæða yfir og aðeins ófullnægjandi skilaboð eru eftir, geturðu byrjað að auka færibreytuna request_timeout. Hins vegar, ef þú stillir gildið á meira en 20 sekúndur, munu eftirfarandi viðvaranir byrja að birtast í Fluentd logs:
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" Þessi skilaboð hafa ekki áhrif á virkni kerfisins á neinn hátt og þýðir að biðminnisskolunartíminn tók lengri tíma en stillt var af slow_flush_log_threshold færibreytunni. Þetta eru villuleitarupplýsingar og við notum þær þegar við veljum gildi færibreytunnar request_timeout.
Almennt val reiknirit er sem hér segir:
- Stilltu request_timeout á gildi sem tryggt er að sé hærra en nauðsynlegt er (hundruð sekúndna). Við uppsetningu er aðalviðmiðunin fyrir rétta stillingu þessarar færibreytu að viðvaranir hverfa vegna skorts á tímamörkum.
- Bíddu eftir skilaboðum um að fara yfir slow_flush_log_threshold þröskuldinn. Viðvörunartextinn í reitnum elapsed_time mun sýna rauntíma biðminni var hreinsaður.
- Stilltu request_timeout á gildi sem er hærra en hámarks lapsed_time gildi sem fæst á athugunartímabilinu. Við reiknum út request_timeout gildið sem liðinn_tími + 50%.
- Til að fjarlægja viðvaranir um langa biðminnisskolun úr skránni geturðu hækkað gildi slow_flush_log_threshold. Við reiknum þetta gildi sem liðinn_tími + 25%.
Lokagildi þessara breytu, eins og áður hefur komið fram, eru fengin fyrir sig fyrir hvert tilvik. Með því að fylgja ofangreindu reikniritinu erum við tryggð að útrýma villunni sem leiðir til endurtekinna skilaboða.
Taflan hér að neðan sýnir hvernig fjöldi villna á dag, sem leiðir til fjölföldunar skilaboða, breytist í því ferli að velja gildi færibreytanna sem lýst er hér að ofan:
hnútur-1
hnútur-2
hnútur-3
hnútur-4
Áður eftir
Áður eftir
Áður eftir
Áður eftir
tókst ekki að skola biðminni
1749/2
694/2
47/0
1121/2
aftur tókst
410/2
205/1
24/0
241/2
Það er þess virði að hafa í huga að stillingarnar sem myndast geta tapað mikilvægi sínu eftir því sem verkefnið stækkar og í samræmi við það eykst fjöldi annála. Aðalmerki um ófullnægjandi tímamörk er að skila skilaboðum um langa biðminni í Fluentd log, það er að fara yfir slow_flush_log_threshold þröskuldinn. Frá þessum tímapunkti er enn lítil framlegð áður en farið er yfir færibreytuna request_timeout, svo það er nauðsynlegt að svara þessum skilaboðum tímanlega og endurtaka ferlið við að velja bestu stillingarnar sem lýst er hér að ofan.
Ályktun
Fínstilling á Fluentd úttaksbuffi er eitt af helstu stigum stillingar EFK stafla, ákvarða stöðugleika starfsemi hans og rétta staðsetningu skjala í vísitölum. Byggt á uppsetningaralgríminu sem lýst er, geturðu verið viss um að allar annálar verði skrifaðar í ElasticSearch vísitöluna í réttri röð, án endurtekningar eða taps.
Lestu einnig aðrar greinar á blogginu okkar:
Heimild: www.habr.com