Logid Kubernetesis (ja mitte ainult) täna: ootused ja tegelikkus

On aasta 2019 ja meil pole ikka veel Kuberneteses logide liitmiseks standardlahendust. Selles artiklis soovime reaalse praktika näidete põhjal jagada oma otsinguid, tekkinud probleeme ja nende lahendusi.

Esmalt teen siiski broneeringu, et erinevad kliendid saavad logide kogumise kaudu väga erinevalt aru:

• keegi soovib näha turva- ja auditiloge;
• keegi - kogu infrastruktuuri tsentraliseeritud logimine;
• ja mõne jaoks piisab ainult rakenduste logide kogumisest, välja arvatud näiteks tasakaalustajad.

Allpool on väljalõige selle kohta, kuidas me rakendasime erinevaid soovinimekirju ja milliseid raskusi me kokku puutusime.

Teooria: logimistööriistade kohta

Logisüsteemi komponentide taust

Raie on jõudnud kaugele, mille tulemusena on välja töötatud metoodikad palkide kogumiseks ja analüüsimiseks, mida me täna kasutame. 1950. aastatel tutvustas Fortran standardsete sisend-/väljundvoogude analoogi, mis aitas programmeerijal oma programmi siluda. Need olid esimesed arvutilogid, mis muutsid tollaste programmeerijate elu lihtsamaks. Täna näeme neis logisüsteemi esimest komponenti - palkide allikas või tootja.

Arvutiteadus ei jäänud seisma: tekkisid arvutivõrgud, esimesed klastrid... Tööle hakkasid mitmest arvutist koosnevad keerulised süsteemid. Nüüd olid süsteemiadministraatorid sunnitud koguma logisid mitmest masinast ja erijuhtudel said nad lisada OS-i tuuma teateid juhuks, kui neil oli vaja süsteemitõrget uurida. Tsentraliseeritud logikogumissüsteemide kirjeldamiseks avaldati see 2000. aastate alguses RFC 3164, mis standardiseeris remote_syslogi. Nii ilmus veel üks oluline komponent: palgikoguja ja nende ladustamine.

Logide mahu suurenemise ja veebitehnoloogiate laialdase kasutuselevõtuga tekkis küsimus, milliseid logisid on vaja mugavalt kasutajatele näidata. Lihtsad konsoolitööriistad (awk/sed/grep) on asendatud täiustatud tööriistadega logi vaatajad - kolmas komponent.

Seoses palgimahu suurenemisega selgus veel midagi: palke on vaja, aga mitte kõiki. Ja erinevad palgid nõuavad erinevat säilitusastet: mõned võivad kaduda ühe päevaga, teised tuleb säilitada 5 aastat. Niisiis lisati logisüsteemile andmevoogude filtreerimise ja marsruutimise komponent - nimetagem seda filter.

Ka salvestus on teinud suure hüppe: tavafailidelt relatsiooniandmebaasidele ja seejärel dokumendile orienteeritud salvestusele (näiteks Elasticsearch). Seega eraldati hoidla kollektorist.

Lõppkokkuvõttes on palgi mõiste laienenud omamoodi abstraktseks sündmuste vooluks, mida tahame ajaloo jaoks säilitada. Või õigemini juhuks, kui on vaja läbi viia uurimine või koostada analüütiline aruanne...

Selle tulemusena on logide kogumisest suhteliselt lühikese aja jooksul kujunenud oluline alamsüsteem, mida võib õigustatult nimetada üheks Big Data alajaotuseks.

Kui kunagi ammu piisas tavalistest väljatrükkidest “logisüsteemiks”, siis nüüd on olukord palju muutunud.

Kubernetes ja palgid

Kui Kubernetes taristu juurde tuli, ei läinud sellest mööda ka juba eksisteeriv palkide kogumise probleem. Mõnes mõttes läks see veelgi valusamaks: taristuplatvormi haldamine ei olnud mitte ainult lihtsustatud, vaid samal ajal ka keeruline. Paljud vanad teenused on hakanud migreeruma mikroteenustele. Logide kontekstis väljendub see logiallikate kasvavas arvus, nende erilises elutsüklis ning vajaduses jälgida logide kaudu kõigi süsteemikomponentide seoseid...

