Hej alle sammen, jeg hedder Alexander, jeg arbejder hos CIAN som ingeniør og er involveret i systemadministration og automatisering af infrastrukturprocesser. I kommentarerne til en af de tidligere artikler blev vi bedt om at fortælle, hvor vi får 4 TB logfiler om dagen, og hvad vi gør med dem. Ja, vi har mange logs, og der er oprettet en separat infrastrukturklynge til at behandle dem, som giver os mulighed for hurtigt at løse problemer. I denne artikel vil jeg fortælle om, hvordan vi har tilpasset det i løbet af et år til at arbejde med et stadigt voksende dataflow.
Hvor startede vi?
I løbet af de sidste par år er belastningen på cian.ru vokset meget hurtigt, og i tredje kvartal af 2018 nåede ressourcetrafikken 11.2 millioner unikke brugere om måneden. På det tidspunkt mistede vi i kritiske øjeblikke op til 40 % af logfilerne, hvorfor vi ikke hurtigt kunne håndtere hændelser og brugte meget tid og kræfter på at løse dem. Vi kunne også ofte ikke finde årsagen til problemet, og det ville gentage sig efter noget tid. Det var et helvede, og det skulle der gøres noget ved.
På det tidspunkt brugte vi en klynge på 10 dataknuder med ElasticSearch version 5.5.2 med standard indeksindstillinger til at gemme logfiler. Det blev introduceret for mere end et år siden som en populær og overkommelig løsning: så var strømmen af logs ikke så stor, det var ingen mening i at komme med ikke-standardkonfigurationer.
Behandling af indgående logfiler blev leveret af Logstash på forskellige porte på fem ElasticSearch-koordinatorer. Et indeks, uanset størrelse, bestod af fem skår. Der blev organiseret en time- og daglig rotation, som et resultat, der dukkede omkring 100 nye skår op i klyngen hver time. Selvom der ikke var særlig mange logfiler, klarede klyngen sig godt, og ingen var opmærksomme på dens indstillinger.
Udfordringerne ved hurtig vækst
Mængden af genererede logfiler voksede meget hurtigt, da to processer overlappede hinanden. På den ene side voksede antallet af brugere af tjenesten. På den anden side begyndte vi aktivt at skifte til en mikroservicearkitektur, hvor vi savede vores gamle monolitter op i C# og Python. Flere dusin nye mikrotjenester, der erstattede dele af monolitten, genererede betydeligt flere logfiler til infrastrukturklyngen.
Det var skalering, der førte os til det punkt, hvor klyngen blev praktisk talt uoverskuelig. Da logfilerne begyndte at ankomme med en hastighed på 20 tusinde beskeder i sekundet, øgede hyppig ubrugelig rotation antallet af shards til 6 tusinde, og der var mere end 600 shards per node.
Dette førte til problemer med tildelingen af RAM, og da en node styrtede ned, begyndte alle skår at bevæge sig samtidigt, hvilket multiplicerede trafikken og indlæste andre noder, hvilket gjorde det næsten umuligt at skrive data til klyngen. Og i denne periode stod vi uden træstammer. Og hvis der var et problem med serveren, mistede vi stort set 1/10 af klyngen. Et stort antal små indekser tilføjede kompleksitet.
Uden logs forstod vi ikke årsagerne til hændelsen og kunne før eller siden træde på den samme rake igen, og i vores teams ideologi var dette uacceptabelt, da alle vores arbejdsmekanismer er designet til at gøre det modsatte - aldrig gentage de samme problemer. For at gøre dette havde vi brug for hele mængden af logfiler og deres levering næsten i realtid, da et team af vagthavende ingeniører overvågede alarmer ikke kun fra metrikker, men også fra logfiler. For at forstå problemets omfang var den samlede mængde logs på det tidspunkt omkring 2 TB pr. dag.
Vi satte et mål om fuldstændigt at eliminere tabet af logfiler og reducere leveringstiden til ELK-klyngen til maksimalt 15 minutter under force majeure (vi har senere stolet på dette tal som en intern KPI).
Ny rotationsmekanisme og varme-varme noder
Vi startede klyngekonverteringen ved at opdatere ElasticSearch-versionen fra 5.5.2 til 6.4.3. Endnu en gang døde vores version 5-klynge, og vi besluttede at slå den fra og fuldstændig opdatere den - der er stadig ingen logfiler. Så vi lavede denne overgang på blot et par timer.
Den mest omfattende transformation på dette stadium var implementeringen af Apache Kafka på tre noder med en koordinator som en mellemliggende buffer. Meddelelsesmægleren reddede os fra at miste logfiler under problemer med ElasticSearch. Samtidig tilføjede vi 2 noder til klyngen og skiftede til en hot-warm arkitektur med tre "hot" noder placeret i forskellige racks i datacentret. Vi omdirigerede logfiler til dem ved hjælp af en maske, der under ingen omstændigheder bør gå tabt - nginx, såvel som applikationsfejllogfiler. Mindre logfiler blev sendt til de resterende noder - debug, advarsel osv., og efter 24 timer blev "vigtige" logfiler fra "varme" noder overført.
For ikke at øge antallet af små indekser skiftede vi fra tidsrotation til rollover-mekanismen. Der var mange oplysninger på foraerne om, at rotation efter indeksstørrelse er meget upålidelig, så vi besluttede at bruge rotation efter antallet af dokumenter i indekset. Vi analyserede hvert indeks og registrerede antallet af dokumenter, hvorefter rotation skulle fungere. Dermed har vi nået den optimale skærvstørrelse - ikke mere end 50 GB.
Klyngeoptimering
Vi er dog ikke helt sluppet af med problemerne. Desværre dukkede der stadig små indeks op: de nåede ikke det angivne volumen, blev ikke roteret og blev slettet ved global rensning af indekser ældre end tre dage, da vi fjernede rotation efter dato. Dette førte til datatab på grund af, at indekset fra klyngen forsvandt fuldstændigt, og et forsøg på at skrive til et ikke-eksisterende indeks brød logikken hos den kurator, som vi brugte til ledelsen. Alias til skrivning blev konverteret til et indeks og brød rollover-logikken, hvilket forårsagede ukontrolleret vækst af nogle indekser op til 600 GB.
For eksempel for rotationskonfigurationen:
сurator-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
Hvis der ikke var noget rollover-alias, opstod der en fejl:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Vi forlod løsningen på dette problem til næste iteration og tog et andet problem op: vi skiftede til pull-logikken i Logstash, som behandler indgående logfiler (fjerner unødvendig information og beriger). Vi placerede den i docker, som vi lancerer via docker-compose, og vi har også placeret logstash-exporter der, som sender metrics til Prometheus for operationel overvågning af logstrømmen. På denne måde gav vi os selv muligheden for problemfrit at ændre antallet af logstash-instanser, der er ansvarlige for at behandle hver type log.
Mens vi forbedrede klyngen, steg cian.ru's trafik til 12,8 millioner unikke brugere om måneden. Som et resultat viste det sig, at vores transformationer var lidt bagud i forhold til ændringerne i produktionen, og vi stod over for, at de "varme" noder ikke kunne klare belastningen og bremsede hele leveringen af logs. Vi modtog "varme" data uden fejl, men vi var nødt til at gribe ind i leveringen af resten og lave en manuel rollover for at fordele indekserne jævnt.
Samtidig blev skalering og ændring af indstillingerne for logstash-forekomster i klyngen kompliceret af det faktum, at det var en lokal docker-compose, og alle handlinger blev udført manuelt (for at tilføje nye ender var det nødvendigt at gå igennem alle serverne og lav docker-compose up -d overalt).
Log omfordeling
I september i år skar vi stadig monolitten op, belastningen på klyngen steg, og strømmen af logfiler nærmede sig 30 tusinde beskeder i sekundet.
Vi startede den næste iteration med en hardwareopdatering. Vi skiftede fra fem koordinatorer til tre, udskiftede dataknudepunkter og vandt i form af penge og lagerplads. Til noder bruger vi to konfigurationer:
- For "hot" noder: E3-1270 v6 / 960 Gb SSD / 32 Gb x 3 x 2 (3 for Hot1 og 3 for Hot2).
- Til "varme" noder: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Ved denne iteration flyttede vi indekset med adgangslogfiler for mikrotjenester, som optager samme plads som nginx-logfiler i frontlinjen, til den anden gruppe af tre "varme" noder. Vi gemmer nu data på "varme" noder i 20 timer, og overfører dem derefter til "varme" noder til resten af logfilerne.
Vi løste problemet med at små indekser forsvandt ved at omkonfigurere deres rotation. Nu roteres indekserne hver 23. time under alle omstændigheder, selvom der er lidt data der. Dette øgede en smule antallet af shards (der var omkring 800 af dem), men set ud fra klyngens ydeevne er det acceptabelt.
Som et resultat var der seks "varme" og kun fire "varme" noder i klyngen. Dette forårsager en lille forsinkelse på anmodninger over lange tidsintervaller, men en forøgelse af antallet af noder i fremtiden vil løse dette problem.
Denne iteration løste også problemet med manglen på halvautomatisk skalering. For at gøre dette implementerede vi en infrastruktur Nomad-klynge - svarende til det, vi allerede har implementeret i produktionen. Indtil videre ændres mængden af Logstash ikke automatisk afhængigt af belastningen, men vi kommer frem til dette.
Planer for fremtiden
Den implementerede konfiguration skalerer perfekt, og nu gemmer vi 13,3 TB data - alle logs i 4 dage, hvilket er nødvendigt for nødanalyse af alarmer. Vi konverterer nogle af logfilerne til metrics, som vi tilføjer til Graphite. For at gøre arbejdet for ingeniører lettere, har vi målinger for infrastrukturklyngen og scripts til semi-automatisk reparation af almindelige problemer. Efter at have øget antallet af dataknudepunkter, som er planlagt til næste år, skifter vi til datalagring fra 4 til 7 dage. Dette vil være nok til operationelt arbejde, da vi altid forsøger at efterforske hændelser så hurtigt som muligt, og for langsigtede undersøgelser er der telemetridata.
I oktober 2019 var trafikken til cian.ru allerede vokset til 15,3 millioner unikke brugere om måneden. Dette blev en seriøs test af den arkitektoniske løsning til levering af træstammer.
Nu forbereder vi os på at opdatere ElasticSearch til version 7. Men til dette bliver vi nødt til at opdatere kortlægningen af mange indekser i ElasticSearch, da de flyttede fra version 5.5 og blev erklæret som forældede i version 6 (de eksisterer simpelthen ikke i version 7) 7). Det betyder, at der under opdateringsprocessen helt sikkert vil være en form for force majeure, som vil efterlade os uden logs, mens problemet er løst. Af version XNUMX ser vi mest frem til Kibana med en forbedret grænseflade og nye filtre.
Vi nåede vores hovedmål: vi holdt op med at miste logfiler og reducerede nedetiden for infrastrukturklyngen fra 2-3 nedbrud om ugen til et par timers vedligeholdelsesarbejde om måneden. Alt dette arbejde i produktionen er næsten usynligt. Men nu kan vi bestemme præcist, hvad der sker med vores tjeneste, vi kan hurtigt gøre det i en stille tilstand og ikke bekymre os om, at logfilerne går tabt. Generelt er vi tilfredse, glade og forbereder os på nye bedrifter, som vi vil tale om senere.
Kilde: www.habr.com