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 për një nga artikujt e kaluar, na u kërkua të tregojmë se nga vijmë 4 TB log-e në ditë dhe çfarë bëjmë me to. Po, kemi shumë log-e, dhe për përpunimin e tyre kemi krijuar një klaster infrastrukture të veçantë që na lejon të zgjidhim shpejt probleme. Në këtë artikull do të flas për mënyrën se si e kemi adaptuar atë për një vit për të punuar me rrjedhën në rritje të të dhënave.
Nga kemi filluar
Gjatë disa viteve të fundit, ngarkesa në cian.ru është rritur shumë shpejt, dhe deri në tremujorin e tretë të vitit 2018, vizitueshmëria e burimit arriti në 11.2 milion përdorues unikë në muaj. Në atë kohë, në momente kritike humbisnim deri në 40% të log-eve, duke na penguar të menaxhonim shpejt incidentet dhe duke shpenzuar shumë kohë dhe energji për t'i zgjidhur ato. Gjithashtu, shpesh nuk mund të gjenim shkakun e problemit, dhe ai përsëritej pas një kohe. Kjo ishte një situatë e vështirë që duhej të zgjidhnim.
NĂ« atĂ« kohĂ«, pĂ«r ruajtjen e log-eve pĂ«rdornim njĂ« klaster prej 10 nodash tĂ« dhĂ«nash me ElasticSearch version 5.5.2 me parametra standard 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, dhe nuk kishte kuptim tĂ« shpiknim konfiguracione jo standarde.Â
PĂ«rpunimin e log-eve tĂ« ardhshme e siguronim me Logstash nĂ« porte tĂ« ndryshme nĂ« pesĂ« koordinatorĂ« tĂ« ElasticSearch. NjĂ« indeks, pavarĂ«sisht nga madhĂ«sia, pĂ«rbĂ«hej prej pesĂ« shardesh. U organizua rotacioni çdo orĂ« dhe çdo ditĂ«, si rezultat çdo orĂ« nĂ« klaster ndodhnin rreth 100 sharde tĂ« reja. NdĂ«rsa log-eve nuk ishin aq shumĂ«, klasteri pĂ«rballonte dhe askush nuk kishte vĂ«nĂ« re parametrat e tij.Â
Problemet nga rritja e shpejtë
Volumi i log-eve tĂ« gjeneruara rritej shumĂ« shpejt, sepse dy procese pĂ«rplasnin njĂ«ri-tjetrin. Nga njĂ«ra anĂ«, numri i pĂ«rdoruesve tĂ« shĂ«rbimit po rritej. Nga ana tjetĂ«r, ne 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 klasterin infrastruktural.Â
PikĂ«risht shkallĂ«zimi na çoi nĂ« njĂ« situatĂ« ku klasteri u bĂ« praktikisht i pakontrolluar. Kur log-et filluan tĂ« vinin me shpejtĂ«si 20,000 mesazhe nĂ« sekondĂ«, rotacionet e shpeshta tĂ« padobishme rritĂ«n numrin e shardeve nĂ« 6,000, ndĂ«rsa pĂ«r çdo nod kishte mĂ« shumĂ« se 600 sharde.Â
Kjo e çonte në probleme me ndarjen e memorie operativ dhe në momentin e rënies së një nodi fillonte një kalim i menjëhershëm i të gjithë shardeve, duke shumëfishuar trafikun dhe ngarkuar nodet e tjera, gjë që e bënte praktikisht të pamundur regjistrimin e të dhënave në klaster. Dhe në atë periudhë mbetëm pa log-e. Në rastin e një problemi me serverin humbnim 1/10 e klasterit në përgjithësi. Një numër i madh indekseve të vogla shtonte vështirësi.
Pa log-e nuk kuptonim arsyet e incidentit dhe mund tĂ« pĂ«rballeshim pĂ«rsĂ«ri me tĂ« njĂ«jtĂ«n problematikĂ«, ndonĂ«se ne nĂ« ideologjinĂ« tonĂ« nuk pranojmĂ« qĂ« ndodhin tĂ« njĂ«jtat probleme. Prandaj na duhej volume tĂ« plotĂ« log-esh dhe dorĂ«zimi i tyre pothuajse nĂ« kohĂ« reale, pasi ekipi i inxhinierĂ«ve pĂ«rgjonte sinjalizimet jo vetĂ«m nga metrikat, por edhe nga log-Ă«t. PĂ«r tĂ« kuptuar sasinĂ« e problemit â nĂ« atĂ« kohĂ« volumi total i log-eve arrinte rreth 2 TB nĂ« ditĂ«.Â
Ne vendosĂ«m njĂ« qĂ«llim â tĂ« eliminojmĂ« plotĂ«sisht humbjen e log-eve dhe tĂ« shkurtuam kohĂ«n e dorĂ«zimit tĂ« tyre nĂ« klasterin ELK deri nĂ« maksimum 15 minuta gjatĂ« forcon e jashtĂ«zakonshme (kjo ishte numri nĂ« tĂ« cilin ne u mbĂ«shtetĂ«m si KPI tĂ« brendshĂ«m mĂ« vonĂ«).
Mekanizmi i ri i rotacionit dhe nodet hot-warm
Transformimi i klasterit e filluam me pĂ«rditĂ«simin e versionit tĂ« ElasticSearch nga 5.5.2 nĂ« 6.4.3. Klasteri ynĂ« i versionit 5 ra pĂ«rsĂ«ri, dhe ne vendosĂ«m ta fiknim dhe ta azhurnonim plotĂ«sisht â gjithsesi nuk kishim log-e. Pra, kĂ«tĂ« kalim e realizuam brenda disa orĂ«ve.
Transformimi mĂ« i madh nĂ« kĂ«tĂ« fazĂ« ishte implementimi nĂ« tre nodet me njĂ« koordinatator si njĂ« tampon tĂ« pĂ«rkohshĂ«m Apache Kafka. Brokeri i mesazheve na shpĂ«toi nga humbja e log-eve gjatĂ« problemeve me ElasticSearch. NĂ« tĂ« njĂ«jtĂ«n kohĂ«, ne shtuam 2 nodĂ« nĂ« klaster dhe kaluam nĂ« arkitekturĂ«n hot-warm me tre nodĂ« "tĂ« nxehta", tĂ« vendosura nĂ« rafte tĂ« ndryshme nĂ« qendrat e tĂ« dhĂ«nave. NĂ« to dirigjuam log-et qĂ« nuk mund tĂ« humbasim nĂ«n asnjĂ« rrethanĂ« â nginx, si dhe log-et e gabimeve tĂ« aplikacioneve. NĂ« nodet e tjera kalonin logĂ«t minorĂ« â debug, warning, etj., ndĂ«rsa pas 24 orĂ«sh kalonin "logĂ«t e rĂ«ndĂ«sishĂ«m" nga nodet "e nxehta".
PĂ«r tĂ« shmangur rritjen e numrit tĂ« indekseve tĂ« vegjĂ«l, ne kaluam nga rotacioni nĂ« kohĂ« nĂ« mekanizmin rollover. NĂ« forume kishte shumĂ« informacion qĂ« rotacioni sipas madhĂ«sisĂ« sĂ« indeksit ishte shumĂ« i pasigurt, prandaj ne vendosĂ«m tĂ« pĂ«rdorim rotacionin sipas numrit tĂ« dokumenteve nĂ« indeks. Anlizuam çdo indeks dhe regjistruam numrin e dokumenteve, pas tĂ« cilit duhet tĂ« aktivizohej rotacioni. NĂ« kĂ«tĂ« mĂ«nyrĂ« arritĂ«m njĂ« madhĂ«si optimale sharde â jo mĂ« shumĂ« se 50 GB.Â
Optimizimi i klasterit
MegjithatĂ«, ne nuk u shpĂ«tuam plotĂ«sisht problemeve. FatkeqĂ«sisht, akoma shfaqeshin indekse tĂ« vogla: ato nuk arrinin volumin e caktuar, nuk rotatoeshin dhe hiqeshin me pastrimin global tĂ« indekseve mbi tre ditĂ«, sepse ne hoqĂ«m rotacionin sipas datĂ«s. Kjo çonte nĂ« humbje tĂ« tĂ« dhĂ«nave, pasi indeksi nga klasteri zhdukej plotĂ«sisht, dhe tentimi pĂ«r tĂ« shkruar nĂ« njĂ« indeks qĂ« nuk ekzistonte prishte logjikĂ«n e curator-it, tĂ« cilin e pĂ«rdornim pĂ«r menaxhim. Alias pĂ«r tĂ« shkruar shndĂ«rrohej nĂ« indeks dhe prishte logjikĂ«n e rollover-it, duke shkaktuar njĂ« rritje tĂ« 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, shfaqej një gabim:
ERROR Â Â alias "nginx_write" not found.
ERROR   Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Zgjidhjen e kësaj probleme e lamë për iteratën e ardhshme dhe u angazhuam me një çështje tjetër: kaluam në logjikën pull të funksionimit të Logstash, që merret me përpunimin e logeve të ardhshme (heqja e informacionit të tepërt dhe pasurimi). E vendosëm atë në docker, të cilin e aktivizojmë përmes docker-compose, po aty e vendosëm logstash-exporter, i cili jep metrika në Prometheus për monitorimin operativ të fluksit të logeve. Kështu i dhamë vetes mundësinë të ndryshonim me lehtësi numrin e instancave të logstash që ishin përgjegjëse për përpunimin e çdo lloji logu.
NdĂ«rkohĂ« qĂ« po pĂ«rmirĂ«sonim klasterin, vizita nĂ« cian.ru u rrit nĂ« 12,8 milion pĂ«rdorues unikĂ« nĂ« muaj. Si rezultat, transformimet tona paksa nuk po pĂ«rputheshin me ndryshimet nĂ« prodhim, dhe pĂ«rballeshim me faktin qĂ« nodet "tĂ« ngrohta" nuk po pĂ«rballonin ngarkesĂ«n dhe ngadalĂ«sonin tĂ« gjithĂ« dĂ«rgimin e logeve. TĂ« dhĂ«nat "tĂ« nxehta" i merrnim pa u prishur, por pĂ«r dĂ«rgimin e tĂ« tjerave duhej tĂ« ndĂ«rhyhej dhe tĂ« bĂ«hej rollover manual, pĂ«r tĂ« shpĂ«rndarĂ« nĂ« mĂ«nyrĂ« tĂ« barabartĂ« indekset.Â
Në të njëjtën kohë, shkallëzimi dhe ndryshimi i cilësimeve të instancave të logstash në klaster u vështirësuan nga fakti se kjo ishte një docker-compose vendor, dhe të gjitha veprimet kryheshin me duar (për të shtuar përfundimet e reja duhej të kalonim me duar në të gjitha serverët dhe të bënim docker-compose up -d kudo).
Rredistribuimi i logeve
NĂ« shtator tĂ« kĂ«tij viti, ne ende vazhdojmĂ« tĂ« ndajmĂ« monolit, ngarkesa nĂ« klaster po rritej, dhe fluksi i logeve po afrohej nĂ« 30 mijĂ« mesazhe nĂ« sekondĂ«.Â
IteratĂ«n e ardhshme e filluam me pĂ«rditĂ«simin e harduerit. Nga pesĂ« koordinatorĂ« kaluam nĂ« tre, zĂ«vendĂ«suam nodet e tĂ« dhĂ«nave dhe fituam si nĂ« para ashtu edhe nĂ« kapacitetin e ruajtjes. 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Ă« iteratĂ« ne e nxorrĂ«m indeksin me loget e qasjes sĂ« mikroshĂ«rbimeve, i cili zĂ« tĂ« njĂ«jtin volum si loget e nginx-it tĂ« frontit, nĂ« grupin e dytĂ« prej tre nodĂ«sh "tĂ« nxehta". TĂ« dhĂ«nat nĂ« nodet "tĂ« nxehta" tani i ruajmĂ« pĂ«r 20 orĂ«, dhe pastaj i kalojmĂ« te "tĂ« ngrohtat" pĂ«r loget e tjera.Â
Problemin e zhdukjes sĂ« indekseve tĂ« vogla e zgjidhĂ«m duke rregulluar rotacionin e tyre. Tani indekset rotatohen nĂ« çdo rast çdo 23 orĂ«, edhe nĂ«se atje ka pak tĂ« dhĂ«na. Kjo pak rriti numrin e shardeve (tani janĂ« rreth 800), por nga kĂ«ndvĂ«shtrimi i performancĂ«s sĂ« klasterit, Ă«shtĂ« tolerueshme.Â
Si rezultat, klasteri përfundoi me gjashtë nodet "të nxehta" dhe vetëm katër "të ngrohta". Kjo shkakton një vonesë të vogël në kërkesat për intervale të mëdha kohore, por rritja e numrit të nodëve në të ardhmen do t'i zgjidhë këtë problem.
NĂ« kĂ«tĂ« iteratĂ« e corrigjim edhe problemin e mungesĂ«s sĂ« shkallĂ«zimit gjysmĂ« automatiku. PĂ«r kĂ«tĂ«, ne zhvilluam njĂ« klasĂ«r infrastrukturore Nomad â tĂ« ngjashĂ«m me atĂ« qĂ« tashmĂ« Ă«shtĂ« zhvilluar tek ne nĂ« prodhim. NdĂ«rkohĂ«, numri i Logstash nuk ndryshon automatikisht nĂ« varĂ«si tĂ« ngarkesĂ«s, por do t'ia arrijmĂ« edhe kĂ«tij.
Planet për të ardhmen
Konfigurimi i realizuar shkallĂ«zohet shkĂ«lqyer, dhe tani ne ruajmĂ« 13.3 TB tĂ« dhĂ«nash - tĂ« gjitha loget pĂ«r 4 ditĂ«t e kaluara, qĂ« janĂ« tĂ« domosdoshme pĂ«r analizimin urgjent tĂ« alarmeve. NjĂ« pjesĂ« e logeve i transformojmĂ« nĂ« metrika, tĂ« cilat i grumbullojmĂ« nĂ« Graphite. PĂ«r tĂ« lehtĂ«suar punĂ«n e inxhinierĂ«ve, kemi metrika pĂ«r klasterin infra-strukturor dhe skripte pĂ«r riparimin gjysmĂ«-automatik tĂ« problemeve tipike. Pasi tĂ« rritet numri i nodĂ«ve tĂ« tĂ« dhĂ«nave, qĂ« Ă«shtĂ« planifikuar pĂ«r vitin e ardhshĂ«m, ne do tĂ« kalojmĂ« nĂ« ruajtjen e tĂ« dhĂ«nave nga 4 nĂ« 7 ditĂ«. Kjo do tĂ« jetĂ« e mjaftueshme pĂ«r operimin efikas, pasi gjithmonĂ« pĂ«rpiqemi tĂ« hetojmĂ« incidentet sa mĂ« shpejt tĂ« jetĂ« e mundur, dhe pĂ«r hetimet afatgjata kemi tĂ« dhĂ«na telemetrie.Â
NĂ« tetor 2019, numri i vizitorĂ«ve tĂ« cian.ru u rrit nĂ« 15.3 milion pĂ«rdorues unik nĂ« muaj. Kjo ishte njĂ« provĂ« e rĂ«ndĂ«sishme pĂ«r zgjidhjen arkitekturore tĂ« dorĂ«zimit tĂ« logeve.Â
Tani po pĂ«rgatitemi tĂ« azhurnojmĂ« ElasticSearch nĂ« versionin 7. MegjithatĂ«, pĂ«r kĂ«tĂ« na nevojitet tĂ« azhurnojmĂ« mapping-un e shumĂ« indekseve nĂ« ElasticSearch, pasi ato u transferuan nga versioni 5.5 dhe u shpallĂ«n si tĂ« tĂ«rhequra nĂ« versionin 6 (nĂ« versionin 7 ato thjesht nuk ekzistojnĂ«). Dhe kjo do tĂ« thotĂ« se gjatĂ« procesit tĂ« azhurnimit patjetĂ«r do tĂ« ketĂ« ndonjĂ« forcĂ« mĂ« tĂ« madhe, e cila pĂ«rkohĂ«sisht do tĂ« na lĂ« pa loge. Nga versioni 7 presim mĂ« shumĂ« nga Kibana me ndĂ«rfaqen e pĂ«rmirĂ«suar dhe filtrat e rinj.Â
Ne arritëm qëllimin kryesor: ndalëm humbjen e logeve dhe e zvogëluam kohën pa funksion të klasterit infra-strukturor nga 2-3 rënie në javë në disa orë punë shërbimi në muaj. E gjithë kjo punë në prodhim është pothuajse e padukshme. Megjithatë, tani mund të përcaktojmë me saktësi se çfarë po ndodh me shërbimin tonë, mund ta bëjmë këtë shpejt në një ambient të qetë dhe nuk shqetësohemi se loget do të humbasin. Në përgjithësi, jemi të kënaqur, të lumtur dhe po përgatitemi për suksese të reja, për të cilat do të flasim më vonë.
Burimi: habr.com