Tulevikku vaadates võin tõdeda, et praegu pole kahjuks Kubernetese jaoks standardiseeritud logimisvõimalust, mis oleks kõigi teistega soodsalt võrreldav. Kõige populaarsemad skeemid kogukonnas on järgmised:

• keegi rullib virna lahti EFK (Elasticsearch, Fluentd, Kibana);
• keegi proovib hiljuti välja antud Loki või kasutab Raieoperaator;
• meie (ja võib-olla mitte ainult meie?..) Olen enda arenguga suures osas rahul - palkmaja...

Reeglina kasutame K8s klastrites (isehostitud lahenduste jaoks) järgmisi komplekte:

• Fluentd + Elasticsearch + Kibana;
• Fluentd + ClickHouse + palkmaja.

Kuid ma ei peatu nende paigaldamise ja seadistamise juhistes. Selle asemel keskendun nende puudustele ja globaalsematele järeldustele palkide olukorra kohta üldiselt.

Harjutage palkidega K8s

"Igapäevased palgid", kui palju teid on?...

Tsentraliseeritud logide kogumine üsna suurest infrastruktuurist nõuab märkimisväärseid ressursse, mis kulub logide kogumisele, säilitamisele ja töötlemisele. Erinevate projektide käigus puutusime kokku erinevate nõuete ja nendest tulenevate tegevusprobleemidega.

Proovime ClickHouse'i

Vaatame projekti tsentraliseeritud salvestusruumi rakendusega, mis genereerib logisid üsna aktiivselt: rohkem kui 5000 rida sekundis. Alustame tööd tema logidega, lisades need ClickHouse'i.

Niipea, kui on vaja maksimaalset reaalajas, on ClickHouse'iga 4-tuumaline server ketta alamsüsteemis juba ülekoormatud:

Seda tüüpi laadimine on tingitud asjaolust, et proovime ClickHouse'is võimalikult kiiresti kirjutada. Ja andmebaas reageerib sellele suurenenud kettakoormusega, mis võib põhjustada järgmisi vigu:

DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts

Fakt on see, et MergeTree tabelid ClickHouse'is (need sisaldavad logiandmeid) on kirjutamistoimingute ajal oma raskused. Neisse sisestatud andmed loovad ajutise partitsiooni, mis seejärel liidetakse põhitabeliga. Selle tulemusena osutub salvestamine kettale väga nõudlikuks ja sellele kehtib ka piirang, mille kohta saime ülaltoodud teate: 1 sekundiga ei saa liita rohkem kui 300 alamsektsiooni (tegelikult on see 300 sisestust sekundis).

Sellise käitumise vältimiseks peaks ClickHouse'ile kirjutama võimalikult suurte tükkidena ja mitte rohkem kui 1 kord iga 2 sekundi järel. Suurte sarivõtete kirjutamine viitab aga sellele, et peaksime ClickHouse'is harvemini kirjutama. See võib omakorda kaasa tuua puhvri ületäitumise ja logide kadumise. Lahenduseks on Fluentd puhvri suurendamine, kuid siis suureneb ka mälukulu.

Märkus: Meie ClickHouse'i lahenduse teine ​​probleemne aspekt oli seotud asjaoluga, et partitsioonid on meie puhul (palkmaja) realiseeritud läbi ühendatud väliste tabelite. Ühenda tabel. See toob kaasa asjaolu, et suurte ajavahemike proovide võtmisel on vaja liigset RAM-i, kuna metatabel itereerib läbi kõik partitsioonid - isegi need, mis ilmselgelt vajalikke andmeid ei sisalda. Kuid nüüd võib selle lähenemisviisi ClickHouse'i praeguste versioonide jaoks ohutult aegunuks kuulutada (c 18.16).

Selle tulemusena saab selgeks, et mitte igal projektil pole piisavalt ressursse, et ClickHouse'is reaalajas logisid koguda (täpsemalt pole nende levitamine sobiv). Lisaks peate kasutama akumulaator, mille juurde tuleme hiljem tagasi. Eespool kirjeldatud juhtum on tõeline. Ja toona ei suutnud me pakkuda usaldusväärset ja stabiilset lahendust, mis kliendile sobiks ja võimaldaks minimaalse viivitusega palke kokku koguda...

Aga Elasticsearch?

Elasticsearch talub teadaolevalt suuri töökoormusi. Proovime seda samas projektis. Nüüd näeb koormus välja selline:

