Logid Kuberneteses (ja mitte ainult) täna: ootused ja reaalsus

Aasta 2019 oli käes ja meil polnud ikka veel standardset lahendust logide kogumiseks Kuberneteses. Selles artiklis soovime, kasutades reaalse praktika näiteid, jagada oma otsinguid, kohtatud probleeme ja nende lahendusi.

Siiski soovin alguses märkida, et erinevad kliendid mõistavad logide kogumist väga erinevalt:

• keegi soovib näha turbe- ja auditi logisid;
• keegi – kogu infrastruktuuri tsentraliseeritud logimist;
• aga mõnele piisab vaid rakenduse logide kogumisest, välja arvatud näiteks tasakaalustajad.

Kuidas me erinevaid "soove" realiseerisime ja milliste raskustega silmitsi seisime – loe edasi.

Teooria: logide tööriistadest

Logimisüsteemi komponente käsitlev eelainetus

Logimine on läbinud pika teekonna, mille tulemusena on välja töötatud logide kogumise ja analüüsi metoodikad, mida me tänapäeval kasutame. Juba 1950. aastatel ilmus Fortransse sarnane standardne sisendi- ja väljundi voog, mis aitas programmeerijatel oma programme tõrgete puhul debugida. Need olid esimesed arvutilogid, mis leevendasid toona programmeerijate elu. Tänaseks näeme meis esimese logimisüsteemi komponenti – logide allikas või "tootja" (producer).

Arvutiteadus ei seisa paigal: tekkisid arvutivõrgud, esimesed klastrid... Alguses hakkasid töötama keerukad süsteemid, mis koosnesid mitmest arvutist. Nüüd pidid süsteemiadministraatorid koguma logisid mitmelt masinalt, ja erijuhtudel võisid nad lisada ka operatsioonisüsteemi tuuma sõnumeid, juhuks kui on vaja uurida süsteemi tõrget. Tsentraliseeritud logide kogumise süsteemide kirjeldamiseks ilmus 2000. aastate alguses RFC 3164, mis standardiseerib remote_syslog. Nii ilmus veel üks oluline komponent: logide koguja ja nende salvestus.

Logide mahu suurenemise ja veebitehnoloogiate laialdise kasutuselevõtu tõttu tekkis küsimus, kuidas logisid kasutajatele mugavalt esitada. Lihtsad konsooli tööriistad (awk/sed/grep) asendati arenenumatega logivaaturid — kolmas komponent.

Logide mahu arvestuse suurenemise tõttu on selge ka midagi muud: logid on vajalikud, kuid mitte kõik. Erinevad logid nõuavad erinevat taset säilitamist: ühed võib kaotada päevas, teised tuleb hoida 5 aastat. Nii lisandus logimisüsteemi komponent andmevoogude filtreerimiseks ja marsruutimiseks — kutsume seda filtriks.

Ladustamine on samuti märkimisväärselt edasi arenenud: tavalistest failidest on üle mindud relatsiooniliste andmebaaside ja seejärel dokumentide põhiste ladustamislahenduste (näiteks Elasticsearch) poole. Nii eraldus kogumisest ladustamine.

Lõppkokkuvõttes on logi mõisted laienenud abstraktsesse sündmuste voogu, mida soovime ajaloos säilitada. Täpsemalt — juhul, kui on vaja korraldada uurimist või koostada analüütiline aruanne…

Lõpuks, lühikese aja jooksul on logide kogumine arenenud oluliseks alamsüsteemiks, mida võib õigustatult nimetada Big Data alaseks osaks.

Kui kunagi olid tavalised print'id piisavad „logimissüsteemi” jaoks, siis nüüd on olukord oluliselt muutunud.

Kubernetes ja logid

Kui Kubernetes tuli infrastruktuuri, siis eksisteerinud logide kogumise probleem ei jätnud teda puutumatuks. Teatud mõttes muutus see isegi valusamaks: infrastruktuuri platvormi haldamine oli mitte ainult lihtsustatud, vaid samal ajal keerulisem. Paljud vanad teenused alustasid migreerimist mikroteenuste juhtimisele. Logide kontekstis väljendus see logide allikate arvu suurenemises, nende erilise elutsükli ja vajaduses jälgida kõigi süsteemi komponentide omavahelisi seoseid…

