Žurnāli Kubernetes (un ne tikai) Ŕodien: gaidas un realitāte

Ž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.

Žurnāli Kubernetes (un ne tikai) Ŕodien: gaidas un realitāte
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:

  • kāds atritina kaudzi EFK (Elasticsearch, Fluentd, Kibana);
  • kāds mēģina nesen izdoto Loki vai lietojumiem Mežizstrādes operators;
  • mums (un varbÅ«t ne tikai mēs?..) Esmu lielā mērā apmierināts ar savu attÄ«stÄ«bu - guļbÅ«ve...

Parasti K8s klasteros (paÅ”mitinātiem risinājumiem) mēs izmantojam Ŕādus komplektus:

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

Žurnāli Kubernetes (un ne tikai) Ŕodien: gaidas un realitāte

ā€œ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ā:

Žurnāli Kubernetes (un ne tikai) Ŕodien: gaidas un realitāte

Šā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:

Žurnāli Kubernetes (un ne tikai) Ŕodien: gaidas un realitāte

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?

Žurnāli Kubernetes (un ne tikai) Å”odien: gaidas un realitāte 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:

{ "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"}

Ž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.

Žurnāli Kubernetes (un ne tikai) Ŕodien: gaidas un realitāte
Å 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.

PS

Lasi arī mūsu emuārā:

Avots: www.habr.com

Pievieno komentāru