ŽurnÄli Kubernetes (un ne tikai) Å”odien: gaidas un realitÄte
Ir 2019. gads, un mums joprojÄm nav standarta risinÄjuma baļķu apkopoÅ”anai Kubernetes. Å ajÄ rakstÄ, izmantojot piemÄrus no reÄlas prakses, mÄs vÄlamies dalÄ«ties ar saviem meklÄjumiem, sastaptajÄm problÄmÄm un to risinÄjumiem.
TomÄr vispirms es izdarÄ«Å”u atrunu, ka dažÄdi klienti, apkopojot žurnÄlus, saprot ļoti dažÄdas lietas:
kÄds vÄlas redzÄt droŔības un audita žurnÄlus;
kÄds - centralizÄta visas infrastruktÅ«ras mežizstrÄde;
un dažiem pietiek savÄkt tikai lietojumprogrammu žurnÄlus, izÅemot, piemÄram, balansÄtÄjus.
TÄlÄk ir sniegts izgriezums par to, kÄ mÄs ieviesÄm dažÄdus āvÄlmju sarakstusā un ar kÄdÄm grÅ«tÄ«bÄm saskÄrÄmies.
Teorija: par mežizstrÄdes rÄ«kiem
PamatinformÄcija par mežizstrÄdes sistÄmas sastÄvdaļÄm
MežizstrÄde ir nogÄjusi garu ceļu, kÄ rezultÄtÄ ir izstrÄdÄtas baļķu vÄkÅ”anas un analÄ«zes metodoloÄ£ijas, ko mÄs izmantojam Å”odien. 1950. gados Fortran ieviesa standarta ievades/izvades straumju analogu, kas palÄ«dzÄja programmÄtÄjam atkļūdot savu programmu. Tie bija pirmie datoru žurnÄli, kas atviegloja dzÄ«vi to laiku programmÄtÄjiem. Å odien mÄs tajÄs redzam pirmo reÄ£istrÄÅ”anas sistÄmas komponentu - baļķu avots vai āražotÄjsā..
DatorzinÄtne nestÄvÄja uz vietas: parÄdÄ«jÄs datortÄ«kli, pirmie klasteri... SÄka strÄdÄt sarežģītas sistÄmas, kas sastÄvÄja no vairÄkiem datoriem. Tagad sistÄmas administratori bija spiesti vÄkt žurnÄlus no vairÄkÄm maŔīnÄm, un Ä«paÅ”os gadÄ«jumos viÅi varÄja pievienot OS kodola ziÅojumus, ja viÅiem bija nepiecieÅ”ams izmeklÄt sistÄmas kļūmi. Lai aprakstÄ«tu centralizÄtÄs žurnÄlu vÄkÅ”anas sistÄmas, 2000. gadu sÄkumÄ tas tika publicÄts RFC 3164, kas standartizÄja remote_syslog. Å Ädi parÄdÄ«jÄs vÄl viens svarÄ«gs komponents: baļķu savÄcÄjs un to uzglabÄÅ”ana.
Pieaugot žurnÄlu apjomam un plaÅ”i ievieÅ”ot tÄ«mekļa tehnoloÄ£ijas, radÄs jautÄjums, kÄdi žurnÄli ir Ärti jÄparÄda lietotÄjiem. VienkÄrÅ”ie konsoles rÄ«ki (awk/sed/grep) ir aizstÄti ar modernÄkiem žurnÄlu skatÄ«tÄji - treÅ”Ä sastÄvdaļa.
SakarÄ ar baļķu apjoma pieaugumu noskaidrojÄs kas cits: baļķi vajag, bet ne visus. Un dažÄdiem baļķiem ir nepiecieÅ”ami dažÄdi saglabÄÅ”anas lÄ«meÅi: daži var pazust vienas dienas laikÄ, bet citi ir jÄuzglabÄ 5 gadus. TÄtad reÄ£istrÄÅ”anas sistÄmai tika pievienots komponents datu plÅ«smu filtrÄÅ”anai un marÅ”rutÄÅ”anai - sauksim to filtrs.
ArÄ« krÄtuve ir veikusi lielu lÄcienu: no parastajiem failiem uz relÄciju datu bÄzÄm un pÄc tam uz dokumentiem orientÄtu krÄtuvi (piemÄram, Elasticsearch). TÄtad krÄtuve tika atdalÄ«ta no kolektora.
Galu galÄ pats žurnÄla jÄdziens ir paplaÅ”inÄjies lÄ«dz sava veida abstraktai notikumu plÅ«smai, ko mÄs vÄlamies saglabÄt vÄsturei. Vai drÄ«zÄk, ja jums ir nepiecieÅ”ams veikt izmeklÄÅ”anu vai sastÄdÄ«t analÄ«tisko ziÅojumu...
LÄ«dz ar to salÄ«dzinoÅ”i Ä«sÄ laika periodÄ Å¾urnÄlu vÄkÅ”ana ir izveidojusies par nozÄ«mÄ«gu apakÅ”sistÄmu, ko pamatoti var saukt par vienu no Big Data apakÅ”sadaļÄm.
Ja kÄdreiz āreÄ£istrÄcijas sistÄmaiā varÄja pietikt ar parastajÄm izdrukÄm, tad tagad situÄcija ir daudz mainÄ«jusies.
Kubernetes un baļķi
Kad Kubernetes nonÄca pie infrastruktÅ«ras, to neapgÄja arÄ« jau pastÄvoÅ”Ä baļķu savÄkÅ”anas problÄma. Dažos veidos tas kļuva vÄl sÄpÄ«gÄks: infrastruktÅ«ras platformas pÄrvaldÄ«ba tika ne tikai vienkÄrÅ”ota, bet vienlaikus arÄ« sarežģīta. Daudzi vecie pakalpojumi ir sÄkuÅ”i migrÄt uz mikropakalpojumiem. ŽurnÄlu kontekstÄ tas izpaužas kÄ pieaugoÅ”ais žurnÄlu avotu skaits, to Ä«paÅ”ais dzÄ«ves cikls un nepiecieÅ”amÄ«ba izsekot visu sistÄmas komponentu attiecÄ«bÄm, izmantojot žurnÄlus...
Raugoties nÄkotnÄ, varu apgalvot, ka Å”obrÄ«d diemžÄl Kubernetes nav standartizÄtas mežizstrÄdes iespÄjas, kas bÅ«tu labvÄlÄ«gas salÄ«dzinÄjumÄ ar citÄm. VispopulÄrÄkÄs shÄmas sabiedrÄ«bÄ ir Å”Ädas:
TomÄr es nekavÄÅ”os pie instrukcijÄm to uzstÄdÄ«Å”anai un konfigurÄÅ”anai. TÄ vietÄ es pievÄrsÄ«Å”os to trÅ«kumiem un globÄlÄkiem secinÄjumiem par situÄciju ar baļķiem kopumÄ.
Prakse ar baļķiem K8s
āIkdienas baļķiā, cik no jums tur ir?...
CentralizÄta žurnÄlu vÄkÅ”ana no diezgan lielas infrastruktÅ«ras prasa ievÄrojamus resursus, kas tiks tÄrÄti žurnÄlu vÄkÅ”anai, uzglabÄÅ”anai un apstrÄdei. Darbojoties dažÄdiem projektiem, saskÄrÄmies ar dažÄdÄm prasÄ«bÄm un no tÄm izrietoÅ”Äm darbÄ«bas problÄmÄm.
IzmÄÄ£inÄsim ClickHouse
ApskatÄ«sim centralizÄtu projekta krÄtuvi ar lietojumprogrammu, kas diezgan aktÄ«vi Ä£enerÄ Å¾urnÄlus: vairÄk nekÄ 5000 rindu sekundÄ. SÄksim strÄdÄt ar viÅa žurnÄliem, pievienojot tos ClickHouse.
TiklÄ«dz bÅ«s nepiecieÅ”ams maksimÄlais reÄllaika laiks, 4 kodolu serveris ar ClickHouse jau bÅ«s pÄrslogots diska apakÅ”sistÄmÄ:
Å Äda veida ielÄde ir saistÄ«ta ar to, ka mÄs cenÅ”amies pÄc iespÄjas ÄtrÄk rakstÄ«t ClickHouse. Un datu bÄze uz to reaÄ£Ä ar palielinÄtu diska slodzi, kas var izraisÄ«t Å”Ädas kļūdas:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
Fakts ir tÄds, ka MergeTree tabulas programmÄ ClickHouse (tie satur žurnÄla datus) rakstÄ«Å”anas operÄciju laikÄ ir savas grÅ«tÄ«bas. Tajos ievietotie dati Ä£enerÄ pagaidu nodalÄ«jumu, kas pÄc tam tiek apvienots ar galveno tabulu. RezultÄtÄ ieraksts diskÄ izrÄdÄs ļoti prasÄ«gs, un uz to attiecas arÄ« ierobežojums, par kuru mÄs saÅÄmÄm iepriekÅ” minÄto paziÅojumu: 1 sekundÄ var sapludinÄt ne vairÄk kÄ 300 apakÅ”sadaļas (faktiski tas ir 300 ieliktÅi sekundÄ).
Lai izvairÄ«tos no Å”Ädas uzvedÄ«bas, jÄraksta ClickHouse pÄc iespÄjas lielÄkos gabalos un ne biežÄk kÄ 1 reizi ik pÄc 2 sekundÄm. TomÄr rakstÄ«Å”ana lielos sÄrijÄs liek domÄt, ka ClickHouse vajadzÄtu rakstÄ«t retÄk. Tas savukÄrt var novest pie bufera pÄrpildes un žurnÄlu zuduma. RisinÄjums ir palielinÄt Fluentd buferi, bet tad palielinÄsies arÄ« atmiÅas patÄriÅÅ”.
PiezÄ«me: VÄl viens problemÄtisks aspekts mÅ«su risinÄjumam ar ClickHouse bija saistÄ«ts ar faktu, ka sadalÄ«Å”ana mÅ«su gadÄ«jumÄ (guļbÅ«ves) tiek Ä«stenota, izmantojot ÄrÄjÄs pievienotÄs tabulas. Apvienot tabulu. Tas noved pie tÄ, ka, atlasot lielus laika intervÄlus, ir nepiecieÅ”ams pÄrmÄrÄ«gs RAM, jo metatabula atkÄrtojas caur visiem nodalÄ«jumiem - pat tiem, kuros acÄ«mredzami nav nepiecieÅ”amo datu. TomÄr tagad Å”o pieeju var droÅ”i pasludinÄt par novecojuÅ”u paÅ”reizÄjÄm ClickHouse versijÄm (c 18.16).
RezultÄtÄ kļūst skaidrs, ka ne katram projektam ir pietiekami daudz resursu, lai ClickHouse reÄllaikÄ savÄktu žurnÄlus (precÄ«zÄk, to izplatÄ«Å”ana nebÅ«s piemÄrota). TurklÄt jums bÅ«s jÄizmanto akumulators, pie kura atgriezÄ«simies vÄlÄk. IepriekÅ” aprakstÄ«tais gadÄ«jums ir reÄls. Un tobrÄ«d nevarÄjÄm piedÄvÄt uzticamu un stabilu risinÄjumu, kas atbilstu klientam un ļautu savÄkt baļķus ar minimÄlu kavÄÅ”anos...
KÄ ar Elasticsearch?
Ir zinÄms, ka Elasticsearch iztur lielas darba slodzes. IzmÄÄ£inÄsim to tajÄ paÅ”Ä projektÄ. Tagad slodze izskatÄs Å”Ädi:
Elasticsearch spÄja sagremot datu straumi, tomÄr Å”Ädu apjomu ierakstÄ«Å”ana ievÄrojami izmanto centrÄlo procesoru. To izlemj, organizÄjot klasteru. Tehniski tÄ nav problÄma, bet izrÄdÄs, ka tikai baļķu savÄkÅ”anas sistÄmas darbÄ«bai mÄs jau izmantojam aptuveni 8 kodolus un sistÄmÄ ir papildus ļoti noslogota komponente...
SecinÄjums: Ŕī iespÄja var bÅ«t pamatota, taÄu tikai tad, ja projekts ir liels un tÄ vadÄ«ba ir gatava tÄrÄt ievÄrojamus resursus centralizÄtai mežizstrÄdes sistÄmai.
Tad rodas dabisks jautÄjums:
KÄdi baļķi patieÅ”Äm ir nepiecieÅ”ami?
MÄÄ£inÄsim mainÄ«t paÅ”u pieeju: žurnÄliem vienlaikus jÄbÅ«t informatÄ«viem, nevis aptveroÅ”iem ikviens notikums sistÄmÄ.
PieÅemsim, ka mums ir veiksmÄ«gs tieÅ”saistes veikals. KÄdi žurnÄli ir svarÄ«gi? SavÄkt pÄc iespÄjas vairÄk informÄcijas, piemÄram, no maksÄjumu vÄrtejas, ir lieliska ideja. Bet ne visi žurnÄli no attÄlu sagrieÅ”anas pakalpojuma produktu katalogÄ mums ir kritiski: pietiek tikai ar kļūdÄm un uzlaboto uzraudzÄ«bu (piemÄram, Ŕī komponenta Ä£enerÄto kļūdu procentuÄlÄ daļa no 500).
TÄtad esam nonÄkuÅ”i pie secinÄjuma, ka centralizÄta mežizstrÄde ne vienmÄr ir attaisnojama. Ä»oti bieži klients vÄlas apkopot visus žurnÄlus vienuviet, lai gan patiesÄ«bÄ no visa žurnÄla ir nepiecieÅ”ami tikai nosacÄ«ti 5% no biznesam kritiskiem ziÅojumiem:
Dažreiz pietiek konfigurÄt, teiksim, tikai konteinera žurnÄla izmÄru un kļūdu savÄcÄju (piemÄram, Sentry).
NegadÄ«jumu izmeklÄÅ”anai bieži vien var pietikt ar kļūdu paziÅojumu un lielu lokÄlo žurnÄlu.
Mums bija projekti, kas iztika tikai ar funkcionÄliem testiem un kļūdu vÄkÅ”anas sistÄmÄm. IzstrÄdÄtÄjam žurnÄli kÄ tÄdi nebija vajadzÄ«gi - viÅi redzÄja visu, sÄkot no kļūdu pÄdÄm.
IlustrÄcija no dzÄ«ves
KÄ labs piemÄrs var kalpot kÄds cits stÄsts. MÄs saÅÄmÄm pieprasÄ«jumu no viena mÅ«su klienta droŔības komandas, kurÅ” jau izmantoja komerciÄlu risinÄjumu, kas tika izstrÄdÄts ilgi pirms Kubernetes ievieÅ”anas.
Bija nepiecieÅ”ams āsadraudzÄtiesā ar centralizÄto žurnÄlu vÄkÅ”anas sistÄmu ar korporatÄ«vo problÄmu noteikÅ”anas sensoru - QRadar. Å Ä« sistÄma var saÅemt žurnÄlus, izmantojot syslog protokolu, un izgÅ«t tos no FTP. TomÄr uzreiz nebija iespÄjams to integrÄt ar fluentd spraudni remote_syslog (kÄ izrÄdÄ«jÄs, mÄs neesam vieni). ProblÄmas ar QRadar iestatÄ«Å”anu izrÄdÄ«jÄs klienta droŔības komandas pusÄ.
RezultÄtÄ daļa biznesam bÅ«tisko žurnÄlu tika augÅ”upielÄdÄta FTP QRadar, bet otra daļa tika novirzÄ«ta, izmantojot attÄlo syslog tieÅ”i no mezgliem. Par to mÄs pat rakstÄ«jÄm vienkÄrÅ”a diagramma - varbÅ«t tas palÄ«dzÄs kÄdam atrisinÄt lÄ«dzÄ«gu problÄmu... Pateicoties izveidotajai shÄmai, klients pats saÅÄma un analizÄja kritiskos žurnÄlus (izmantojot savus iecienÄ«tÄkos rÄ«kus), un mÄs varÄjÄm samazinÄt reÄ£istrÄÅ”anas sistÄmas izmaksas, ietaupot tikai pagÄjuÅ”ajÄ mÄnesÄ«.
VÄl viens piemÄrs liecina par to, ko nevajadzÄtu darÄ«t. Viens no mÅ«su klientiem apstrÄdei no katra notikumi, kas nÄk no lietotÄja, izveidoti vairÄkÄs rindÄs nestrukturÄta produkcija informÄcija žurnÄlÄ. KÄ jÅ«s varÄtu nojaust, Å”Ädus žurnÄlus bija ÄrkÄrtÄ«gi neÄrti gan lasÄ«t, gan uzglabÄt.
KritÄriji apaļkokiem
Å Ädi piemÄri liek secinÄt, ka papildus baļķu savÄkÅ”anas sistÄmas izvÄlei jums ir nepiecieÅ”ams projektÄt arÄ« paÅ”us baļķus! KÄdas Å”eit ir prasÄ«bas?
ŽurnÄliem ir jÄbÅ«t maŔīnlasÄmÄ formÄtÄ (piemÄram, JSON).
ŽurnÄliem jÄbÅ«t kompaktiem un ar iespÄju mainÄ«t reÄ£istrÄÅ”anas pakÄpi, lai atkļūdotu iespÄjamÄs problÄmas. TajÄ paÅ”Ä laikÄ ražoÅ”anas vidÄs jums vajadzÄtu palaist sistÄmas ar tÄdu reÄ£istrÄÅ”anas lÄ«meni kÄ brÄ«dinÄjums vai kļūda.
ŽurnÄliem jÄbÅ«t normalizÄtiem, tas ir, žurnÄla objektÄ visÄm rindÄm jÄbÅ«t vienÄdam lauka tipam.
NestrukturÄti apaļkoki var radÄ«t problÄmas ar baļķu iekrauÅ”anu noliktavÄ un to apstrÄdes pilnÄ«gu apturÄÅ”anu. IlustrÄcijai Å”eit ir piemÄrs ar kļūdu 400, ar kuru daudzi noteikti ir saskÄruÅ”ies fluentd žurnÄlos:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
Kļūda nozÄ«mÄ, ka jÅ«s sÅ«tÄt indeksam lauku, kura veids ir nestabils, ar gatavu kartÄÅ”anu. VienkÄrÅ”Äkais piemÄrs ir lauks nginx žurnÄlÄ ar mainÄ«go $upstream_status. TajÄ var bÅ«t gan skaitlis, gan virkne. PiemÄram:
ŽurnÄli liecina, ka serveris 10.100.0.10 atbildÄja ar kļūdu 404 un pieprasÄ«jums tika nosÅ«tÄ«ts uz citu satura krÄtuvi. RezultÄtÄ vÄrtÄ«ba žurnÄlos kļuva Å”Äda:
"upstream_response_time": "0.001, 0.007"
Å Ä« situÄcija ir tik izplatÄ«ta, ka tÄ pat ir pelnÄ«jusi atseviŔķu atsauces dokumentÄcijÄ.
KÄ ar uzticamÄ«bu?
Ir reizes, kad visi žurnÄli bez izÅÄmuma ir vitÄli svarÄ«gi. Un lÄ«dz ar to ir problÄmas ar tipiskajÄm baļķu savÄkÅ”anas shÄmÄm K8s, kas ierosinÄtas / apspriestas iepriekÅ”.
PiemÄram, fluentd nevar savÄkt baļķus no Ä«slaicÄ«giem konteineriem. VienÄ no mÅ«su projektiem datu bÄzes migrÄcijas konteiners darbojÄs mazÄk nekÄ 4 sekundes un pÄc tam tika dzÄsts - saskaÅÄ ar attiecÄ«go anotÄciju:
"helm.sh/hook-delete-policy": hook-succeeded
Å Ä« iemesla dÄļ migrÄcijas izpildes žurnÄls netika iekļauts krÄtuvÄ. Politika Å”ajÄ gadÄ«jumÄ var palÄ«dzÄt. before-hook-creation.
VÄl viens piemÄrs ir Docker žurnÄla rotÄcija. PieÅemsim, ka ir lietojumprogramma, kas aktÄ«vi raksta žurnÄlos. NormÄlos apstÄkļos mums izdodas apstrÄdÄt visus žurnÄlus, taÄu, tiklÄ«dz parÄdÄs problÄma ā piemÄram, kÄ aprakstÄ«ts iepriekÅ” ar nepareizu formÄtu ā apstrÄde apstÄjas, un Docker pagriež failu. RezultÄtÄ var tikt zaudÄti biznesam svarÄ«gi žurnÄli.
TÄpÄc svarÄ«gi ir atdalÄ«t žurnÄlu plÅ«smas, iegulstot vÄrtÄ«gÄkos nosÅ«tot tieÅ”i lietojumprogrammÄ, lai nodroÅ”inÄtu to droŔību. TurklÄt nebÅ«tu lieki dažus izveidot baļķu āakumulatorsā., kas var izturÄt Ä«slaicÄ«gu krÄtuves nepieejamÄ«bu, vienlaikus saglabÄjot svarÄ«gus ziÅojumus.
Visbeidzot, mÄs nedrÄ«kstam to aizmirst Ir svarÄ«gi pareizi uzraudzÄ«t jebkuru apakÅ”sistÄmu. PretÄjÄ gadÄ«jumÄ ir viegli nonÄkt situÄcijÄ, kurÄ fluentd atrodas stÄvoklÄ« CrashLoopBackOff un neko nesÅ«ta, un tas sola svarÄ«gas informÄcijas zaudÄÅ”anu.
Atzinumi
Å ajÄ rakstÄ mÄs neaplÅ«kojam SaaS risinÄjumus, piemÄram, Datadog. Daudzas no Å”eit aprakstÄ«tajÄm problÄmÄm vienÄ vai otrÄ veidÄ jau ir atrisinÄjuÅ”as komercuzÅÄmumi, kas specializÄjas žurnÄlu vÄkÅ”anÄ, taÄu ne visi dažÄdu iemeslu dÄļ var izmantot SaaS (galvenÄs ir izmaksas un atbilstÄ«ba 152-FZ).
CentralizÄta žurnÄlu vÄkÅ”ana sÄkotnÄji Ŕķiet vienkÄrÅ”s uzdevums, taÄu tÄ nebÅ«t nav. Ir svarÄ«gi atcerÄties, ka:
DetalizÄti jÄreÄ£istrÄ tikai kritiskie komponenti, savukÄrt pÄrraudzÄ«bu un kļūdu apkopoÅ”anu var konfigurÄt citÄm sistÄmÄm.
RažoÅ”anÄ apaļkokiem jÄbÅ«t minimÄliem, lai neradÄ«tu nevajadzÄ«gu slodzi.
ŽurnÄliem jÄbÅ«t maŔīnlasÄmiem, normalizÄtiem un stingrÄ formÄtÄ.
TieÅ”Äm kritiskie žurnÄli jÄsÅ«ta atseviÅ”Ä·Ä straumÄ, kas jÄnodala no galvenajiem.
Ir vÄrts apsvÄrt baļķu akumulatoru, kas var glÄbt jÅ«s no lielas slodzes uzliesmojumiem un padarÄ«t noliktavas slodzi vienmÄrÄ«gÄku.
Å ie vienkÄrÅ”ie noteikumi, ja tie tiek piemÄroti visur, ļautu iepriekÅ” aprakstÄ«tajÄm shÄmÄm darboties, pat ja tÄm trÅ«kst svarÄ«gu komponentu (akumulatora). Ja jÅ«s neievÄrosiet Å”Ädus principus, uzdevums jÅ«s un infrastruktÅ«ru viegli novedÄ«s pie citas ļoti noslogotas (un tajÄ paÅ”Ä laikÄ neefektÄ«vas) sistÄmas sastÄvdaļas.