Eelnevale vaates võib öelda, et praegu ei ole kahjuks standardiseeritud logimise varianti Kubernetes'ele, mis eristuks kõigist teistest. Kõige populaarsemad kogukonnas skeemid on järgmised:

• keegi seadistab stack'i EFK (Elasticsearch, Fluentd, Kibana);
• keegi - proovib hiljuti välja antud Loki või kasutab Logging operatorit;
• meid (võib-olla mitte ainult meid? ..) paljuski rahuldab oma arendus — loghouse…

Tavaliselt kasutame selliseid kombinatsioone K8s-klastrites (self-hosted lahenduste jaoks):

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

Kuid ma ei kavatse peatuda nende installimise ja konfigureerimise juhistel. Selle asemel keskendun nende puudustele ja globaalsematele järeldustele logide olukorra kohta üldiselt.

Logide praktika K8s-is

„Igapäevased logid”, kui palju teid on?..

Keskne logide kogumine piisavalt suure infrastruktuuri puhul nõuab märkimisväärseid ressursse, mis lähevad logide kogumisele, säilitamisele ja töötlemisele. Erinevate projektide käigus oleme kokku puutunud erinevate nõudmiste ning neist tulenevate probleemidega.

Proovime ClickHouse'i

Vaatame keskset salvestust projektil, kus rakendus genereerib aktiivselt logisid: üle 5000 rida sekundis. Alustame töötamist nende logidega, kogudes need ClickHouse'i.

Niipea, kui on vajalik maksimaalne reaalaja töötlus, on 4-tuuma server ClickHouse'i jaoks juba koormatud diskisüsteemi osas:

Selline laadimise tüüp on seotud sellega, et püüame maksimaalselt kiiresti kirjutada ClickHouse'i. Ja sellele DB reageerib suurenenud diskikoormusega, mistõttu võib esineda selliseid vigu:

DB::Exception: Liigne partii (300). Ühendused töötlevad oluliselt aeglasemalt kui sisestamised

Asi on selles, et MergeTree-tabelid ClickHouse'is (kus asuvad logide andmed) on kirjutamise toimingutel oma keerukused. Tabelisse sisestatud andmed genereerivad ajutise partii, mis hiljem ühinenud põhitäiusega. Tulemuseks on, et kirjutamine on kettale väga nõudlik ning sellele kehtib piirang, mille kohta saime eespool teate: 1 sekundi jooksul ei tohi ühenduda rohkem kui 300 alampartiid (tegelikult 300 sisestamist sekundis).

Et sellist käitumist vältida, tuleb ClickHouse'i kirjutada nii suurte blokidena kui võimalik ja mitte sagedamini kui 1 kord 2 sekundi jooksul. Kuid suurte pakettide kirjutamine eeldab, et peame harvemini kirjutama ClickHouse'i. See omakorda võib viia puhveri ületäitumiseni ja logide kadumiseni. Lahendus on suurendada Fluentd puhvrit, kuid siis suureneb ka mälutarve.

Märkus: Teine probleemne külg meie lahenduses ClickHouse'i kohta oli seotud sellega, et meie puhul (loghouse) on partitsioonimine realiseeritud läbi välistabelite, mis on seotud Merge-tabeliga. See on toob kaasa selle, et suurte ajavahemike puhul on vajalik liialt palju mäluruumi, kuna meta tabel läbib kõik partitsioonid — isegi need, mis kindlasti ei sisalda vajalikke andmeid. Siiski võib sellise lähenemisviisi nüüd julgelt vananenuks kuulutada ClickHouse'i uusimate versioonide jaoks (c 18.16).

Seetõttu on selge, et ClickHouse'i reaalajas logide kogumiseks ei piisa ressursse kaugel iga projekti jaoks (täpsemalt, nende jaotamine ei oleks otstarbekas). Lisaks on vajalik kasutada akumulaator, mille juurde me veel tagasi tuleme. Ülaltoodud juhtum on tegelik. Ja sel hetkel ei suutnud me pakkuda usaldusväärset ja stabiilset lahendust, mis rahuldaks kliendi nõudmisi ja võimaldaks koguda logisid minimaalse viivitusega…

Aga Elasticsearch?

On teada, et Elasticsearch suudab taluda suuri koormusi. Proovime seda samas projektis. Nüüd näeb koormus välja järgmiselt:

