It is 2019, en wy hawwe noch altyd gjin standertoplossing foar log-aggregaasje yn Kubernetes. Yn dit artikel wolle wy, mei help fan foarbylden út echte praktyk, ús sykopdrachten, problemen dy't ûnderfûn binne en har oplossingen diele.
Ik sil lykwols earst in reservearje meitsje dat ferskate klanten heul ferskillende dingen begripe troch logs te sammeljen:
- immen wol befeiligings- en kontrôlelogs sjen;
- immen - sintralisearre logging fan 'e hiele ynfrastruktuer;
- en foar guon is it genôch om allinich applikaasjelogs te sammeljen, útsein bygelyks balancers.
Hjirûnder is de besuniging hjirûnder oer hoe't wy ferskate "ferlanglisten" ymplementearre hawwe en hokker swierrichheden wy tsjinkamen.
Teory: oer logging ark
Eftergrûn oer de komponinten fan in logsysteem
Logging is in lange wei kommen, wêrtroch't metoaden foar it sammeljen en analysearjen fan logs binne ûntwikkele, wat wy hjoed brûke. Werom yn 'e 1950's yntrodusearre Fortran in analoog fan standert ynfier-/útfierstreamen, dy't de programmeur holp om syn programma te debuggen. Dit wiene de earste kompjûterlogboeken dy't it libben makliker makken foar programmeurs fan dy tiden. Hjoed sjogge wy yn har de earste komponint fan it logsysteem - boarne of "produsint" fan logs.
De kompjûterwittenskip stie net stil: kompjûternetwurken ferskynden, de earste klusters... Komplekse systemen besteande út ferskate kompjûters begûnen te wurkjen. No waarden systeembehearders twongen om logs fan ferskate masines te sammeljen, en yn spesjale gefallen koene se OS-kernelberjochten tafoegje yn gefal dat se in systeemflater moatte ûndersykje. Om sintralisearre logsammelingssystemen te beskriuwen, waard it yn 'e iere 2000's publisearre , dy't standardisearre remote_syslog. Dit is hoe't in oare wichtige komponint ferskynde: log samler en harren opslach.
Mei de tanimming fan it folume fan logs en de wiidfersprate yntroduksje fan webtechnologyen, ûntstie de fraach fan hokker logs maklik oan brûkers toand wurde moatte. Ienfâldige konsole-ark (awk/sed/grep) binne ferfongen troch mear avansearre log sjoggers - tredde komponint.
Troch de tanimming fan it folume fan logs waard wat oars dúdlik: logs binne nedich, mar net allegear. En ferskate logs fereaskje ferskillende nivo's fan behâld: guon kinne ferlern gean yn in dei, wylst oaren moatte wurde opslein foar 5 jier. Dat, in komponint foar filterjen en routing fan gegevensstreamen waard tafoege oan it logsysteem - litte wy it neame filter.
Opslach hat ek in grutte sprong makke: fan reguliere bestannen nei relasjonele databases, en dan nei dokumint-rjochte opslach (bygelyks Elasticsearch). Sa waard de opslach skieden fan de samler.
Uteinlik is it sels konsept fan in log útwreide ta in soarte fan abstrakte stream fan eveneminten dy't wy foar de skiednis bewarje wolle. Of leaver, as jo in ûndersyk moatte dwaan of in analytysk rapport opstelle ...
Dêrtroch hat logkolleksje yn in relatyf koarte perioade útgroeid ta in wichtich subsysteem, dat mei rjocht ien fan de ûnderseksjes yn Big Data neamd wurde kin.
As eartiids gewoane printsjes genôch wêze kinne foar in "loggingsysteem", no is de situaasje in protte feroare.
Kubernetes en logs
Doe't Kubernetes by de ynfrastruktuer kaam, rûn it al besteande probleem fan it sammeljen fan logs der ek net om. Op guon manieren waard it noch pynliker: it behearen fan it ynfrastruktuerplatfoarm waard net allinich ferienfâldige, mar ek yngewikkelder tagelyk. In protte âlde tsjinsten binne begon te migrearjen nei mikrotsjinsten. Yn 'e kontekst fan logs wurdt dit wjerspegele yn it groeiende oantal logboarnen, har spesjale libbenssyklus, en de needsaak om de relaasjes fan alle systeemkomponinten te folgjen fia logs ...
Foarútsjen kin ik stelle dat d'r no spitigernôch gjin standertisearre logging-opsje is foar Kubernetes dy't geunstich fergelykje mei alle oaren. De populêrste regelingen yn 'e mienskip binne as folgjend:
- immen unrolls de steapel EFK (Elasticsearch, Fluentd, Kibana);
- immen besiket de koartlyn útbrocht of brûkt ;
- нас (en miskien net allinnich wy?..) Ik bin foar it grutste part tefreden mei myn eigen ûntwikkeling - ...
As regel brûke wy de folgjende bondels yn K8s-klusters (foar sels-hoste oplossingen):
- ;
- .
Ik sil lykwols net dwaen oer ynstruksjes foar har ynstallaasje en konfiguraasje. Ynstee sil ik rjochtsje op har tekoartkommingen en mear globale konklúzjes oer de situaasje mei logs yn 't algemien.
Oefenje mei logs yn K8s
"Alle dagen logboeken", hoefolle fan jim binne der? ..
Sintrale kolleksje fan logs út in frij grutte ynfrastruktuer fereasket in soad middels, dy't sille wurde bestege oan it sammeljen, opslaan en ferwurkjen fan logs. Tidens de eksploitaasje fan ferskate projekten waarden wy konfrontearre mei ferskate easken en operasjonele problemen dy't dêrút ûntstiene.
Litte wy ClickHouse besykje
Litte wy nei in sintralisearre opslach sjen op in projekt mei in applikaasje dy't logs frij aktyf genereart: mear dan 5000 rigels per sekonde. Litte wy begjinne te wurkjen mei syn logs, en tafoegje se oan ClickHouse.
Sadree't maksimale realtime fereaske is, sil de 4-kearnserver mei ClickHouse al oerladen wurde op it skiifsubsysteem:
Dit type laden is te tankjen oan it feit dat wy besykje sa rap mooglik yn ClickHouse te skriuwen. En de databank reagearret hjirop mei ferhege skiifbelêsting, wat de folgjende flaters kin feroarsaakje:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
Punt is dat yn ClickHouse (se befetsje loggegevens) hawwe har eigen swierrichheden by skriuwoperaasjes. De yn har ynfoege gegevens genereart in tydlike partysje, dy't dan wurdt gearfoege mei de haadtabel. As gefolch, de opname blykt te wêzen hiel easken op 'e skiif, en it is ek ûnder foarbehâld fan' e beheining dat wy krigen melding oer hjirboppe: net mear as 1 subpartitions kinne wurde gearfoege yn 300 sekonde (feitlik, dit is 300 ynserts per sekonde).
Om dit gedrach te foarkommen, yn sa grut mooglike stikken en net mear as 1 kear elke 2 sekonden. It skriuwen yn grutte bursts suggerearret lykwols dat wy minder faak moatte skriuwe yn ClickHouse. Dit kin op syn beurt liede ta in bufferoerstream en ferlies fan logs. De oplossing is om de Fluentd-buffer te ferheegjen, mar dan sil it ûnthâldferbrûk ek tanimme.
remark: In oar problematysk aspekt fan ús oplossing mei ClickHouse wie relatearre oan it feit dat partitioning yn ús gefal (loghouse) wurdt ymplementearre fia eksterne tabellen ferbûn . Dit liedt ta it feit dat by sampling fan grutte tiidintervallen tefolle RAM nedich is, om't de metatable iterearret troch alle partysjes - sels dyjingen dy't fansels net de nedige gegevens befetsje. No kin dizze oanpak lykwols feilich ferâldere wurde ferklearre foar hjoeddeistige ferzjes fan ClickHouse (c ).
As gefolch wurdt it dúdlik dat net elk projekt genôch middels hat om logs yn realtime te sammeljen yn ClickHouse (krekter, har ferdieling sil net passend wêze). Derneist moatte jo gebrûk meitsje аккумулятор, dêr't wy letter op weromkomme. It hjirboppe beskreaune gefal is echt. En op dat stuit wiene wy net yn steat om in betroubere en stabile oplossing oan te bieden dy't by de klant paste en ús logs mei minimale fertraging sammelje kinne ...
Hoe sit it mei Elasticsearch?
Elasticsearch is bekend om swiere wurkdruk te behanneljen. Litte wy it besykje yn itselde projekt. No sjocht de lading der sa út:
Elasticsearch wie yn steat om de gegevensstream te fertarren, lykwols, it skriuwen fan sokke folumes derop brûkt de CPU sterk. Dat wurdt besletten troch it organisearjen fan in kluster. Technysk is dit gjin probleem, mar it docht bliken dat gewoan om it logboeksammelsysteem te betsjinjen, wy al sawat 8 kearnen brûke en in ekstra heul laden komponint yn it systeem hawwe ...
Bottom line: dizze opsje kin rjochtfeardige wurde, mar allinich as it projekt grut is en har behear is ree om wichtige boarnen te besteegjen oan in sintralisearre logsysteem.
Dan ûntstiet in natuerlike fraach:
Hokker logs binne echt nedich?
Litte wy besykje de oanpak sels te feroarjen: logs moatte tagelyk ynformatyf wêze en net dekke elke evenemint yn it systeem.
Litte wy sizze dat wy in suksesfolle online winkel hawwe. Hokker logs binne wichtich? It sammeljen fan safolle mooglik ynformaasje, bygelyks fan in betellingspoarte, is in geweldich idee. Mar net alle logs fan 'e ôfbyldingssnijtsjinst yn' e produktkatalogus binne kritysk foar ús: allinich flaters en avansearre kontrôle binne genôch (bygelyks it persintaazje fan 500 flaters dat dizze komponint genereart).
Dat binne wy dus ta de konklúzje kommen sintralisearre logging is net altyd terjochte. Hiel faak wol de kliïnt alle logs op ien plak sammelje, hoewol yn feite, út it heule log, mar in betingst 5% fan berjochten dy't kritysk binne foar it bedriuw binne ferplicht:
- Soms is it genôch om te konfigurearjen, bygelyks, allinich de grutte fan 'e kontenerlog en de flatersamler (bygelyks Sentry).
- In flatermelding en in grut lokaal log sels kinne faak genôch wêze om ynsidinten te ûndersykjen.
- Wy hiene projekten dy't it makken mei eksklusyf funksjonele tests en systemen foar flatersamling. De ûntwikkelder hie gjin logs as sadanich nedich - se seagen alles fan flaterspoaren.
Yllustraasje út it libben
In oar ferhaal kin as goed foarbyld tsjinje. Wy krigen in fersyk fan it befeiligingsteam fan ien fan ús kliïnten dy't al in kommersjele oplossing brûkte dy't lang foar de yntroduksje fan Kubernetes ûntwikkele is.
It wie nedich om "freonen te meitsjen" fan it sintralisearre logboeksamlingssysteem mei de Corporate Problem Detection Sensor - QRadar. Dit systeem kin logs ûntfange fia it syslog-protokol en helje se fan FTP. It wie lykwols net fuortendaliks mooglik om it te yntegrearjen mei de remote_syslog plugin foar fluentd (sa't bliken die, ). Problemen mei it ynstellen fan QRadar die bliken te wêzen oan 'e kant fan it befeiligingsteam fan' e kliïnt.
As resultaat waard in diel fan 'e saaklike krityske logs opladen nei FTP QRadar, en it oare diel waard omlaat fia syslog op ôfstân direkt fan' e knopen. Dêrfoar hawwe wy sels skreaun - miskien sil it ien helpe om in ferlykber probleem op te lossen ... Mei tank oan it resultearjende skema krige en analysearre de kliïnt sels krityske logs (mei syn favorite ark), en wy koenen de kosten fan it logsysteem ferminderje, allinich de besparring ferline moanne.
In oar foarbyld is frij yndikatyf fan wat net te dwaan. Ien fan ús kliïnten foar ferwurking fan elk eveneminten komme út de brûker, makke multiline unstructured output ynformaasje yn log. Lykas jo miskien riede, wiene sokke logs ekstreem ûngemaklik foar sawol lêzen as opslaan.
Kritearia foar logs
Sokke foarbylden liede ta de konklúzje dat jo neist it kiezen fan in logboeksamlingsysteem moatte ûntwerpe ek de logs sels! Wat binne de easken hjir?
- Logs moatte yn masine-lêsber formaat wêze (bygelyks JSON).
- Logs moatte kompakt wêze en mei de mooglikheid om de mjitte fan logging te feroarjen om mooglike problemen te debuggen. Tagelyk moatte jo yn produksjeomjouwings systemen útfiere mei in lognivo lykas Warskôging of Fersin.
- Logs moatte wurde normalisearre, dat is, yn in log foarwerp, alle rigels moatte hawwe deselde fjild type.
Unstrukturearre logs kinne liede ta problemen mei it laden fan logs yn opslach en har ferwurking folslein stopje. As yllustraasje is hjir in foarbyld mei flater 400, dy't in protte definityf binne tsjinkaam yn floeiende logs:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
De flater betsjut dat jo in fjild stjoere wêrfan it type ynstabyl is nei de yndeks mei in klearmakke mapping. It ienfâldichste foarbyld is in fjild yn it nginx-log mei in fariabele $upstream_status. It kin in nûmer as in tekenrige befetsje. Bygelyks:
{ "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"}
De logs litte sjen dat tsjinner 10.100.0.10 antwurde mei in 404 flater en it fersyk waard stjoerd nei in oare ynhâld opslach. As gefolch waard de wearde yn 'e logs sa:
"upstream_response_time": "0.001, 0.007"
Dizze situaasje is sa gewoan dat it sels in apart fertsjinnet .
Hoe sit it mei betrouberens?
D'r binne tiden dat alle logs sûnder útsûndering essensjeel binne. En mei dit, de typyske log samling regelingen foar K8s foarsteld / besprutsen hjirboppe hawwe problemen.
Bygelyks, fluentd kin net sammelje logs út koarte-libben konteners. Yn ien fan ús projekten libbe de databankmigraasjekontainer minder dan 4 sekonden en waard doe wiske - neffens de oerienkommende annotaasje:
"helm.sh/hook-delete-policy": hook-succeeded
Hjirtroch waard it útfieringslogboek fan migraasje net opnommen yn 'e opslach. Polityk kin helpe yn dit gefal. before-hook-creation.
In oar foarbyld is Docker-logrotaasje. Litte wy sizze dat d'r in applikaasje is dy't aktyf skriuwt nei logs. Under normale omstannichheden slagget it ús om alle logs te ferwurkjen, mar sa gau as der in probleem ferskynt - bygelyks lykas hjirboppe beskreaun mei in ferkeard formaat - stopet de ferwurking, en Docker draait it bestân. It resultaat is dat saaklike krityske logs ferlern gean kinne.
Dat is dêrom it is wichtich om te skieden log streamen, ynbêde it ferstjoeren fan de meast weardefolle direkt yn 'e applikaasje om har feiligens te garandearjen. Derneist soe it net oerstallich wêze om guon te meitsjen "akkumulator" fan logs, dy't koarte ûnbeskikberens fan opslach kinne oerlibje by it bewarjen fan krityske berjochten.
As lêste moatte wy dat net ferjitte It is wichtich om elk subsysteem goed te kontrolearjen. Oars, is it maklik om te rinnen yn in situaasje dêr't fluentd is yn in steat CrashLoopBackOff en stjoert neat, en dit belooft it ferlies fan wichtige ynformaasje.
befinings
Yn dit artikel sjogge wy net nei SaaS-oplossingen lykas Datadog. In protte fan 'e hjir beskreaune problemen binne al op ien of oare manier oplost troch kommersjele bedriuwen dy't spesjalisearje yn it sammeljen fan logs, mar net elkenien kin SaaS brûke om ferskate redenen (de wichtichste binne kosten en konformiteit mei 152-FZ).
Sintralisearre logkolleksje liket earst in ienfâldige taak, mar it is it hielendal net. It is wichtich om te ûnthâlden dat:
- Allinich krityske komponinten moatte yn detail oanmeld wurde, wylst tafersjoch en flatersammeling kinne wurde konfigureare foar oare systemen.
- Logs yn produksje moatte minimaal wurde hâlden om net unnedige lading ta te foegjen.
- Logs moatte masine lêsber wêze, normalisearre, en hawwe in strikt formaat.
- Echt krityske logs moatte wurde ferstjoerd yn in aparte stream, dy't moatte wurde skieden fan de wichtichste.
- It is de muoite wurdich om te beskôgje in log accumulator, dat kin rêde jo út bursts fan hege lading en meitsje de lading op 'e opslach mear unifoarm.
Dizze ienfâldige regels, as oeral tapast wurde, soene de hjirboppe beskreaune circuits tastean kinne wurkje - ek al ûntbrekke se wichtige komponinten (de batterij). As jo soksoarte prinsipes net hâlde, sil de taak jo en de ynfrastruktuer maklik liede nei in oare heul laden (en tagelyk net effektyf) komponint fan it systeem.
PS
Lês ek op ús blog:
- «";
- «";
- «".
Boarne: www.habr.com