2019a da, eta oraindik ez dugu Kubernetes-en log-ak agregatzeko irtenbide estandarrik. Artikulu honetan, praktika errealeko adibideak erabiliz, gure bilaketak, aurkitutako arazoak eta haien konponbideak partekatu nahiko genituzke.
Hala ere, lehenik eta behin, erreserba bat egingo dut bezero ezberdinek gauza oso desberdinak ulertzen dituzten erregistroak bilduz:
- norbaitek segurtasun eta auditoretza erregistroak ikusi nahi ditu;
- norbait - azpiegitura osoaren erregistro zentralizatua;
- eta batzuentzat nahikoa da aplikazioen erregistroak soilik biltzea, adibidez, orekatzaileak kenduta.
Jarraian, hainbat "desioen zerrenda" nola inplementatu genituen eta zein zailtasun aurkitu genituen.
Teoria: erregistro-tresnei buruz
Erregistro-sistema baten osagaiei buruzko aurrekariak
Erregistroak bide luzea egin du, eta horren ondorioz erregistroak biltzeko eta aztertzeko metodologiak garatu dira, gaur egun erabiltzen duguna. 1950eko hamarkadan, Fortran-ek sarrera/irteera korronte estandarren analogo bat sartu zuen, programatzaileari bere programa arazketan lagundu zion. Hauek izan ziren garai haietako programatzaileei bizitza errazten zien lehen erregistro informatikoak. Gaur egun horietan ikusten dugu erregistro-sistemaren lehen osagaia - erregistroen iturria edo "ekoizlea"..
Informatika ez zen geldirik egon: sare informatikoak agertu ziren, lehen klusterrak... Hainbat ordenagailuz osatutako sistema konplexuak hasi ziren lanean. Orain sistema-administratzaileak hainbat makinatako erregistroak biltzera behartuta zeuden, eta kasu berezietan OS kernel mezuak gehi ditzakete, sistemaren hutsegite bat ikertu behar bazuten. Erregistro bilketa sistema zentralizatuak deskribatzeko, 2000ko hamarkadaren hasieran argitaratu zen , remote_syslog estandarizatu zuena. Honela agertu zen beste osagai garrantzitsu bat: erregistro-biltzailea eta haien biltegiratzea.
Erregistroen bolumena handituz eta web teknologien sarrera hedatuarekin, erabiltzaileei zer erregistro erakutsi behar zaien galdera sortu zen. Kontsola tresna soilak (awk/sed/grep) aurreratuagoekin ordezkatu dira erregistro-ikusleak - Hirugarren osagaia.
Erregistroen bolumena handitu zela eta, beste zerbait argi geratu zen: erregistroak behar dira, baina ez guztiak. Eta enbor ezberdinek kontserbazio maila desberdinak behar dituzte: batzuk egun batean gal daitezke, eta beste batzuk 5 urtez gorde behar dira. Beraz, datu-fluxuak iragazteko eta bideratzeko osagai bat gehitu zen erregistro-sistemara - deitu dezagun iragazkia.
Biltegiratzeak ere jauzi handia eman du: fitxategi arruntetatik datu-base erlazionaletara, eta gero dokumentuetara bideratutako biltegiratzera (adibidez, Elasticsearch). Beraz, biltegia kolektoretik bereizi zen.
Azken finean, erregistroaren kontzeptua bera historiarako gorde nahi dugun gertaeren korronte abstraktu batera hedatu da. Edo hobeto esanda, ikerketa bat egin edo txosten analitiko bat egin behar baduzu...
Ondorioz, denbora-tarte nahiko laburrean, erregistro-bilketa azpisistema garrantzitsu bat bihurtu da, eta hori zuzen dei daiteke Big Dataren azpiataletako bat.
Garai batean inprimaketa arruntak nahikoa baziren “erregistro-sistema” baterako, orain egoera asko aldatu da.
Kubernetes eta erregistroak
Kubernetes azpiegiturara iritsi zenean, lehendik zegoen erregistroak biltzeko arazoak ere ez zuen saihestu. Nolabait, are mingarriagoa bihurtu zen: azpiegituren plataforma kudeatzea erraztu ez ezik, korapilatu ere egin zen aldi berean. Zerbitzu zahar asko mikrozerbitzuetara migratzen hasi dira. Erregistroen testuinguruan, hori gero eta handiagoa den erregistro-iturrietan, haien bizi-ziklo berezian eta sistemaren osagai guztien erlazioen jarraipena erregistroen bidez islatzen da...
Aurrera begira, esan dezaket orain, zoritxarrez, ez dagoela Kubernetes-en erregistro-aukera estandarizaturik, beste guztiekin alderatuko litzatekeena. Komunitatean gehien erabiltzen diren eskemak hauek dira:
- norbaitek pila zabaltzen du EFK (Elasticsearch, Fluentd, Kibana);
- norbait da berriki ateratakoa probatzen edo erabilerak ;
- gurekin (eta agian ez gu bakarrik?..) Nere garapenarekin oso pozik nago - ...
Oro har, honako sorta hauek erabiltzen ditugu K8s klusterretan (auto-ostatatutako soluzioetarako):
- ;
- .
Hala ere, ez naiz haien instalazio eta konfiguraziorako argibideetan luzatuko. Horren ordez, haien gabezietan eta orokorrean erregistroen egoerari buruzko ondorio globalagoetan zentratuko naiz.
K8-ko erregistroekin praktikatu
“Eguneroko erregistroak”, zenbat zarete?...
Azpiegitura handi samarreko erregistroen bilketa zentralizatuak baliabide handiak behar ditu, erregistroak biltzeko, gordetzeko eta prozesatzeko erabiliko direnak. Hainbat proiekturen funtzionamenduan zehar, horietatik eratorritako hainbat eskakizun eta funtzionamendu arazoren aurrean izan ginen.
Saia gaitezen ClickHouse
Ikus dezagun biltegiratze zentralizatu bat nahiko aktiboki erregistroak sortzen dituen aplikazio batekin proiektu batean: 5000 lerro baino gehiago segundoko. Has gaitezen bere erregistroekin lanean, ClickHouse-ra gehituz.
Gehieneko denbora errealean behar den bezain laster, ClickHouse duen 4 nukleoko zerbitzaria dagoeneko gainkargatuko da disko azpisisteman:
Karga mota hau ClickHousen ahalik eta azkarren idazten saiatzen ari garelako da. Eta datu-baseak diskoaren karga handituz erreakzionatzen du, eta horrek errore hauek sor ditzake:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
Izan ere dela ClickHouse-n (erregistro-datuak dituzte) bere zailtasunak dituzte idazketa-eragiketetan. Horietan txertatutako datuek behin-behineko partizioa sortzen dute, eta gero taula nagusiarekin bateratzen da. Ondorioz, grabazioa oso zorrotza bihurtzen da diskoan, eta goian jasotako oharrean jaso dugun mugaren menpe dago ere: ezin dira 1 azpipartizio baino gehiago batu segundo batean (hain zuzen ere, hau da 300 txertaketa). segundoko).
Jokabide hori saihesteko, ahalik eta zati handienetan eta gehienez 1 aldiz 2 segundoro. Hala ere, leherketa handietan idazteak ClickHousen maizago idatzi beharko genukeela iradokitzen du. Horrek, aldi berean, buffer gainezkatzea eta erregistroak galtzea ekar dezake. Irtenbidea Fluentd buffer-a handitzea da, baina gero memoria-kontsumoa ere handituko da.
Kontuan izan: ClickHouse-rekin dugun irtenbidearen beste alderdi problematiko bat gure kasuan partizioa (loghouse) kanpoko taulen bidez inplementatzen dela lotuta zegoen. . Horrek denbora-tarte handiak lagintzean gehiegizko RAM behar izatea dakar, metataulak partizio guztietan zehar errepikatzen duelako, baita, jakina, beharrezko datuak ez dituztenak ere. Hala ere, orain hurbilketa hau segurtasunez zaharkituta deklara daiteke ClickHouse-ren egungo bertsioetarako (c ).
Ondorioz, argi geratzen da proiektu guztiek ez dutela nahikoa baliabide erregistroak denbora errealean biltzeko ClickHousen (zehazkiago, haien banaketa ez da egokia izango). Horrez gain, erabili beharko duzu аккумулятор, gerora itzuliko gara. Goian azaldutako kasua benetakoa da. Eta garai hartan ezin izan genuen irtenbide fidagarri eta egonkorrik eskaini bezeroari egokituko zitzaion eta erregistroak gutxieneko atzerapenarekin biltzeko aukera emango zigun...
Zer gertatzen da Elasticsearch?
Elasticsearch-ek lan karga astunak kudeatzen dituela ezaguna da. Saia gaitezen proiektu berean. Orain karga honelakoa da:
Elasticsearch-ek datu-jarioa digeritzeko gai izan zen, hala ere, bolumen horiek idazteak CPUa asko erabiltzen du. Hau kluster bat antolatuz erabakitzen da. Teknikoki, hau ez da arazo bat, baina ikusten da erregistroak biltzeko sistema funtzionatzeko dagoeneko 8 nukleo inguru erabiltzen ditugula eta sisteman oso kargatutako osagai gehigarri bat dugula...
Beheko lerroa: aukera hau justifika daiteke, baina proiektua handia bada eta bere kudeaketa prest badago erregistro-sistema zentralizatu batean baliabide garrantzitsuak gastatzeko.
Orduan galdera natural bat sortzen da:
Zein erregistro behar dira benetan?
Saia gaitezen ikuspegia bera aldatzen: erregistroak aldi berean informatiboak izan behar dira eta ez estaltzen bakoitzeko gertaera sisteman.
Demagun online denda arrakastatsua dugula. Zein erregistro dira garrantzitsuak? Ahalik eta informazio gehien biltzea, adibidez, ordainketa pasabide batetik, ideia bikaina da. Baina produktuen katalogoko irudiak zatitzeko zerbitzuko erregistro guztiak ez dira guretzat kritikoak: akatsak eta monitorizazio aurreratua baino ez dira nahikoa (adibidez, osagai horrek sortzen duen 500 akatsen ehunekoa).
Beraz, hori ondorioztatu dugu erregistro zentralizatua ez da beti justifikatzen. Askotan bezeroak erregistro guztiak leku bakarrean bildu nahi ditu, nahiz eta, egia esan, erregistro osotik negoziorako kritikoak diren mezuen % 5 baldintzatua soilik behar den:
- Batzuetan nahikoa da, esate baterako, edukiontzien erregistroaren eta errore-biltzaileen tamaina soilik konfiguratzea (adibidez, Sentry).
- Erroreen jakinarazpena eta tokiko erregistro handi bat nahikoa izan daitezke gertakariak ikertzeko.
- Proba funtzionalekin eta akatsak biltzeko sistema esklusiboekin eginiko proiektuak genituen. Garatzaileak ez zuen erregistrorik behar, hala nola, akatsen arrastoetatik dena ikusi zuten.
Bizitzaren ilustrazioa
Beste istorio bat adibide ona izan daiteke. Kubernetes sartu baino askoz lehenago garatu zen irtenbide komertzial bat erabiltzen ari zen gure bezeroetako baten segurtasun-taldearen eskaera jaso genuen.
Beharrezkoa zen erregistro-bilketa sistema zentralizatuaren "lagunak egitea" arazo korporatiboen detektatzeko sentsorearekin - QRadar. Sistema honek log-ak jaso ditzake syslog protokoloaren bidez eta FTP-tik berreskura ditzake. Hala ere, ezin izan zen berehala integratzea remote_syslog plugin-arekin fluentd-erako (gertatu zenez, ). QRadar konfiguratzeko arazoak bezeroaren segurtasun taldearen alde egon ziren.
Ondorioz, negozioaren erregistro kritikoen zati bat FTP QRadar-era kargatu zen, eta beste zatia urruneko syslog bidez zuzenean nodoetatik birbideratu zen. Horretarako idatzi ere egin dugu - agian norbaitek antzeko arazo bat konpontzen lagunduko dio... Sortutako eskemari esker, bezeroak berak erregistro kritikoak jaso eta aztertu zituen (bere gogoko tresnak erabiliz), eta erregistro-sistemaren kostua murrizteko gai izan ginen, bakarrik aurreztuz. azken hilabetean.
Beste adibide bat nahiko adierazgarria da zer ez egin behar den. Prozesatzeko gure bezeroetako bat bakoitzeko erabiltzailearengandik datozen gertaerak, linea anitzeko egina irteera ez egituratua erregistroan dagoen informazioa. Asma dezakezun bezala, horrelako erregistroak oso deserosoak ziren irakurtzeko eta gordetzeko.
Erregistroetarako irizpideak
Horrelako adibideek ondorioztatzen dute erregistroak biltzeko sistema aukeratzeaz gain, behar duzula erregistroak beraiek ere diseinatu! Zeintzuk dira hemen baldintzak?
- Erregistroak makinaz irakur daitekeen formatuan egon behar dira (adibidez, JSON).
- Erregistroak trinkoak eta erregistro-maila aldatzeko gaitasuna izan behar dute, arazo posibleak arazteko. Aldi berean, ekoizpen-inguruneetan bezalako erregistro-maila duten sistemak exekutatu beharko dituzu abisu edo Errorea.
- Erregistroak normalizatu behar dira, hau da, erregistro-objektu batean, lerro guztiek eremu-mota bera izan behar dute.
Egituratu gabeko erregistroek erregistroak biltegian kargatzeko arazoak sor ditzakete eta prozesatzeko erabat gelditzea. Ilustrazio gisa, hona hemen 400 errorea duen adibide bat, askok behin betiko topatu duten erregistro jarioetan:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
Erroreak esan nahi du bere mota ezegonkorra den eremu bat bidaltzen ari zarela indizera prest egindako mapa batekin. Adibiderik errazena nginx erregistroko eremu bat da aldagai batekin $upstream_status. Zenbaki bat edo kate bat izan dezake. Adibidez:
{ "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"}
Erregistroek erakusten dute 10.100.0.10 zerbitzariak 404 errore batekin erantzun zuela eta eskaera beste eduki biltegi batera bidali zela. Ondorioz, erregistroetako balioa honela geratu zen:
"upstream_response_time": "0.001, 0.007"
Egoera hau hain da ohikoa ezen aparteko bat ere merezi duela .
Eta fidagarritasunaz?
Aldiz, erregistro guztiak ezinbestekoak dira salbuespenik gabe. Eta honekin, goian proposatutako/eztabaidatutako K8rako log-bilketa eskem tipikoek arazoak dituzte.
Esate baterako, fluentd-ek ezin ditu erregistroak bildu iraupen laburreko edukiontzietatik. Gure proiektuetako batean, datu-basearen migrazio-edukiontzi bat 4 segundo baino gutxiagoz bizi izan zen eta gero ezabatu egin zen, dagokion oharpenaren arabera:
"helm.sh/hook-delete-policy": hook-succeeded
Hori dela eta, migrazioaren exekuzio erregistroa ez zen biltegian sartu. Politikak lagun dezake kasu honetan. before-hook-creation.
Beste adibide bat Docker erregistroaren biraketa da. Demagun erregistroetan aktiboki idazten duen aplikazio bat dagoela. Baldintza normaletan, erregistro guztiak prozesatzea lortzen dugu, baina arazoren bat agertzen den bezain laster, adibidez, goian deskribatutako formatu oker batekin, prozesatzea gelditzen da eta Docker-ek fitxategia biratzen du. Ondorioz, negozioaren erregistro kritikoak gal daitezke.
Horregatik garrantzitsua da erregistro-korronteak bereiztea, baliotsuenak zuzenean aplikaziora bidaliz txertatuz, haien segurtasuna bermatzeko. Horrez gain, ez litzateke soberan egongo batzuk sortzea erregistroen “metagailua”., biltegiratze labur baten erabilgarritasunik gabe iraun dezakeena, mezu kritikoak gordetzen dituen bitartean.
Azkenik, hori ez dugu ahaztu behar Garrantzitsua da edozein azpisistema behar bezala kontrolatzea. Bestela, erraza da fluentd egoera batean dagoen egoera batean topo egitea CrashLoopBackOff eta ez du ezer bidaltzen, eta honek informazio garrantzitsua galtzea agintzen du.
Findings
Artikulu honetan, ez ditugu Datadog bezalako SaaS irtenbideak aztertzen. Hemen deskribatutako arazo asko erregistroak biltzen espezializatutako merkataritza-enpresek modu batean edo bestean konpondu dituzte dagoeneko, baina denek ezin dute SaaS erabili hainbat arrazoirengatik. (nagusiak kostua eta 152-FZ betetzea dira).
Erregistro-bilketa zentralizatua hasieran zeregin sinple bat dirudi, baina ez da batere. Garrantzitsua da gogoratzea:
- Osagai kritikoak soilik xehetasunez erregistratu behar dira, monitorizazioa eta akatsen bilketa beste sistemetarako konfiguratu daitezkeen bitartean.
- Ekoizpeneko erregistroak minimoak izan behar dira, alferrikako karga ez gehitzeko.
- Erregistroak makinaz irakurgarriak izan behar dira, normalizatuak eta formatu zorrotza izan behar dute.
- Erregistro benetan kritikoak korronte bereizi batean bidali behar dira, nagusietatik bereizita egon beharko lukeena.
- Merezi du egur metagailu bat kontuan hartzea, karga handiko leherketetatik salbatzeko eta biltegiaren karga uniformeagoa izan dadin.
Arau sinple hauek, nonahi aplikatuz gero, goian deskribatutako zirkuituak funtzionatuko lukete, osagai garrantzitsuak (bateria) falta badituzte ere. Printzipio horiek betetzen ez badituzu, zereginak erraz eramango zaitu zu eta azpiegitura sistemaren oso kargatutako (eta, aldi berean, eraginkortasunik gabeko) beste osagai batera.
PS
Irakurri ere gure blogean:
- «»;
- «»;
- «'.
Iturria: www.habr.com