Elasticsearch suutis andmevoo seedida, kuid selliste mahtude kirjutamine kasutab palju protsessorit. See otsustatakse klastri korraldamisega. Tehniliselt pole see probleem, kuid selgub, et ainuüksi logide kogumise süsteemi toimimiseks kasutame juba umbes 8 südamikku ja süsteemis on veel üks kõrgelt koormatud komponent...

Kokkuvõte: see valik võib olla õigustatud, kuid ainult siis, kui projekt on mahukas ja selle juhtkond on valmis kulutama märkimisväärseid ressursse tsentraliseeritud logisüsteemile.

Siis tekib loomulik küsimus:

Milliseid palke on tegelikult vaja?

Proovime lähenemist ise muuta: logid peaksid olema samal ajal informatiivsed ja mitte katma igaüks sündmus süsteemis.

Oletame, et meil on edukas veebipood. Millised logid on olulised? Koguda võimalikult palju teavet, näiteks maksete lüüsist, on suurepärane idee. Kuid mitte kõik pildilõiketeenuse logid tootekataloogis pole meie jaoks kriitilised: piisab ainult vigadest ja täiustatud jälgimisest (näiteks 500 vea protsent, mille see komponent genereerib).

Seega oleme jõudnud järeldusele, et tsentraliseeritud metsaraie ei ole alati õigustatud. Väga sageli soovib klient koguda kõik logid ühte kohta, kuigi tegelikult on kogu logist vaja vaid tingimuslikku 5% ettevõtte jaoks kriitilistest sõnumitest:

• Mõnikord piisab, kui konfigureerida näiteks ainult konteineri logi ja veakoguja suurus (näiteks Sentry).
• Juhtumite uurimiseks võib sageli piisata veateatisest ja suurest kohalikust logist.
• Meil oli projekte, mis said hakkama ainult funktsionaalsete testide ja veakogumissüsteemidega. Arendaja ei vajanud logisid kui selliseid - nad nägid kõike alates veajälgedest.

Illustratsioon elust

Teine lugu võib olla heaks näiteks. Saime päringu ühe meie kliendi turvameeskonnalt, kes kasutas juba ammu enne Kubernetese kasutuselevõttu välja töötatud kommertslahendust.

Tsentraliseeritud logide kogumise süsteemiga oli vaja "sõbraks saada" ettevõtte probleemide tuvastamise anduriga - QRadar. See süsteem saab logisid vastu võtta syslogi protokolli kaudu ja hankida need FTP-st. Siiski ei olnud seda kohe võimalik integreerida fluentd-i remote_syslog pluginaga (nagu selgus, me ei ole üksi). Probleemid QRadari seadistamisega osutusid kliendi turvameeskonna pooleks.

Selle tulemusena laaditi osa ärikriitilistest logidest üles FTP QRadarisse ja teine ​​osa suunati kaugsüslogi kaudu otse sõlmedest. Selle jaoks me isegi kirjutasime lihtne diagramm - ehk aitab see kellelgi sarnast probleemi lahendada... Tänu tekkinud skeemile sai klient ise (oma lemmiktööriistade abil) kriitilisi logisid vastu ja analüüsis ning saime logimissüsteemi maksumust vähendada, säästes vaid Eelmine kuu.

Teine näide näitab, mida mitte teha. Üks meie klientidest töötlemiseks iga kasutajalt tulevad sündmused, tehtud mitmerealine struktureerimata väljund info logis. Nagu arvata võis, oli selliseid logisid nii lugeda kui ka salvestada äärmiselt ebamugav.

Palkide kriteeriumid

Sellised näited viivad järeldusele, et lisaks palgikogumissüsteemi valimisele peate seda tegema kujundada ka palgid ise! Millised on siin nõuded?

• Logid peavad olema masinloetavas vormingus (nt JSON).
• Logid peaksid olema kompaktsed ja logimisastet muutma, et võimalikke probleeme siluda. Samal ajal peaksite tootmiskeskkondades käivitama süsteeme logimistasemega nagu Hoiatus või viga.
• Logid peavad olema normaliseeritud, st logiobjektis peavad kõik read olema sama väljatüübiga.

Struktureerimata palgid võivad põhjustada probleeme palkide lattu laadimisel ja nende töötlemise täieliku peatamise. Näitena on siin näide veaga 400, mida paljud on Fluentd logides kindlasti kohanud:

