Hei alle sammen, jeg heter Alexander, jeg jobber i CIAN som ingeniør og er involvert i systemadministrasjon og automatisering av infrastrukturprosesser. I kommentarene til en av de tidligere artiklene ble vi bedt om å fortelle hvor vi får 4 TB logger per dag og hva vi gjør med dem. Ja, vi har mange logger, og det er opprettet en egen infrastrukturklynge for å behandle dem, som gjør at vi raskt kan løse problemer. I denne artikkelen skal jeg snakke om hvordan vi tilpasset den i løpet av et år for å jobbe med en stadig voksende dataflyt.
Hvor begynte vi?
I løpet av de siste årene har belastningen på cian.ru vokst veldig raskt, og i tredje kvartal 2018 nådde ressurstrafikken 11.2 millioner unike brukere per måned. På det tidspunktet mistet vi i kritiske øyeblikk opptil 40 % av loggene, og derfor kunne vi ikke raskt håndtere hendelser og brukte mye tid og krefter på å løse dem. Ofte kunne vi heller ikke finne årsaken til problemet, og det ville gjenta seg etter en tid. Det var et helvete og det måtte gjøres noe med.
På den tiden brukte vi en klynge på 10 datanoder med ElasticSearch versjon 5.5.2 med standard indeksinnstillinger for å lagre logger. Den ble introdusert for mer enn et år siden som en populær og rimelig løsning: da var strømmen av tømmerstokker ikke så stor, det var ingen vits i å komme med ikke-standardiserte konfigurasjoner.
Behandling av innkommende logger ble levert av Logstash på forskjellige porter på fem ElasticSearch-koordinatorer. En indeks, uansett størrelse, besto av fem skår. Det ble organisert en time- og daglig rotasjon, som et resultat av at det dukket opp rundt 100 nye skår i klyngen hver time. Selv om det ikke var veldig mange logger, klarte klyngen seg bra, og ingen tok hensyn til innstillingene.
Utfordringene med rask vekst
Volumet av genererte logger vokste veldig raskt, da to prosesser overlappet hverandre. På den ene siden vokste antallet brukere av tjenesten. På den annen side begynte vi aktivt å bytte til en mikrotjenestearkitektur, og saget opp våre gamle monolitter i C# og Python. Flere dusin nye mikrotjenester som erstattet deler av monolitten genererte betydelig flere logger for infrastrukturklyngen.
Det var skalering som førte oss til det punktet hvor klyngen ble praktisk talt uhåndterlig. Da loggene begynte å komme med en hastighet på 20 tusen meldinger per sekund, økte hyppig ubrukelig rotasjon antallet shards til 6 600, og det var mer enn XNUMX shards per node.
Dette førte til problemer med tildelingen av RAM, og når en node krasjet, begynte alle shards å bevege seg samtidig, og multipliserte trafikken og lastet inn andre noder, noe som gjorde det nesten umulig å skrive data til klyngen. Og i denne perioden ble vi stående uten tømmerstokker. Og hvis det var et problem med serveren, mistet vi i utgangspunktet 1/10 av klyngen. Et stort antall små indekser ga kompleksitet.
Uten logger forsto vi ikke årsakene til hendelsen og kunne før eller siden tråkke på samme rake igjen, og i ideologien til teamet vårt var dette uakseptabelt, siden alle våre arbeidsmekanismer er designet for å gjøre det motsatte - aldri gjenta de samme problemene. For å gjøre dette trengte vi hele volumet av logger og leveringen av dem nesten i sanntid, siden et team av vakthavende ingeniører overvåket varsler ikke bare fra beregninger, men også fra logger. For å forstå omfanget av problemet var det totale volumet av tømmerstokker på den tiden omtrent 2 TB per dag.
Vi satte et mål om å eliminere tap av logger fullstendig og redusere leveringstiden til ELK-klyngen til maksimalt 15 minutter under force majeure (vi brukte senere dette tallet som en intern KPI).
Ny rotasjonsmekanisme og varme-varme noder
Vi startet klyngekonverteringen ved å oppdatere ElasticSearch-versjonen fra 5.5.2 til 6.4.3. Nok en gang døde versjon 5-klyngen vår, og vi bestemte oss for å slå den av og fullstendig oppdatere den - det er fortsatt ingen logger. Så vi gjorde denne overgangen på bare et par timer.
Den mest omfattende transformasjonen på dette stadiet var implementeringen av Apache Kafka på tre noder med en koordinator som en mellombuffer. Meldingsmegleren reddet oss fra å miste logger under problemer med ElasticSearch. Samtidig la vi til 2 noder til klyngen og byttet til en varm-varm-arkitektur med tre "varme" noder plassert i forskjellige rack i datasenteret. Vi omdirigerte logger til dem ved å bruke en maske som ikke skal gå tapt under noen omstendigheter - nginx, så vel som applikasjonsfeillogger. Mindre logger ble sendt til de gjenværende nodene - feilsøking, advarsel, etc., og etter 24 timer ble "viktige" logger fra "varme" noder overført.
For ikke å øke antallet små indekser, byttet vi fra tidsrotasjon til rullemekanismen. Det var mye informasjon på forumene om at rotasjon etter indeksstørrelse er veldig upålitelig, så vi bestemte oss for å bruke rotasjon etter antall dokumenter i indeksen. Vi analyserte hver indeks og registrerte antall dokumenter som rotasjon skulle fungere etter. Dermed har vi nådd den optimale shard-størrelsen - ikke mer enn 50 GB.
Klyngeoptimalisering
Vi har imidlertid ikke blitt helt kvitt problemene. Dessverre dukket det fortsatt opp små indekser: de nådde ikke det angitte volumet, ble ikke rotert og ble slettet ved global rengjøring av indekser eldre enn tre dager, siden vi fjernet rotasjon etter dato. Dette førte til tap av data på grunn av at indeksen fra klyngen forsvant helt, og et forsøk på å skrive til en ikke-eksisterende indeks brøt logikken til kuratoren som vi brukte til ledelsen. Alias for skriving ble konvertert til en indeks og brøt rollover-logikken, noe som forårsaket ukontrollert vekst av noen indekser opp til 600 GB.
For eksempel for rotasjonskonfigurasjonen:
с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 det ikke var noe rollover-alias, oppstod det en feil:
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 overlot løsningen på dette problemet til neste iterasjon og tok opp et annet problem: vi byttet til pull-logikken til Logstash, som behandler innkommende logger (fjerner unødvendig informasjon og beriker). Vi plasserte den i docker, som vi lanserer via docker-compose, og vi plasserte også logstash-exporter der, som sender metrikk til Prometheus for operasjonell overvåking av loggstrømmen. På denne måten ga vi oss selv muligheten til å jevnt endre antall logstash-instanser som er ansvarlige for å behandle hver type logg.
Mens vi forbedret klyngen, økte trafikken til cian.ru til 12,8 millioner unike brukere per måned. Som et resultat viste det seg at transformasjonene våre lå litt bak endringene i produksjonen, og vi ble møtt med det faktum at de "varme" nodene ikke kunne takle belastningen og bremset hele leveringen av tømmerstokker. Vi mottok "varme" data uten feil, men vi måtte gripe inn i leveringen av resten og gjøre en manuell rollover for å fordele indeksene jevnt.
Samtidig ble skalering og endring av innstillingene for logstash-forekomster i klyngen komplisert av det faktum at det var en lokal docker-compose, og alle handlinger ble utført manuelt (for å legge til nye ender, var det nødvendig å manuelt gå gjennom alle serverne og gjør docker-compose up -d overalt).
Omfordeling av logg
I september i år kuttet vi fortsatt opp monolitten, belastningen på klyngen økte, og strømmen av logger nærmet seg 30 tusen meldinger per sekund.
Vi startet neste iterasjon med en maskinvareoppdatering. Vi byttet fra fem koordinatorer til tre, byttet ut datanoder og vant på penger og lagringsplass. For noder bruker vi to konfigurasjoner:
- For "hot" noder: E3-1270 v6 / 960 Gb SSD / 32 Gb x 3 x 2 (3 for Hot1 og 3 for Hot2).
- For "varme" noder: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Ved denne iterasjonen flyttet vi indeksen med tilgangslogger for mikrotjenester, som tar opp samme plass som frontlinje nginx-logger, til den andre gruppen av tre "varme" noder. Vi lagrer nå data på "varme" noder i 20 timer, og overfører dem deretter til "varme" noder til resten av loggene.
Vi løste problemet med at små indekser forsvant ved å rekonfigurere rotasjonen deres. Nå roteres indeksene hver 23. time i alle fall, selv om det er lite data der. Dette økte antallet shards litt (det var omtrent 800 av dem), men med tanke på klyngeytelse er det tolerabelt.
Som et resultat var det seks "varme" og bare fire "varme" noder i klyngen. Dette forårsaker en liten forsinkelse på forespørsler over lange tidsintervaller, men å øke antall noder i fremtiden vil løse dette problemet.
Denne iterasjonen løste også problemet med mangelen på halvautomatisk skalering. For å gjøre dette, distribuerte vi en infrastruktur Nomad-klynge - tilsvarende det vi allerede har distribuert i produksjon. Foreløpig endres ikke mengden Logstash automatisk avhengig av belastningen, men vi kommer til dette.
Planer for fremtiden
Den implementerte konfigurasjonen skalerer perfekt, og nå lagrer vi 13,3 TB med data - alle logger i 4 dager, noe som er nødvendig for nødanalyse av varsler. Vi konverterer noen av loggene til beregninger, som vi legger til Graphite. For å gjøre arbeidet til ingeniører enklere, har vi beregninger for infrastrukturklyngen og skript for halvautomatisk reparasjon av vanlige problemer. Etter å ha økt antallet datanoder, som er planlagt til neste år, går vi over til datalagring fra 4 til 7 dager. Dette vil være nok for operativt arbeid, siden vi alltid prøver å etterforske hendelser så raskt som mulig, og for langtidsundersøkelser finnes det telemetridata.
I oktober 2019 hadde trafikken til cian.ru allerede vokst til 15,3 millioner unike brukere per måned. Dette ble en seriøs test av den arkitektoniske løsningen for levering av stokker.
Nå forbereder vi oss på å oppdatere ElasticSearch til versjon 7. For dette må vi imidlertid oppdatere kartleggingen av mange indekser i ElasticSearch, siden de flyttet fra versjon 5.5 og ble erklært som avviklet i versjon 6 (de eksisterer rett og slett ikke i versjonen 7). Dette betyr at under oppdateringsprosessen vil det definitivt være en slags force majeure, som vil etterlate oss uten logger mens problemet er løst. Av versjon 7 gleder vi oss mest til Kibana med forbedret grensesnitt og nye filtre.
Vi nådde hovedmålet vårt: vi sluttet å miste logger og reduserte nedetiden til infrastrukturklyngen fra 2-3 krasj per uke til et par timers vedlikeholdsarbeid per måned. Alt dette arbeidet i produksjonen er nesten usynlig. Nå kan vi imidlertid finne ut nøyaktig hva som skjer med tjenesten vår, vi kan raskt gjøre det i en stille modus og ikke bekymre oss for at loggene vil gå tapt. Generelt er vi fornøyde, glade og forbereder oss på nye bedrifter, som vi skal snakke om senere.
Kilde: www.habr.com