Elasticsearch suutis andmevoo töödelda, kuid selliste mahtude salvestamine kasutab tugevalt CPU-d. See lahendatakse klastrite korraldamisega. Puht tehniliselt pole see probleem, kuid selgub, et logide kogumise süsteemi jaoks kasutame juba umbes 8 tuuma ja meil on süsteemis täiendav kõrge koormusega komponent…

Kokkuvõtlikult: see variant võib olla õigustatud, kuid ainult juhul, kui projekt on suur ja selle juhtkond on valmis kulutama märkimisväärseid ressursse keskse logimise süsteemile.

Siis tekib põhjendatud küsimus:

Milliseid logisid on tegelikult vaja?

Proovime muuta lähenemist: logid peavad olema samas informatiivsed ja mitte katma iga süsteemis

Oletame, et meil on edukas veebipood. Millised logid on olulised? Maksimaalse teabe kogumine, näiteks makseväravast — suurepärane idee. Kuid tooteartiklite lõikamise teenusest ei ole meie jaoks kriitilised kõik logid: piisab ainult vigadest ja laiendatud jälgimisest (näiteks 500-se vigade protsendi jälgimine, mida see komponent genereerib).

Nii oleme jõudnud tõdemuseni, et keskne logimine ei ole kaugeltki alati põhjendatud. Väga sageli soovib klient koguda kõik logid ühte kohta, kuigi tegelikult on kogu logist vajalik vaid tinglikult 5% sõnumitest, mis on äriliselt kriitilised:

• Mõnikord piisab näiteks ainult konteineri logi suuruse ja veateate kogumise seadistamisest (nt Sentry).
• Juhtumite uurimiseks võib sageli piisata veateatest ja üsna suurest kohalikust logist.
• Meil on olnud projekte, mis piirdusid ainult funktsionaalsete testide ja veakogumise süsteemidega. Arendaja ei saanud logisid kasutada — nad nägid kõike läbi veateadete jälgimise.

Illustratsioon elust

Hea näite toob esile teine lugu. Meile tuli taotlus ühe kliendi turvatiimi poolt, kellel oli juba kasutuses kommertslahendus, mis oli välja töötatud kaua enne Kubernetes'e kasutuselevõttu.

Tõdeti, et oli vaja "sõbrustada" tsentraliseeritud logide kogumise süsteemi ettevõtte probleemide avastamise sensori — QRadariga. See süsteem suudab logisid vastu võtta syslog protokolli kaudu ning võtta FTP kaudu. Aga integreerida seda remote_syslog plugina kasutamisega fluentd'ga ei õnnestunud kohe. (nagu selgus, me ei ole üksi.). QRadar'i seadistamise probleemid olid kliendi turvatiimi poolel.

Seetõttu laaditi osa logisid, mis olid ärilisest vaatepunktist kriitilised, FTP QRadar'i, ja teine osa suunati remote syslog'i kaudu otse sõlmedest. Selleks kirjutasime isegi lihtsa chart'i, mis võib aidata kedagi sarnase ülesande lahendamisel... Saadud skeemi tulemusena sai klient kriitilisi logisid kätte ja analüüsis neid oma lemmikriistadega, samas kui meie suutsime vähendada logimise süsteemi kulusid, säilitades vaid viimase kuu.

Veel üks näide on üsna õpetlik selles, kuidas mitte teha. Ühel meie kliendil, kes töötles of each kasutajalt saabuvate sündmuste mitmerealine struktureerimata teave logis. Kuidas kergesti arvata, oli selliseid logisid äärmiselt ebamugav lugeda ja säilitada.

Logide kriteeriumid

Sellised näited viivad meid järeldusele, et lisaks logide kogumise süsteemi valimisele tuleb disainida ka logid.! Millised on siin nõuded?

• Logid peavad olema masinloetavas vormingus (nt JSON).
• Logid peavad olema kompaktsed ja võimaldama logimise taseme muutmist, et probleeme lahendada. Samas tuleb tootmiskeskkondades süsteemid käivitada logimise tasemega nagu Hoiatus või Error.
• Logid peavad olema normaliseeritud, st logi objektis peavad kõik read olema sama tüüpi väärtused.

Struktuurita logid võivad põhjustada probleeme logide laadimisel salvestusse ning nende töötlemise täielik peatamine. Näiteks toome välja vea 400, millega paljud on kindlasti fluentd logides kokku puutunud:

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

