Përshëndetje të gjithëve, unë quhem Aleksandër, punoj në CIAN si inxhinier dhe merrem me administrimin e sistemeve dhe automatizimin e proceseve infrastrukturore. Në komentet e njërit prej artikujve të kaluar, na u kërkua të flasim mbi burimin prej 4 TB log-eve në ditë dhe çfarë bëjmë me to. Po, kemi shumë log-e dhe për procesimin e tyre është krijuar një grup infrastrukture i veçantë që na lejon të zgjidhim problemet në mënyrë operative. Në këtë artikull, do të flas për mënyrën se si e kemi adaptuar atë gjatë një viti për të punuar me fluksin në rritje të të dhënave.
Si e nisëm
Gjatë disa viteve të fundit, ngarkesa në cian.ru u rrit shumë shpejt, dhe në tremujorin e tretë të vitit 2018, vizitat në burim arritën 11.2 milion përdorues unikë në muaj. Në ato momente kritike, ne humbnim deri në 40% të log-eve, duke e bërë të pamundur të merreshim me incidentet në kohë dhe duke shpenzuar shumë kohë dhe energji për t'i zgjidhur ato. Po ashtu, shpesh nuk mund të gjenim shkakun e problemit dhe ai ripërsëritej pas një kohë. Kjo ishte një ferr prej të cilit na duhej të bënim diçka.
NĂ« atĂ« kohĂ«, pĂ«r ruajtjen e log-eve pĂ«rdornim njĂ« grup prej 10 nodave tĂ« dhĂ«nash me ElasticSearch version 5.5.2 me konfigurime standarde tĂ« indekseve. E implementuam atĂ« mĂ« shumĂ« se njĂ« vit mĂ« parĂ« si njĂ« zgjidhje tĂ« njohur dhe tĂ« pĂ«rballueshme: atĂ«herĂ« fluksi i log-eve nuk ishte aq i madh, prandaj nuk kishte kuptim tĂ« krijonim konfigurime jo standarde.Â
PĂ«r procesimin e log-eve tĂ« ardhura, Logstash funksiononte nĂ« ports tĂ« ndryshme nĂ« pesĂ« koordinatorĂ« ElasticSearch. NjĂ« indeks, pavarĂ«sisht nga madhĂ«sia, ishte pĂ«rbĂ«rĂ« nga pesĂ« shard. Kemi organizuar rotacionin çdo orĂ« dhe ditor, kĂ«shtu qĂ« çdo orĂ« nĂ« grupin tonĂ« shfaqeshin rreth 100 shard tĂ« rinj. NdĂ«rsa log-eve nuk ishin shumĂ«, grupi pĂ«rballonte situatĂ«n dhe askush nuk e vuri re konfigurimin e tij.Â
Problemet e rritjes së shpejtë
VĂ«llimi i log-eve tĂ« gjeneruara po rritej shumĂ« shpejt, pasi dy procese sigurisht po ndĂ«rfuten. Nga njĂ«ra anĂ«, numri i pĂ«rdoruesve tĂ« shĂ«rbimit po rritej gjithnjĂ« e mĂ« shumĂ«. Nga ana tjetĂ«r, filluam tĂ« kalojmĂ« aktivisht nĂ« njĂ« arkitekturĂ« mikroshĂ«rbimesh duke ndarĂ« monolitĂ«t tanĂ« tĂ« vjetĂ«r nĂ« C# dhe Python. Disa dhjetĂ«ra mikroshĂ«rbime tĂ« reja, qĂ« zĂ«vendĂ«suan pjesĂ« tĂ« monolitit, gjeneronin ndjeshĂ«m mĂ« shumĂ« log-e pĂ«r grupin infrastrukturore.Â
SaktĂ«sisht shkallĂ«zimi na çoi nĂ« njĂ« situatĂ« ku klasteri u bĂ« praktikisht i pakontrolueshĂ«m. Kur logat filluan tĂ« vijnĂ« me shpejtĂ«si prej 20 mijĂ« mesazhesh nĂ« sekundĂ«, rotacioni i shpeshtĂ« i padobishĂ«m e rriti numrin e shardĂ«ve nĂ« 6 mijĂ«, ndĂ«rsa njĂ« nyje kishte mĂ« shumĂ« se 600 shardĂ«.Â
Kjo çonte në probleme me ndarjen e memories, ndërsa kur një nyje binte, ndodhte një transferim i menjëhershëm i të gjithë shardëve, duke shumëzuar trafikun dhe ngarkuar nyjet e tjera, gjë që e bënte thuajse të pamundur regjistrimin e të dhënave në klaster. Gjatë kësaj periudhe, ne ishim pa loga. Dhe kur kishte problem me server ne humbisnim 1/10 të klasterit në thelb. Numri i madh i indekseve të vogla e shtonte kompleksitetin.
Pa loga, nuk kuptonim arsyet e incidentit dhe mund tĂ« pĂ«rballeshim herĂ«t ose vonĂ« me tĂ« njĂ«jtat probleme pĂ«rsĂ«ri, dhe kjo nĂ« ideologjinĂ« tonĂ« ekipore ishte e papranueshme, pasi tĂ« gjithĂ« mekanizmat tanĂ« tĂ« punĂ«s ishin tĂ« dizajnuar pĂ«r tĂ« mos i pĂ«rsĂ«ritur ndonjĂ«herĂ« tĂ« njĂ«jtat probleme. PĂ«r kĂ«tĂ« na duhej njĂ« vĂ«llim i plotĂ« logash dhe dĂ«rgimi i tyre praktika nĂ« kohĂ« reale, pasi ekipi i inxhinierĂ«ve vigilent monitoronte alarmin jo vetĂ«m nga metrikat, por edhe nga logat. PĂ«r tĂ« kuptuar shkallĂ«n e problemit - nĂ« atĂ« kohĂ«, vĂ«llimi total i logĂ«ve ishte rreth 2 TB nĂ« ditĂ«.Â
Ne vendosëm një detyrë - të eliminojmë plotësisht humbjen e logëve dhe të shkurtomë kohën e dërgimit në klasterin ELK maks 15 minuta gjatë rasteve urgjente (në këtë shifër më vonë mbështeteshim si KPI të brendshëm).
Mekanizmi i ri i rotacionit dhe nyjet hot-warm
Ne filluam transformimin e klasterit me përditësimin e versionit ElasticSearch nga 5.5.2 në 6.4.3. Klasteri ynë i versionit 5 përsëri ra, dhe vendosëm ta fikim dhe ta përditësojmë plotësisht - nuk kishte loga. Pra, këtë kalim e bëmë për vetëm disa orë.
Transformimi mĂ« i madh nĂ« kĂ«tĂ« fazĂ« ishte implementimi nĂ« tri nodet me njĂ« koordinĐ°ŃĐŸŃ si njĂ« tampon ndĂ«rmjetĂ«s Apache Kafka. Brokeri i mesazheve na çliroi nga humbja e logĂ«ve gjatĂ« problemeve me ElasticSearch. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, ne shtuam 2 node nĂ« kluster dhe kaluam nĂ« arkitekturĂ«n hot-warm me tri nodet "tĂ« nxehta", tĂ« vendosura nĂ« shtylla tĂ« ndryshme nĂ« qendĂ«r tĂ« tĂ« dhĂ«nave. Atje ne redirektuam logĂ«t qĂ« nuk duhet tĂ« humben kurrĂ« â nginx, si dhe logĂ«t e gabimeve tĂ« aplikacioneve. Tek nodet e tjera shkonin logĂ«t e dorĂ«s sĂ« dytĂ« â debug, warning, etj., dhe pas 24 orĂ«ve, logĂ«t "e rĂ«ndĂ«sishme" nga nodet "tĂ« nxehta" kalonin.
PĂ«r tĂ« mos rritur numrin e indekseve tĂ« vogla, ne kaluam nga rotacioni sipas kohĂ«s nĂ« mekanizmin e rollover. NĂ« forume kishte shumĂ« informacione se rotacioni sipas madhĂ«sisĂ« sĂ« indeksit ishte shumĂ« i pabesueshĂ«m, prandaj vendosĂ«m tĂ« pĂ«rdorim rotacionin sipas numrit tĂ« dokumenteve nĂ« indeks. Ne analizuam çdo indeks dhe regjistruam numrin e dokumenteve, pas tĂ« cilit duhej tĂ« aktivizohej rotacioni. KĂ«shtu arritĂ«m madhĂ«sinĂ« optimale tĂ« shard-it â jo mĂ« shumĂ« se 50 GB.Â
Optimizimi i klasterit
MegjithatĂ«, ne nuk u çlirĂ«m plotĂ«sisht nga problemet. FatkeqĂ«sisht, ndiheshin ende indekse tĂ« vogla: ato nuk arrinin volumet e caktuara, nuk rotacionoheshin dhe hiqeshin me pastrimin global tĂ« indekseve mĂ« tĂ« vjetra se tri ditĂ«, pasi ne e hoqĂ«m rotacionin sipas datĂ«s. Kjo çoi nĂ« humbje tĂ« tĂ« dhĂ«nave pĂ«r shkak se indeksi zhdukej plotĂ«sisht nga klasteri, ndĂ«rsa pĂ«rpjekjet pĂ«r tĂ« shkruar nĂ« njĂ« indeks qĂ« nuk ekzistonte prishnin logjikĂ«n e curator-it, qĂ« ne pĂ«rdornim pĂ«r menaxhim. Alias-i pĂ«r shkruarje transformohej nĂ« indeks dhe prishte logjikĂ«n e rollover-it, duke shkaktuar rritjen e pakontrolluar tĂ« disa indekseve deri nĂ« 600 GB.Â
Për shembull, për konfigurimin e rotacionit:
curator-elk-rollover.yaml
---
actions:
1:
action: rollover
options:
name: "nginx_write"
conditions:
max_docs: 100000000
2:
action: rollover
options:
name: "python_error_write"
conditions:
max_docs: 10000000
Në mungesë të rollover alias, ndodhte një gabim:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. : Unable to perform index rollover with alias "nginx_write".
Zgjidhjen e këtij problemi e lanë për iteracionin e ardhshëm dhe u morëm me një çështje tjetër: kaluam në logjikën pull të punës së Logstash-it, i cili merret me procesimin e logëve hyrëse (ndalimin e informacionit të tepërt dhe pasurimin e tij). E vendosëm atë në docker, të cilin e ekzekutojmë përmes docker-compose, atje po ashtu vendosëm logstash-exporter, i cili jep metrika në Prometheus për monitorimin operacional të fluksit të logëve. Kështu e dhamë vetës mundësinë të ndryshojmë gradualisht numrin e instancave të logstash-it, që ishin përgjegjës për procesimin e çdo lloji logu.
NdĂ«rkohĂ« qĂ« po pĂ«rmirsonim klasterin, vizitueshmĂ«ria e cian.ru u rrit nĂ« 12.8 milion pĂ«rdorues unikĂ« nĂ« muaj. Si rezultat, ndodhi qĂ« transformimet tona paksa nuk arritĂ«n pas ndryshimeve nĂ« prodhim, dhe u pĂ«rballĂ«m me faktin se nodet "tĂ« ngrohta" nuk e pĂ«rballonin ngarkesĂ«n dhe ngadalĂ«suan tĂ« gjithĂ« shpĂ«rndarjen e logĂ«ve. TĂ« dhĂ«nat "tĂ« nxehta" i merrnim pa ndĂ«rprerje, por pĂ«r shpĂ«rndarjen e tĂ« tjerave duhej tĂ« intervenonim dhe tĂ« bĂ«nim rollover manual pĂ«r tĂ« shpĂ«rndarĂ« nĂ« mĂ«nyrĂ« tĂ« barabartĂ« indekset.Â
Megjithatë, shkallëzimi dhe ndryshimi i konfigurimeve të instancave të logstash-it në klaster u komplikuar nga fakti se ishte një docker-compose lokal, dhe të gjitha veprimet kryheshin manualisht (për të shtuar skajet e reja kishte nevojë të kalonim manualisht në të gjitha serverat dhe të bënim docker-compose up -d kudo).
Rredistribuimi i logëve
NĂ« shtator tĂ« kĂ«tij vitit, ne ende po vazhdonim tĂ« shpĂ«rbĂ«nim monolit, ngarkesa nĂ« klaster po rritej, dhe fluksi i logĂ«ve po arriti nĂ« gati 30 mijĂ« mesazhe nĂ« sekondĂ«.Â
Iteracionin e ardhshĂ«m e filluam me pĂ«rmirĂ«simin e harduerit. Nga pesĂ« koordinatorĂ« kaluam nĂ« tre, zĂ«vendĂ«suam nodet e dhĂ«nave dhe fituam nĂ« kosto dhe kapacitet ruajtjeje. PĂ«r nodet pĂ«rdorim dy konfiguracione:Â
- Për nodet "të nxehta": E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 për Hot1 dhe 3 për Hot2).
- Për nodet "të ngrohta": E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
NĂ« kĂ«tĂ« iteracion, ne nxorrĂ«m indeksin me logĂ«t e aksesit tĂ« mikroshĂ«rbjeve, i cili zĂ« po aq hapĂ«sirĂ« sa logĂ«t e nginx-it tĂ« pĂ«rparshĂ«m, nĂ« grupin e dytĂ« nga tre nodet "tĂ« nxehta". TĂ« dhĂ«nat nĂ« nodet "tĂ« nxehta" tani i ruajmĂ« pĂ«r 20 orĂ«, dhe mĂ« pas i transferojmĂ« nĂ« "tĂ« ngrohta" me logĂ«t e tjera.Â
Ne zgjidhĂ«m problemin e zhdukjes sĂ« indekseve tĂ« vogla duke rikonfiguruar rotacionin e tyre. Tani indekset rotacionohen çdo 23 orĂ«, pavarĂ«sisht se sa tĂ« dhĂ«na ka. Kjo çoi nĂ« njĂ« rritje tĂ« numrit tĂ« shardĂ«ve (arritĂ«m rreth 800), por nga kĂ«ndi i performancĂ«s sĂ« klasterit, kjo Ă«shtĂ« e pĂ«rballueshme.Â
Si rezultat, në klaster kemi gjashtë nodet 'të nxehta' dhe vetëm katër 'të ngrohta'. Kjo shkakton një vonesë të vogël në kërkesat për periudha të gjata, por rritja e numrit të nodëve në të ardhmen do ta zgjidhë këtë problem.
NĂ« kĂ«tĂ« iteracion, ne e patĂ«m edhe problemin e mungesĂ«s sĂ« shkallĂ«zimit gjysmĂ«automatik. PĂ«r kĂ«tĂ«, ne kemi vendosur njĂ« klaster infrastrukture Nomad â i ngjashĂ«m me atĂ« qĂ« tashmĂ« kemi nĂ« prodhim. Deri tani, numri i Logstash nuk ndryshon automatikisht nĂ« varĂ«si tĂ« ngarkesĂ«s, por ne do tĂ« arrijmĂ« atje.
Planet për të ardhmen
Konfigurimi i realizuar bĂ«het shkallĂ«zues shumĂ« mirĂ«, dhe tani ruajmĂ« 13.3 TB tĂ« dhĂ«nash â tĂ« gjithĂ« loget pĂ«r 4 ditĂ«, qĂ« Ă«shtĂ« e nevojshme pĂ«r analizat emergjente tĂ« alerteve. PjesĂ«n e logĂ«ve e transformojmĂ« nĂ« metrikĂ«, tĂ« cilat i mbledhim nĂ« Graphite. PĂ«r tĂ« lehtĂ«suar punĂ«n e inxhinierĂ«ve, kemi metrikĂ« pĂ«r klasterin e infrastrukturĂ«s dhe skripte pĂ«r riparimin gjysmĂ«automat tĂ« problemeve tipike. Pas rritjes sĂ« numrit tĂ« nodĂ«ve tĂ« dhĂ«nash qĂ« Ă«shtĂ« planifikuar pĂ«r vitin e ardhshĂ«m, do tĂ« kalojmĂ« nga ruajtja e tĂ« dhĂ«nave pĂ«r 4 nĂ« 7 ditĂ«. Kjo do tĂ« jetĂ« e mjaftueshme pĂ«r tĂ« punuar nĂ« mĂ«nyrĂ« efikase, pasi gjithmonĂ« pĂ«rpiqemi tĂ« hetojmĂ« incidentet sa mĂ« shpejt tĂ« jetĂ« e mundur, dhe pĂ«r hetimet afatgjata, kemi tĂ« dhĂ«na telemetri.Â
NĂ« tetor 2019, vizitueshmĂ«ria e cian.ru u rrit nĂ« 15.3 milion pĂ«rdorues unikĂ« nĂ« muaj. Kjo ishte njĂ« provĂ« serioze pĂ«r zgjidhjen arkitektonike tĂ« dorĂ«zimit tĂ« logĂ«ve.Â
Aktualisht po pĂ«rgatitemi tĂ« pĂ«rditĂ«sojmĂ« ElasticSearch nĂ« versionin 7. MegjithatĂ«, pĂ«r kĂ«tĂ« do tĂ« duhet tĂ« pĂ«rditĂ«sojmĂ« mapping-un e shumĂ« indekseve nĂ« ElasticSearch, pasi ato kaluan nga versioni 5.5 dhe u shpallĂ«n si tĂ« vjetruara nĂ« versionin 6 (nĂ« versionin 7 thjesht nuk ekzistojnĂ«). Kjo do tĂ« thotĂ« se gjatĂ« procesit tĂ« pĂ«rditĂ«simit do tĂ« ketĂ« ndonjĂ« ngjarje tĂ« papritur, e cila pĂ«r njĂ« kohĂ« do tĂ« na lĂ«rĂ« pa log. Nga versioni 7, presim mĂ« shumĂ« Kibana me njĂ« ndĂ«rfaqe tĂ« pĂ«rmirĂ«suar dhe filtra tĂ« rinj.Â
Ne arritëm qëllimin tonë kryesor: ndaluam humbjen e logjeve dhe reduktuam kohën e ndërprerjes së infrastrukturës nga 2-3 rënie në javë në disa orë punë të shërbimit në muaj. I gjithë ky punë në prodhim është pothuajse e padukshme. Megjithatë, tani mund të përcaktojmë saktësisht se çfarë po ndodh me shërbimin tonë, mund ta bëjmë këtë shpejt në një mënyrë të qetë dhe të mos shqetësohemi për humbjen e logjeve. Në përgjithësi, jemi të kënaqur, të lumtur dhe po përgatisim për sfida të reja, të cilat do t'ju tregojmë më vonë.
Burimi: habr.com