2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"

Viga tähendab, et saadate valmis vastendusega indeksisse välja, mille tüüp on ebastabiilne. Lihtsaim näide on muutujaga väli nginxi logis $upstream_status. See võib sisaldada kas numbrit või stringi. Näiteks:

{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"}
{ "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}

Logid näitavad, et server 10.100.0.10 vastas tõrkega 404 ja päring saadeti teise sisumälu. Selle tulemusena muutus logide väärtus järgmiseks:

"upstream_response_time": "0.001, 0.007"

See olukord on nii tavaline, et väärib isegi eraldi viited dokumentatsioonis.

Aga usaldusväärsus?

Mõnikord on kõik logid ilma eranditeta elutähtsad. Ja sellega on ülal pakutud/arutatud tüüpilistel K8-de logikogumisskeemidel probleeme.

Näiteks fluentd ei saa koguda palke lühiealistest konteineritest. Ühes meie projektis elas andmebaasi migratsiooni konteiner vähem kui 4 sekundit ja seejärel kustutati - vastavalt vastavale märkusele:

"helm.sh/hook-delete-policy": hook-succeeded

Seetõttu ei kaasatud salvestusruumi migratsiooni käivituslogi. Sel juhul saab poliitikast abi. before-hook-creation.

Teine näide on Dockeri logi pööramine. Oletame, et on olemas rakendus, mis kirjutab aktiivselt logidesse. Tavatingimustes õnnestub meil kõiki logisid töödelda, kuid niipea, kui ilmneb probleem – näiteks nagu eespool kirjeldatud vale vormingu puhul – töötlemine peatub ja Docker pöörab faili. Tulemuseks on see, et ärikriitilised logid võivad kaduda.

Sellepärast oluline on logivoogude eraldamine, manustades kõige väärtuslikumad otse rakendusse, et tagada nende ohutus. Lisaks poleks üleliigne mõne loomine palkide “akumulaator”., mis võib kriitilisi sõnumeid salvestades üle elada lühiajalise salvestusruumi puudumise.

Lõpuks ei tohi me seda unustada Oluline on mis tahes alamsüsteemi korralikult jälgida. Vastasel juhul on lihtne sattuda olukorda, kus fluentd on olekus CrashLoopBackOff ja ei saada midagi ning see tõotab olulise teabe kadumist.

Järeldused

Selles artiklis me ei käsitle SaaS-i lahendusi, nagu Datadog. Paljud siin kirjeldatud probleemid on logide kogumisele spetsialiseerunud äriettevõtete poolt ühel või teisel viisil juba lahendatud, kuid kõik ei saa erinevatel põhjustel SaaS-i kasutada (peamised on maksumus ja vastavus standardile 152-FZ).

Tsentraliseeritud logikogumine näib esmapilgul lihtne ülesanne, kuid see pole sugugi nii. Oluline on meeles pidada, et:

• Üksikasjalikult tuleb logida ainult kriitilised komponendid, samas kui jälgimist ja vigade kogumist saab konfigureerida teiste süsteemide jaoks.
• Tootmises tuleks palke hoida minimaalsena, et mitte lisada tarbetut koormust.
• Logid peavad olema masinloetavad, normaliseeritud ja range vorminguga.
• Tõeliselt kriitilised logid tuleks saata eraldi voos, mis tuleks peamistest eraldada.
• Tasub kaaluda palgiakumulaatorit, mis võib säästa suure koormuse purunemisest ja muuta lao koormuse ühtlasemaks.

Need lihtsad reeglid, kui neid kõikjal rakendada, võimaldaksid ülalkirjeldatud ahelatel töötada – kuigi neil puuduvad olulised komponendid (aku). Kui te sellistest põhimõtetest kinni ei pea, juhatab ülesanne teid ja taristut kergesti mõne teise suure koormusega (ja samal ajal ebatõhusa) süsteemi komponendi juurde.

PS

Loe ka meie blogist:

• «Tutvustame palkmaja – avatud lähtekoodiga süsteemi Kubernetes palkidega töötamiseks";
• «Kubernetese ökosüsteemi versioonid KubeCon'19-st: JFrog Container Registry, Kui IBM-ilt, Loki 1.0.0…";
• «Jälgimine ja Kubernetes (ülevaade ja videoaruanne)'.

Allikas: www.habr.com