Vea õpetus tähendab, et saadate indeksi, kus on valmis kaardistus, välja mingi tipu, mille tüüp on ebastabiilne. Kõige lihtsam näide on nginx logis olev väli muutuja $upstream_status. Selles võib olla nii number kui ka string. Näiteks:

{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Okt/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, nagu 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/Okt/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, nagu 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"}

Logides on näha, et server 10.100.0.10 vastas 404 vea ja päring suunati teise sisuhoidla. Tulemusena muutus logides väärtus selliseks:

"upstream_response_time": "0.001, 0.007"

See olukord on nii levinud, et see on saanud isegi eraldi mainimise dokumentatsioonis.

Aga kuidas on usaldusväärsusega?

On juhtumeid, kus on hädasti vaja kõiki logisid eranditeta. Ja tavapärastes K8s logide kogumise skeemides, nagu eelnimetatud, on probleeme.

Näiteks ei suuda fluentd koguda logisid lühiajalistest konteineritest. Ühes meie projektis elab andmebaasi migratsiooni konteiner alla 4 sekundi ja siis kustutatakse — vastavalt vastavale annotatsioonile:

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

Seetõttu ei jõudnud migratsiooni tegevuse logi salvestusse. Sellisel juhul võib aidata poliitika before-hook-creation.

Teine näide on Docker logide pööramine. Oletame, et on rakendus, mis kirjutab aktiivselt logidesse. Tavalistes tingimustes suudame kõik logid töödelda, kuid kui ilmneb probleem — näiteks nagu eespool kirjeldatud vale vorminguga — peatub töötlemine ning Docker pöörab faili. Tulemuseks on, et olulised ettevõtte logid võivad kaduma minna.

Just seetõttu Oluline on jagada logide vooge, integreerides kõige väärtuslikumate otse rakendusse saatmise, et tagada nende säilimine. Lisaks ei tee paha luua mingit "logide akumulaatorit", mis suudab taluda hetkete ei-toimetamise salvestust, säilitades kriitilised sõnumid.

Lõpuks ei tohi unustada, et igal süsteemil on oluline kvaliteetselt jälgida. Vastasel juhul on lihtne sattuda olukorda, kus fluentd on seisundis CrashLoopBackOff ja ei saatnud midagi, ja see tähistab olulise teabe kaotust.

Järeldused

Selles artiklis me ei käsitle selliseid SaaS-lahendusi nagu Datadog. Paljud siin kirjeldatud probleemid on mingil viisil juba lahendatud kommertsfirmade poolt, kes on spetsialiseerunud logide kogumisele, kuid mitte kõik ei saa erinevatel põhjustel kasutada SaaS-i. (peamised - see on hind ja 152-FZ seaduse järgimine).

Keskne logide kogumine näib esialgu lihtsa ülesandena, kuid ei ole sugugi selline. Oluline on meeles pidada, et:

• Detsemberdada põhjalikult tuleks ainult kriitilisi komponente, samas kui teiste süsteemide jaoks võib seadistada jälgimise ja vigade kogumise.
• Logid tootmises peaksid olema minimaalsed, et mitte tekitada liigset koormust.
• Logid peavad olema masinloetavad, normaliseeritud ja neil peab olema range formaat.
• Tõeliselt kriitilised logid tuleks saata eraldi vooguna, mis peab olema eraldatud põhivoolust.
• Väärt on läbi mõelda logide akumulaator, mis võib päästa kõrge koormuse puhangute korral ja muudab koormuse salvestusele ühtlasemaks.

Need lihtsad reeglid, kui neid rakendada igal pool, lubaksid töötada ka eespool kirjeldatud skeemides — isegi kui neis puuduvad olulised komponendid (akumulaator). Kuid kui sellistest põhimõtetest ei pea kinni, võib ülesanne kergesti viia sind ja infrastruktuuri veel ühe kõrge koormusega (ja samas vähe efektiivse) süsteemi komponendini.

P.S.

Lugege ka meie blogist:

• «Tutvustame loghouse'i — Open Source süsteemi logidega töötamiseks Kuberneteses.»;
• «Vabastused Kubernetes'i ökosüsteemis KubeCon’19-l: JFrog Container Registry, IBM-i Kui, Loki 1.0.0…»;
• «Monitoring ja Kubernetes (ülevaade ja video ettekandest)».

Allikas: habr.com