Það er 2019, og við höfum enn ekki staðlaða lausn fyrir skráningu í Kubernetes. Í þessari grein viljum við, með því að nota dæmi úr raunveruleikanum, deila leitum okkar, vandamálum sem upp hafa komið og lausnum þeirra.
Hins vegar, fyrst, mun ég gera fyrirvara um að mismunandi viðskiptavinir skilji mjög mismunandi hluti með því að safna annálum:
- einhver vill sjá öryggis- og endurskoðunarskrár;
- einhver - miðstýrð skógarhögg á öllu innviði;
- og fyrir suma er nóg að safna eingöngu forritaskrám, að undanskildum til dæmis jafnvægistækjum.
Hér að neðan er niðurskurðurinn hér að neðan um hvernig við útfærðum ýmsa „óskalista“ og hvaða erfiðleika við lentum í.
Kenning: um skógarhöggverkfæri
Bakgrunnur um íhluti skógarhöggskerfis
Skógarhögg hefur náð langt og það hefur verið þróuð aðferðafræði til að safna og greina annála, sem er það sem við notum í dag. Aftur á fimmta áratugnum kynnti Fortran hliðstæða staðlaða inntaks/úttaksstrauma, sem hjálpaði forritaranum að kemba forritið sitt. Þetta voru fyrstu tölvuskrárnar sem gerðu forriturum þess tíma lífið auðveldara. Í dag sjáum við í þeim fyrsta þáttinn í skógarhöggskerfinu - uppspretta eða „framleiðandi“ annála.
Tölvunarfræðin stóð ekki í stað: tölvunet komu fram, fyrstu klasarnir... Flókin kerfi sem samanstóð af nokkrum tölvum fóru að virka. Nú neyddust kerfisstjórar til að safna annálum frá nokkrum vélum og í sérstökum tilvikum gætu þeir bætt við OS kjarnaskilaboðum ef þeir þyrftu að rannsaka kerfisbilun. Til að lýsa miðlægum annálasöfnunarkerfum var það gefið út snemma á 2000 , sem staðlaði remote_syslog. Svona birtist annar mikilvægur þáttur: timbursafnari og geymslu þeirra.
Með auknu magni annála og víðtækri kynningu á veftækni vaknaði spurningin um hvaða skrár þarf að sýna notendum á þægilegan hátt. Einföld stjórnborðsverkfæri (awk/sed/grep) hafa verið skipt út fyrir fullkomnari verkfæri log áhorfendur - þriðji þáttur.
Vegna aukins magns af trjábolum kom annað í ljós: það er þörf á stokkum, en ekki öllum. Og mismunandi annálar krefjast mismunandi varðveislu: sumir geta glatast á einum degi, á meðan aðrir þurfa að geyma í 5 ár. Svo, hluti til að sía og beina gagnaflæði var bætt við skógarhöggskerfið - við skulum kalla það sía.
Geymsla hefur einnig tekið stórt stökk: frá venjulegum skrám yfir í venslagagnagrunna og síðan í skjalamiðaða geymslu (til dæmis Elasticsearch). Þannig að geymslan var aðskilin frá safnaranum.
Á endanum hefur sjálft hugtakið loga stækkað í eins konar óhlutbundinn straum atburða sem við viljum varðveita til sögunnar. Eða réttara sagt, ef þú þarft að framkvæma rannsókn eða semja greiningarskýrslu...
Afleiðingin er sú að á tiltölulega stuttum tíma hefur annálasöfnun þróast í mikilvægt undirkerfi, sem með réttu má kalla einn af undirkaflunum í Big Data.
Ef einu sinni venjuleg prentun gæti dugað fyrir „skráningarkerfi“, þá hefur ástandið breyst mikið.
Kubernetes og logs
Þegar Kubernetes kom að innviðunum fór vandamálið sem þegar var til við að safna annálum ekki framhjá því heldur. Að sumu leyti varð það enn sársaukafyllra: stjórnun innviðavettvangsins var ekki aðeins einfölduð heldur einnig flókin á sama tíma. Margar gamlar þjónustur eru farnar að flytjast yfir í örþjónustur. Í samhengi við annála endurspeglast þetta í vaxandi fjölda annálaheimilda, sérstökum líftíma þeirra og þörfinni á að fylgjast með tengslum allra kerfishluta í gegnum annála...
Þegar ég horfi fram á veginn get ég fullyrt að nú, því miður, er enginn staðlaður skógarhöggsmöguleiki fyrir Kubernetes sem myndi bera sig saman við alla aðra. Vinsælustu kerfin í samfélaginu eru sem hér segir:
- einhver rúllar upp staflanum EFK (Elasticsearch, Fluentd, Kibana);
- einhver er að prófa nýlega gefið út eða notar ;
- okkur (og kannski ekki bara við?..) Ég er að mestu ánægður með minn eigin þroska - ...
Að jafnaði notum við eftirfarandi búnta í K8s klösum (fyrir lausnir sem hýst eru sjálfar):
- ;
- .
Hins vegar mun ég ekki dvelja við leiðbeiningar um uppsetningu þeirra og stillingar. Þess í stað mun ég einbeita mér að göllum þeirra og fleiri alþjóðlegum ályktunum um ástandið með logs almennt.
Æfðu þig með logs í K8s
„Hversdagsskrár“, hvað eruð þið mörg?
Miðstýrð söfnun logs úr nokkuð stórum innviðum krefst talsverðs fjármagns, sem varið verður í söfnun, geymslu og vinnslu logs. Við rekstur ýmissa verkefna stóðum við frammi fyrir ýmsum kröfum og rekstrarvanda sem af þeim stafaði.
Prófum ClickHouse
Við skulum skoða miðlæga geymslu á verkefni með forriti sem býr til annála nokkuð virkan: meira en 5000 línur á sekúndu. Við skulum byrja að vinna með annálana hans, bæta þeim við ClickHouse.
Um leið og hámarks rauntíma er krafist mun 4-kjarna þjónninn með ClickHouse þegar vera ofhlaðinn á undirkerfi disksins:
Þessi tegund af hleðslu er vegna þess að við erum að reyna að skrifa í ClickHouse eins fljótt og auðið er. Og gagnagrunnurinn bregst við þessu með auknu diskálagi, sem getur valdið eftirfarandi villum:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
Staðreyndin er sú að í ClickHouse (þeir innihalda loggögn) eiga í erfiðleikum með að skrifa. Gögnin sem eru sett inn í þau mynda tímabundna skipting sem síðan er sameinuð aðaltöflunni. Fyrir vikið reynist upptakan vera mjög krefjandi fyrir diskinn og hún er einnig háð þeim takmörkunum sem við fengum tilkynningu um hér að ofan: ekki er hægt að sameina meira en 1 undirskil á 300 sekúndu (reyndar eru þetta 300 innskot á sekúndu).
Til að forðast þessa hegðun, í eins stórum bitum og hægt er og ekki oftar en 1 sinni á 2 sekúndna fresti. Hins vegar, að skrifa í stórum lotum, bendir til þess að við ættum að skrifa sjaldnar í ClickHouse. Þetta getur aftur leitt til yfirflæðis í biðminni og taps á logum. Lausnin er að auka Fluentd biðminni en þá mun minnisnotkunin líka aukast.
Athugið: Annar erfiður þáttur í lausn okkar með ClickHouse var tengdur þeirri staðreynd að skipting í okkar tilviki (bjálkahús) er útfærð í gegnum ytri töflur tengdar . Þetta leiðir til þess að þegar tekið er sýnishorn af stórum tímabilum þarf of mikið vinnsluminni, þar sem metatable endurtekur sig í gegnum allar skiptingarnar - jafnvel þær sem augljóslega innihalda ekki nauðsynleg gögn. Hins vegar er nú örugglega hægt að lýsa þessari aðferð úrelta fyrir núverandi útgáfur af ClickHouse (c ).
Fyrir vikið verður ljóst að ekki hvert verkefni hefur nóg fjármagn til að safna annálum í rauntíma í ClickHouse (nánar tiltekið, dreifing þeirra mun ekki vera viðeigandi). Að auki verður þú að nota аккумулятор, sem við munum koma aftur að síðar. Málið sem lýst er hér að ofan er raunverulegt. Og á þeim tíma gátum við ekki boðið upp á áreiðanlega og stöðuga lausn sem hentaði viðskiptavinum og gerði okkur kleift að safna annálum með lágmarks töf...
Hvað með Elasticsearch?
Elasticsearch er þekkt fyrir að takast á við mikið vinnuálag. Prófum það í sama verkefninu. Nú lítur álagið svona út:
Elasticsearch gat melt gagnastrauminn, en að skrifa slík bindi í hann nýtir örgjörvann mjög. Þetta er ákveðið með því að skipuleggja klasa. Tæknilega séð er þetta ekki vandamál, en það kemur í ljós að bara til að stjórna annálasafnskerfinu notum við nú þegar um 8 kjarna og höfum til viðbótar mjög hlaðinn íhlut í kerfinu...
Niðurstaða: hægt er að réttlæta þennan valkost, en aðeins ef verkefnið er stórt og stjórnendur þess eru tilbúnir til að eyða umtalsverðum fjármunum í miðstýrt skógarhöggskerfi.
Þá vaknar eðlileg spurning:
Hvaða logs er raunverulega þörf?
Við skulum reyna að breyta nálguninni sjálfri: annálar ættu samtímis að vera upplýsandi og ekki ná yfir hver atburður í kerfinu.
Segjum að við séum með farsæla netverslun. Hvaða logs eru mikilvægar? Að safna eins miklum upplýsingum og mögulegt er, til dæmis frá greiðslugátt, er frábær hugmynd. En ekki eru allir annálarnir frá myndasneiðarþjónustunni í vörulistanum mikilvægir fyrir okkur: aðeins villur og háþróað eftirlit nægir (til dæmis hlutfallið af 500 villum sem þessi hluti myndar).
Þannig að við höfum komist að þeirri niðurstöðu miðlæg skógarhögg er ekki alltaf réttlætanleg. Mjög oft vill viðskiptavinurinn safna öllum annálum á einn stað, þó að í rauninni þurfi aðeins skilyrt 5% af skilaboðum sem eru mikilvæg fyrir fyrirtækið úr öllum annálum:
- Stundum er nóg að stilla, segjum, aðeins stærð gámaskrárinnar og villusafnarans (til dæmis Sentry).
- Villutilkynning og stór staðbundin skrá sjálf geta oft verið nóg til að rannsaka atvik.
- Við vorum með verkefni sem létu okkur nægja eingöngu virkniprófanir og villusöfnunarkerfi. Framkvæmdaraðilinn þurfti ekki annála sem slíka - þeir sáu allt frá villusporum.
Myndskreyting úr lífinu
Önnur saga getur verið gott dæmi. Við fengum beiðni frá öryggisteymi eins viðskiptavinar okkar sem var þegar að nota viðskiptalausn sem var þróuð löngu fyrir kynningu á Kubernetes.
Nauðsynlegt var að „eignast vini“ miðlæga annálasöfnunarkerfisins með vandamálaskynjara fyrirtækja - QRadar. Þetta kerfi getur tekið á móti annálum í gegnum syslog samskiptareglur og sótt þær frá FTP. Hins vegar var ekki strax hægt að samþætta það með remote_syslog viðbótinni fyrir fluentd (eins og það kom í ljós, ). Vandamál við uppsetningu QRadar reyndust vera hlið öryggisteymi viðskiptavinarins.
Fyrir vikið var hluta af viðskipta mikilvægu annálunum hlaðið upp á FTP QRadar og hinum hlutanum var vísað beint frá hnútunum í gegnum ytra syslog. Fyrir þetta skrifuðum við meira að segja - ef til vill mun það hjálpa einhverjum að leysa svipað vandamál... Þökk sé kerfinu sem varð til, fékk viðskiptavinurinn sjálfur og greindi mikilvæga annála (með því að nota uppáhalds verkfærin sín), og við gátum dregið úr kostnaði við skógarhöggkerfið og sparað aðeins í síðasta mánuði.
Annað dæmi er alveg til marks um hvað ekki á að gera. Einn af viðskiptavinum okkar til vinnslu af hverju atburðir sem koma frá notanda, gerðir multiline óskipulögð framleiðsla upplýsingar í log. Eins og þú gætir giska á, voru slíkar annálar afar óþægilegar bæði að lesa og geyma.
Skilyrði fyrir logs
Slík dæmi leiða til þeirrar niðurstöðu að auk þess að velja söfnunarkerfi fyrir annál þarftu að gera það hanna líka stokkana sjálfir! Hverjar eru kröfurnar hér?
- Logs verða að vera á véllæsilegu sniði (til dæmis JSON).
- Logs ætti að vera fyrirferðarlítið og með getu til að breyta umfangi skráningar til að kemba hugsanleg vandamál. Á sama tíma, í framleiðsluumhverfi ættir þú að keyra kerfi með skógarhöggsstigi eins og Viðvörun eða villa.
- Logs verða að vera eðlilegir, það er, í log hlut, allar línur verða að hafa sömu reitgerð.
Óskipulagðir annálar geta leitt til vandamála við að hlaða annálum inn í geymslu og stöðva algjörlega vinnslu þeirra. Sem dæmi, hér er dæmi með villu 400, sem margir hafa örugglega lent í í reiprennandi annálum:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
Villan þýðir að þú ert að senda reit þar sem gerð er óstöðug í vísitöluna með tilbúinni kortlagningu. Einfaldasta dæmið er reitur í nginx log með breytu $upstream_status. Það getur innihaldið annað hvort tölu eða streng. Til dæmis:
{ "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"}
Skrárnar sýna að þjónn 10.100.0.10 svaraði með 404 villu og beiðnin var send í aðra efnisgeymslu. Fyrir vikið varð gildið í annálunum svona:
"upstream_response_time": "0.001, 0.007"
Þetta ástand er svo algengt að það verðskuldar jafnvel aðskilnað .
Hvað með áreiðanleika?
Það eru tímar þegar allir annálar án undantekninga eru mikilvægir. Og með þessu eru dæmigerð logsöfnunarkerfi fyrir K8 sem lögð er til/rædd hér að ofan í vandræðum.
Til dæmis getur fluentd ekki safnað timbri úr skammlífum gámum. Í einu af verkefnum okkar lifði gagnagrunnsflutningsílátið í minna en 4 sekúndur og var síðan eytt - samkvæmt samsvarandi athugasemd:
"helm.sh/hook-delete-policy": hook-succeeded
Vegna þessa var flutningsframkvæmdaskráin ekki innifalin í geymslunni. Stjórnmál geta hjálpað í þessu máli. before-hook-creation.
Annað dæmi er Docker log snúningur. Segjum að það sé forrit sem skrifar virkan í annála. Við venjulegar aðstæður tekst okkur að vinna úr öllum annálum, en um leið og vandamál koma upp - til dæmis eins og lýst er hér að ofan með rangt snið - hættir vinnslan og Docker snýr skránni. Niðurstaðan er sú að viðskiptaþættir annálar gætu glatast.
Þess vegna það er mikilvægt að aðgreina logstrauma, fella inn að senda þá verðmætustu beint inn í forritið til að tryggja öryggi þeirra. Auk þess væri ekki óþarfi að búa til nokkrar „safnari“ annála, sem getur lifað af stutta geymsluleysi á meðan að vista mikilvæg skilaboð.
Að lokum megum við ekki gleyma því Mikilvægt er að fylgjast vel með hvaða undirkerfi sem er. Annars er auðvelt að lenda í aðstæðum þar sem fluentd er í ástandi CrashLoopBackOff og sendir ekki neitt, og þetta lofar tapi á mikilvægum upplýsingum.
Niðurstöður
Í þessari grein erum við ekki að skoða SaaS lausnir eins og Datadog. Mörg þeirra vandamála sem hér er lýst hafa þegar verið leyst með einum eða öðrum hætti af viðskiptafyrirtækjum sem sérhæfa sig í söfnun logs, en það geta ekki allir notað SaaS af ýmsum ástæðum (það helsta eru kostnaður og samræmi við 152-FZ).
Miðstýrð annálasöfnun lítur í fyrstu út eins og einfalt verkefni, en er það alls ekki. Það er mikilvægt að muna að:
- Aðeins þarf að skrá mikilvæga hluti í smáatriðum, en eftirlit og villusöfnun er hægt að stilla fyrir önnur kerfi.
- Halda ætti skrám í framleiðslu í lágmarki til að auka ekki á óþarfa álag.
- Dagskrár verða að vera véllesanlegar, staðlaðar og vera með ströngu sniði.
- Raunverulega mikilvæga annála ætti að senda í sérstökum straumi, sem ætti að vera aðskilinn frá þeim helstu.
- Það er þess virði að íhuga timbursafn, sem getur bjargað þér frá sprengingum af miklu álagi og gert álagið á geymsluna einsleitara.
Þessar einföldu reglur, ef þeim er beitt alls staðar, myndu leyfa rafrásunum sem lýst er hér að ofan að virka - jafnvel þó að þær vanti mikilvæga hluti (rafhlöðuna). Ef þú fylgir ekki slíkum meginreglum mun verkefnið auðveldlega leiða þig og innviðina í annan mjög hlaðinn (og á sama tíma óvirkan) hluta kerfisins.
PS
Lestu líka á blogginu okkar:
- «»;
- «»;
- «'.
Heimild: www.habr.com