Viti 2019, dhe ne ende nuk kishim një zgjidhje standard për agregimin e logeve në Kubernetes. Në këtë artikull, do të doja të ndaj përvojat tona, sfidat që hasëm dhe zgjidhjet e tyre, duke përdorur shembuj nga praktika reale.
Megjithatë, përpara se të filloj, dua të theksoj se ndryshkohen pritjet e ndryshme të klientëve në lidhje me mbledhjen e logeve:
- disa duan të shohin loget e sigurisë dhe auditimit;
- disa â logimin e centralizuar tĂ« gjithĂ« infrastrukturĂ«s;
- ndërsa disa janë të kënaqur vetëm me mbledhjen e logeve të aplikacioneve, duke përjashtuar, për shembull, balancuesit.
Për atë se si ne zbatuam të ndryshmet 'për dëshira' dhe me çfarë vështirësish u përballëm, lexoni më poshtë.
Teoria: për mjetet për loge
Historia e përbërësve të sistemit të logimit
Logimi ka kaluar njĂ« rrugĂ« tĂ« gjatĂ«, gjatĂ« sĂ« cilĂ«s janĂ« zhvilluar metodologjitĂ« e mbledhjes dhe analizĂ«s sĂ« logeve, qĂ« ne pĂ«rdorim sot. QĂ« nĂ« vitet 1950 nĂ« Fortran u shfaq njĂ« ekuivalent i rrjedhave standarde tĂ« input-it dhe output-it, qĂ« ndihmonte programuesit nĂ« depurimin e programeve tĂ« tyre. KĂ«to ishin loget e para kompjuterike qĂ« lehtĂ«suan jetĂ«n e programuesve tĂ« asaj kohe. Sot, ne i shohim kĂ«to si pĂ«rbĂ«rĂ«sin e parĂ« tĂ« sistemit tĂ« logimit â burimi ose 'prodhuesi' (producer) i logeve.
Shkenca kompjuterike nuk qëndroi në vend: u shfaqën rrjetet kompjuterike, klasterët e parë... Filluan të funksiononin sisteme të komplikuara, të përbëra nga disa kompjuterë. Tani adminët sistemorë ishin të detyruar të mbledhin loge nga disa makina, dhe në raste të veçanta, mund të shtonin edhe mesazhe nga bërthama e sistemit operativ në rast se do të nevojitej një hetim për ndonjë dështim sistemor. Për të përshkruar sistemet e mbledhjes së logeve në mënyrë të centralizuar, në fillim të viteve 2000 doli , i cili standardizoi remote_syslog. Kështu, u shfaq një përbërës tjetër i rëndësishëm: kollektori (grumbulluesi) i logeve dhe depoja e tyre.
Me rritjen e volumit tĂ« logeve dhe pĂ«rhapjen e teknologjive tĂ« uebit, u shfaq pyetja se si loget t'u tregohet pĂ«rdoruesve nĂ« mĂ«nyrĂ« tĂ« rehatshme. NĂ« vend tĂ« mjeteve tĂ« zakonshme tĂ« konsolĂ«s (awk/sed/grep) erdhĂ«n 'shikuesit e logeve' â pĂ«rbĂ«rĂ«si i tretĂ«. Me rritjen e volumit tĂ« logeve u bĂ« e qartĂ« edhe diçka tjetĂ«r: loget janĂ« tĂ« nevojshme, por jo tĂ« gjitha. Dhe loget e ndryshme kĂ«rkojnĂ« nivele tĂ« ndryshme tĂ« ruajtjes: disa mund tĂ« humbasin pas njĂ« dite, ndĂ«rsa tĂ« tjera duhet tĂ« ruhen pĂ«r 5 vjet. KĂ«shtu, nĂ« sistemin e logimit u shtua njĂ« pĂ«rbĂ«rĂ«s filtrimi dhe rrugĂ«zimi i flukseve tĂ« tĂ« dhĂ«nave â ta quajmĂ«
filtri. Depo të dhënash gjithashtu bënë një skak të rëndësishëm: kaluan nga skedarët e zakonshëm në baza të dhënash relationale, e më pas në depo të orientuara nga dokumentet (për shembull, Elasticsearch). Kështu, kolektori u nda nga depoja..
MĂ« nĂ« fund, vetĂ« koncepti i logut u zgjerua nĂ« njĂ« rrjedhĂ« abstrakte ngjarjesh qĂ« duam tĂ« ruajmĂ« pĂ«r histori. MĂ« saktĂ«sisht â pĂ«r rastin kur do tĂ« nevojitet njĂ« hetim ose tĂ« pĂ«rgatitet njĂ« raport analitik...
Si rezultat, brenda një kohe relativisht të shkurtër, mbledhja e logeve u zhvillua në një nën-sistem të rëndësishëm, që e meriton të quhet një nga nënkatet në Big Data.
Nëse dikur printimet e zakonshme mund të ishin të mjaftueshme për 'sistemin e logimit', tani situata është ndjeshëm e ndryshuar.
Kubernetes dhe loget
Kur Kubernetes erdhi në infrastrukturë, problemi ekzistues i mbledhjes së logeve nuk e shmangu atë. Në njëfarë mënyre, u bë edhe më i mprehtë: menaxhimi i platformës infrastrukturore u thjeshtësua, por njëkohësisht u komplikuar. Shumë shërbime të vjetra filluan migrimin në rregullat e mikrosherbimeve. Në kontekstin e logeve, kjo u shpreh në numrin në rritje të burimeve të logeve, ciklit të tyre të veçantë të jetës dhe nevojës për të ndjekur përmes logeve lidhjet e të gjitha përbërësve të sistemit...
Duke shkuar përpara, mund të konstatoni se tani, fatkeqësisht, nuk ka një variant të standardizuar të logimit për Kubernetes, që do të dallonte dukshëm nga të gjitha të tjerat. Skemat më të njohura në komunitet shkurtikohen në:
disa e zhvillojnë stekun
- EFK (Elasticsearch, Fluentd, Kibana); disa â provojnĂ« versionin e sapo lĂ«shuar
- ose përdorin operatorin e logimit ;
- (ndoshta, dhe jo vetĂ«m ne?...) nĂ« shumĂ« aspekte na pĂ«rshtatet zhvillimi ynĂ« i brendshĂ«m â Zakonisht, ne pĂ«rdorim kĂ«to kombinime nĂ« klasteret K8s (pĂ«r zgjidhjet nĂ« vetĂ«-hostim): âŠ
Fluentd + Elasticsearch + Kibana
- ;
- .
Praktika me loget në K8s
'Loget e përditshme', sa shumë jeni ju?..
'Log-ët e përditshme', sa shumë jeni ju?..
Grumbullimi i centralizuar i regjistrimeve nga një infrastrukturë mjaft të madhe kërkon burime të konsiderueshme, të cilat do të shpenzohen për mbledhjen, ruajtjen dhe përpunimin e regjistrimeve. Gjatë përdorimit të projekteve të ndryshme ne jemi përballur me kërkesa të ndryshme dhe problemet që shfaqen për shkak të tyre.
Le të provojmë ClickHouse
Le të shqyrtojmë një depo të centralizuar në një projekt me një aplikacion që gjeneron mjaft regjistrime: më shumë se 5000 rreshta në sekondë. Le të fillojmë të punojmë me regjistrimet e tij, duke i ruajtur ato në ClickHouse.
Sa herë që kërkohet maksimumi në kohë reale, një server me 4 bërthama me ClickHouse do të jetë tashmë i ngarkuar për sistemin e diskut:
Ky lloj ngarkese lidhet me faktin se po përpiqemi të shkruajmë sa më shpejt në ClickHouse. Dhe kjo DB reagon me një ngarkesë të rritur në disk, për shkak të së cilës mund të japë këto gabime:
DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts
ĂĂ«shtja Ă«shtĂ« se nĂ« ClickHouse (ku ruhen tĂ« dhĂ«nat e regjistrimeve) kanĂ« vĂ«shtirĂ«si tĂ« veta gjatĂ« operacioneve tĂ« shkrimit. TĂ« dhĂ«nat qĂ« futen nĂ« to gjenerojnĂ« njĂ« parti tĂ« pĂ«rkohshme, e cila mĂ« pas bashkohet me tabelĂ«n kryesore. Si rezultat, shkrimi bĂ«het shumĂ« kĂ«rkesĂ« pĂ«r disk, si dhe mbi tĂ« zbatohet njĂ« kufizim, njoftimi pĂ«r tĂ« cilin e morĂ«m mĂ« lart: nĂ« 1 sekondĂ« mund tĂ« bashkohen jo mĂ« shumĂ« se 300 nĂ«nparti (faktikisht kjo Ă«shtĂ« 300 insertâĂ« nĂ« sekondĂ«).
Për të shmangur një sjellje të tillë, sa më shumë pjesë të mundshme dhe jo më shpesh se 1 herë në 2 sekonda. Megjithatë, shkrimi në grupe të mëdha nënkupton se duhet të shkruajmë më rrallë në ClickHouse. Kjo, nga ana tjetër, mund të çojë në mbushjen e tamponit dhe humbjen e regjistrimeve. Zgjidhja është të rritet tamponi i Fluentd, por atëherë do të rritet edhe konsumimi i memories.
ShĂ«nim: NjĂ« tjetĂ«r aspekt problematik i zgjidhjes sonĂ« me ClickHouse ishte se partitizimi nĂ« rastin tonĂ« (loghouse) Ă«shtĂ« realizuar pĂ«rmes tabelave tĂ« jashtme tĂ« lidhura Kjo çon nĂ« atĂ« qĂ« kur po merrni njĂ« gamĂ« tĂ« gjerĂ« temporale kĂ«rkohet memorie e tepĂ«rt, pasi tabela e metadhenave kalon tĂ« gjitha partitĂ« â madje ato qĂ« parashikohet qartĂ« se nuk pĂ«rmbajnĂ« tĂ« dhĂ«nat e nevojshme. MegjithatĂ«, tani ky qasje mund tĂ« shpallet me siguri e vjetruar pĂ«r versionet aktuale tĂ« ClickHouse (nga ).
Si përfundim, bëhet e qartë se për mbledhjen e regjistrimeve në kohë reale në ClickHouse burimet e çdo projekti nuk janë mjaft të përshtatshme (në mënyrë më të saktë, shpërndarja e tyre nuk do të ishte e arsyeshme). Për më tepër, do të nevojitet të përdorim akumulimin, të cilin do të rikthehemi. Rasti i përshkruar më sipër është i vërtetë. Dhe në atë kohë ne nuk arritëm të ofronim një zgjidhje të besueshme dhe të qëndrueshme që do të kënaqte klientin dhe do të lejonte mbledhjen e regjistrimeve me vonesë minimale...
Po Elasticsearch?
Dihet se Elasticsearch përballon ngarkesa të mëdha. Le të provojmë atë në të njëjtin projekt. Tani ngarkesa duket si më poshtë:
Elasticsearch arriti të përballojë fluksin e të dhënave, megjithatë shkrimi i këtyre volumesh në të konsumon shumë CPU. Kjo zgjidhet me organizimin e një klustri. Tërësisht teknikisht kjo nuk është një problem, megjithatë do të ndodhte se vetëm për të punuar sistemin e mbledhjes së regjistrimeve ne përdorim rreth 8 bërthama dhe kemi një komponent të ngarkuar të lartë në sistem...
Përfundimi: një alternativë e tillë mund të jetë e justifikueshme, por vetëm nëse projekti është i madh dhe drejtuesit e tij janë të gatshëm të shpenzojnë burime të dukshme për sistemin e centralizuar të regjistrimeve.
Atëherë lind pyetja e arsyeshme:
Cilat regjistrime janë vërtet të nevojshme?
Le të përpiqemi të ndryshojmë vetë qasjen: regjistrimet duhet të jenë njëkohësisht informuese dhe të mos mbulojnë çdo ngjarje në sistem.
Supozoni se kemi një dyqan të suksesshëm online. Cilat regjistrime janë të rëndësishme? Të mbledhësh maksimumin e informacionit, për shembull, nga portali i pagesave - është një ide e shkëlqyer. Ndërsa nga shërbimi i prerjes së imazheve në katalogun e produkteve na nevojiten vetëm disa regjistrime: mjafton vetëm gabime dhe monitorimi i zgjeruar (për shembull, në përqindje të gabimeve 500 që gjeneron ky komponent).
Këtu arritëm në atë që centralizimi i regjistrimeve nuk justifikohet gjithmonë.Shpeshherë, klienti dëshiron të mbledhë të gjitha regjistrimet në një vend, megjithatë në të vërtetë nga e gjithë regjistrimi nevojiten vetëm 5% të mesazheve që janë kritike për biznesin:
- Ndonjëherë është mjaft të konfigurosh, për shembull, vetëm madhësinë e regjistrimit të kontejnerëve dhe mbledhësin e gabimeve (për shembull, Sentry).
- Për hetimin e incidenteve shpesh mjafton njoftimi për gabim dhe vetë një regjistrim lokal të madh.
- Kemi pasur projekte që ishin shpërndarë ekskluzivisht me teste funksionale dhe sisteme mbledhjeje të gabimeve. Ndërsa zhvilluesi nuk kishte nevojë për regjistrime si të tilla - ata i panë të gjitha përmes dhjetëra gabimeve.
Ilustrim nga jeta reale
Një shembull i mirë mund të jetë një histori tjetër. Na erdhi një kërkesë nga ekipi i sigurisë së njërit nga klientët tanë, të cilët kishin implementuar një zgjidhje komerciale që ishte zhvilluar shumë para se të implementohej Kubernetes.
Duhej tĂ« "bashkonim" sistemin e grumbullimit tĂ« centralizuar tĂ« logeve me sensorin korporativ tĂ« zbulimit tĂ« problemeve â QRadar. Ky sistem di tĂ« pranojĂ« loge pĂ«rmes protokollit syslog, tĂ« marrĂ« nga FTP. MegjithatĂ«, integrimi i tij me plugin-in remote_syslog pĂ«r fluentd nuk e arriti rezultatin e dĂ«shiruar menjĂ«herĂ«. (siç u zbulua, ). Problemet me konfigurimin e QRadar ishin nĂ« anĂ«n e ekipit tĂ« sigurisĂ« sĂ« klientit.
Si rezultat, disa loge, tĂ« rĂ«ndĂ«sishme pĂ«r biznesin, u transferuan nĂ« FTP QRadar, dhe disa tĂ« tjera u redirektuara direkt nga nodet pĂ«rmes remote syslog. PĂ«r kĂ«tĂ«, ne madje shkruam â ndoshta ai do tĂ« ndihmojĂ« dikĂ« tĂ« zgjidhĂ« njĂ« problem tĂ« ngjashĂ«m... FalĂ« skemĂ«s qĂ« arritĂ«m, klienti vetĂ« merrte dhe analizonte loget kritike (duke pĂ«rdorur mjetet e tij tĂ« preferuara), ndĂ«rsa ne arritĂ«m tĂ« ulni shpenzimet pĂ«r sistemin e logeve, duke ruajtur vetĂ«m muajin e fundit.
Një shembull tjetër është mjaft ilustrues në atë se si nuk duhet vepruar. Një nga klientët tanë bënte një nxjerrje shumë-rreshtore çdo të strukturuar të informacionit në log. Siç mund ta imagjinoni, këto loge ishin jashtëzakonisht të padobishme për t'u lexuar dhe ruajtur. të informacionit në log. Siç është e lehtë të supozohet, logët e tillë ishin jashtëzakonisht të vështirë për t'u lexuar dhe ruajtur.
Kriteret për loget
Shembuj të tillë na çojnë në përfundimin se përveç zgjedhjes së sistemit të grumbullimit të logeve, duhet të projektohen gjithashtu vetë loget! Cilat janë këtu kërkesat?
- Loget duhet të jenë në format të lexueshëm nga makinat (p.sh., JSON).
- Loget duhet të jenë kompakte dhe të kenë mundësinë të ndryshojnë nivelin e logimit për të diagnostikuar mundësitë për probleme. Në ambientet e prodhimit, duhet të startohen sistemet me një nivel logimi të tillë si Kujdes ose Gabim.
- Loget duhet të jenë të normalizuara, domethënë, në objektin e logut të gjitha fushat e stringjeve duhet të kenë të njëjtin tip.
Loget e pa-struktuara mund tĂ« shkaktojnĂ« probleme me ngarkimin e logeve nĂ« depo dhe tĂ« ndalojnĂ« plotĂ«sisht pĂ«rpunimin e tyre. Si njĂ« ilustĂ«rim â njĂ« shembull me gabimin 400, me tĂ« cilin shumĂ« kanĂ« pĂ«rballur nĂ« loget e fluentd:
2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"
Gabimi tregon se po dĂ«rgoni nĂ« indeks njĂ« fushĂ« me mapping tĂ« gatshĂ«m, tipi i sĂ« cilĂ«s Ă«shtĂ« i paqĂ«ndrueshĂ«m. NjĂ« shembull i thjeshtĂ« â fusha nĂ« logun nginx me variablin $upstream_status. Ajo mund tĂ« jetĂ« si numĂ«r, ashtu edhe string. PĂ«r shembull:
{ "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"}
Në loge mund të shihet se serveri 10.100.0.10 u përgjigj me gabimin 404 dhe kërkesa u dërgua në një depo të tjera përmbajtjeje. Si rezultat, në loge vlera u bë kështu:
"upstream_response_time": "0.001, 0.007"
Kjo situatë është aq e zakonshme, saqë meritoi madje një përmendje të veçantë në dokumentacion .
Ka raste kur të gjitha loget pa përjashtim janë jetike. Dhe këtu, skemat standarde të grumbullimit të logeve për K8s, të propozuara/diskutuar më lart, kanë probleme.
PĂ«r shembull, fluentd nuk mund tĂ« grumbullojĂ« loge nga kontenierĂ«t e shkurtĂ« tĂ« jetĂ«s. NĂ« njĂ«rin nga projektet tona, kontejneri me migrimin e bazĂ«s sĂ« tĂ« dhĂ«nave jetoi mĂ« pak se 4 sekonda dhe mĂ« pas u fshi â sipas annotacionit pĂ«rkatĂ«s:
"helm.sh/hook-delete-policy": hook-succeeded
Si rezultat, logu i ekzekutimit të migrimit nuk arriti në depo. Një politikë që mund të ndihmojë në këtë rast është
Për këtë arsye, logu i ekzekutimit të migrimit nuk shkonte në depo. Një politikë e tillë si before-hook-creation.
NjĂ« shembull tjetĂ«r â rotacioni i logeve tĂ« Docker-it. Supozoni se ka njĂ« aplikacion qĂ« shkruan aktivisht nĂ« loge. NĂ« kushte normale, ne arrijmĂ« tĂ« pĂ«rpunojmĂ« tĂ« gjitha loget, por sapo shfaqet njĂ« problem â siç u pĂ«rmend mĂ« sipĂ«r me formatin e gabuar â pĂ«rpunimi ndalet, dhe Docker rrotullon skedarin. Si rezultat, mund tĂ« humbasim loget kritike pĂ«r biznesin.
Prandaj është e rëndësishme të ndahen rrjedhat e logeve, duke integruar dërgimin e më të vlefsishmëve direkt në aplikacion, për të siguruar ruajtjen e tyre. Për më tepër, nuk do të ishte keq të krijonim një lloj "akumulatori" të logeve, që mund të përballojë një mungesë të shkurtër të depozitës duke ruajtur mesazhet kritike.
Në fund, nuk duhet harruar se çdo nën-sistem është e rëndësishme të monitorohet cilësisht. Ndryshe, lehtësisht mund të përballesh me një situatë, ku fluentd është në gjendje CrashLoopBackOff dhe nuk dërgon asgjë, dhe kjo do të çojë në humbjen e informacionit të rëndësishëm.
PĂ«rfundimet
Në këtë artikull ne nuk e shqyrtojmë zgjidhjet SaaS si Datadog. Shumë nga problemet e përmendura këtu tashmë janë zgjidhur nga kompani komerciale që specializohen në grumbullimin e logeve, por jo të gjithë mund të përdorin SaaS për arsye të ndryshme (arsyet kryesore janë kostoja dhe përputhja me 152-FZ).
Grumbullimi i centralizuar i logeve fillon si njĂ« detyrĂ« e thjeshtĂ«, por nuk Ă«shtĂ« aspak kĂ«shtu. ĂshtĂ« e rĂ«ndĂ«sishme tĂ« mbani mend se:
- Duhet të regjistroni në detaje vetëm komponentët kritikë, ndërsa për sistemet e tjera mund të konfiguroni monitorimin dhe grumbullimin e gabimeve.
- Loget në production duhet të jenë minimale, për të mos krijuar ngarkesë të tepërt.
- Loget duhet të jenë të lexueshme nga machine, të normalizuara, dhe të kenë një format të rreptë.
- Loget që janë me të vërtetë kritike duhet të dërgohen përmes një kanali të veçantë, i cili duhet të jetë i ndarë nga ato kryesore.
- Duhet të mendoni për një akumulator logesh, i cili mund të shpëtojë nga shpërthime të ngarkesës së lartë dhe ta bëjë ngarkesën në ruajtje më të rregullt.
KĂ«to rregulla tĂ« thjeshta, nĂ«se aplikohen kudo, do tĂ« lejonin qĂ« tĂ« funksiononin dhe skemat e pĂ«rmendura mĂ« lart â edhe pse atyre u mungojnĂ« komponente tĂ« rĂ«ndĂ«sishme (akumlatori). NĂ«se nuk ndiheni pas kĂ«tyre principeve, detyra do t'ju çojĂ« dhe ju dhe infrastrukturĂ«n nĂ« njĂ« komponent tjetĂ«r me ngarkesĂ« tĂ« lartĂ« (dhe njĂ«kohĂ«sisht tĂ« pakufizuar) tĂ« sistemit.
P.S.
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «».
Burimi: habr.com
