{"id":53590,"date":"2019-12-05T00:00:00","date_gmt":"2019-12-04T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/kak-my-v-tsian-ukroshhali-terabajty-logov"},"modified":"2020-02-18T14:01:30","modified_gmt":"2020-02-18T11:01:30","slug":"kak-my-v-tsian-ukroshhali-terabajty-logov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-my-v-tsian-ukroshhali-terabajty-logov","title":{"rendered":"Hvordan vi i CIAN t\u00e6mmede terabyte af logs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Hvordan
\n
\nHej alle sammen, mit navn er Alexander, jeg arbejder som ingeni\u00f8r hos CIAN og besk\u00e6ftiger mig med systemadministration og automatisering af infrastrukturprocesser. I kommentarfeltet til en af vores tidligere artikler blev vi bedt om at fort\u00e6lle, hvor vi f\u00e5r 4 TB logfiler om dagen fra, og hvad vi g\u00f8r med dem. Ja, vi har mange logfiler, og der er oprettet et separat infrastrukturcluster til deres behandling, hvilket g\u00f8r det muligt for os at l\u00f8se problemer hurtigt. I denne artikel vil jeg fort\u00e6lle om, hvordan vi i l\u00f8bet af et \u00e5r har tilpasset det til at arbejde med en konstant voksende str\u00f8m af data.
\n<\/a><\/noindex><\/p>\n

Hvordan vi startede<\/h3>\n

\n\"Hvordan
\n
\nDe sidste par \u00e5r er belastningen p\u00e5 cian.ru steget meget hurtigt, og i tredje kvartal af 2018 n\u00e5ede antallet af unikke brugere p\u00e5 siden op p\u00e5 11,2 millioner om m\u00e5neden. P\u00e5 det tidspunkt mistede vi op til 40 % af logfilerne i kritiske \u00f8jeblikke, hvilket gjorde, at vi ikke kunne h\u00e5ndtere h\u00e6ndelserne hurtigt og brugte meget tid og kr\u00e6fter p\u00e5 at l\u00f8se dem. Vi kunne ogs\u00e5 ofte ikke finde \u00e5rsagen til problemerne, hvilket fik dem til at gentage sig efter et stykke tid. Det var et helvede, som vi m\u00e5tte g\u00f8re noget ved.<\/p>\n

P\u00e5 det tidspunkt brugte vi et cluster best\u00e5ende af 10 datanoder med ElasticSearch version 5.5.2 med standardindstillinger for indekser. Det blev implementeret for mere end et \u00e5r siden som en popul\u00e6r og tilg\u00e6ngelig l\u00f8sning: dengang var str\u00f8mmen af logfiler ikke s\u00e5 stor, s\u00e5 det gav ikke mening at finde p\u00e5 ikke-standard konfigurationer.\u00a0<\/p>\n

Behandlingen af de indkommende logfiler blev h\u00e5ndteret af Logstash p\u00e5 forskellige porte p\u00e5 fem ElasticSearch-koordinatorer. \u00c9n indeks, uanset st\u00f8rrelse, bestod af fem shards. Der var etableret time- og d\u00f8gnrotation, hvilket resulterede i, at der hver time blev tilf\u00f8jet cirka 100 nye shards til clusteren. Da antallet af logfiler ikke var alt for mange, klarede klusteret det, og ingen lagde m\u00e6rke til dets indstillinger.\u00a0<\/p>\n

Problemer med hastig v\u00e6kst<\/h3>\n

\nM\u00e6ngden af genererede logfiler voksede meget hurtigt, da to processer overlapmede hinanden. P\u00e5 den ene side blev antallet af brugere af tjenesten st\u00f8rre. P\u00e5 den anden side begyndte vi aktivt at skifte til en mikrotjenestearkitektur, hvilket involverede, at vi delte vores gamle monolitter op i C# og Python. Flere dusin nye mikrotjenester, der erstattede dele af monolitten, genererede betydeligt flere logfiler til infrastrukturclusteren.\u00a0<\/p>\n

Skalering var netop \u00e5rsagen til, at klyngen blev n\u00e6sten umulig at styre. Da loggene begyndte at komme ind med en hastighed p\u00e5 20.000 meddelelser per sekund, \u00f8gede hyppig ubrugelig rotation antallet af shards til 6.000, og hver node havde mere end 600 shards.\u00a0<\/p>\n

Dette f\u00f8rte til problemer med tildelingen af RAM, og da en node fejlede, begyndte alle shards at flytte samtidig, hvilket fordoblede trafikken og belastede de andre noder, hvilket gjorde det n\u00e6sten umuligt at skrive data til klyngen. I denne periode var vi ogs\u00e5 uden logs. Og ved problemet med serveren<\/a> mistede vi 1\/10 af klyngen generelt. Et stort antal sm\u00e5 indeks gjorde det ogs\u00e5 mere kompliceret.<\/p>\n

Uden logs forstod vi ikke \u00e5rsagerne til h\u00e6ndelsen og kunne p\u00e5 et eller andet tidspunkt risikere at tr\u00e6de p\u00e5 de samme t\u00e6er igen, hvilket var helt uacceptabelt for vores teams ideologi, da alle vores arbejdsmechanismer er skr\u00e6ddersyet til det stik modsatte \u2014 aldrig at gentage de samme problemer. Derfor havde vi brug for et komplet s\u00e6t logs og deres levering n\u00e6sten i realtid, da teamet av de vagthavende ingeni\u00f8rer overv\u00e5gede alerter ikke kun fra metrics, men ogs\u00e5 fra logs. For at forst\u00e5 omfanget af problemet - p\u00e5 det tidspunkt udgjorde det samlede logniveau cirka 2 TB om dagen.\u00a0<\/p>\n

Vi satte os for at helt undg\u00e5 tab af logs og reducere leveringstiden til klyngen ELK til maksimum 15 minutter under n\u00f8dsituationer (til dette tal refererede vi senere som vores interne KPI).<\/p>\n

Ny mekanisme til rotation og hot-warm noder<\/h3>\n

\n\"Hvordan
\n
\nVi begyndte transformationen af klyngen med at opdatere versionen af ElasticSearch fra 5.5.2 til 6.4.3. Vores klynge 5 versionen gik endnu en gang ned, og vi besluttede at lukke den ned og opdatere den helt - der var trods alt ingen logs. S\u00e5 denne overgang tog vi kun et par timer.<\/p>\n

Den mest omfattende \u00e6ndring p\u00e5 dette stadium var implementeringen p\u00e5 tre noder med en koordinator som mellembuffer for Apache Kafka. Beskedbrokeren befriede os fra tab af logs under problemer med ElasticSearch. Samtidig tilf\u00f8jede vi 2 noder til klyngen og skiftede til en hot-warm arkitektur med tre \"varme\" noder placeret i forskellige skuffer i datacenteret. Her videresendte vi logs, som ikke m\u00e5tte g\u00e5 tabt \u2014 nginx og ogs\u00e5 logs for applikationsfejl. De \u00f8vrige noder modtog mindre vigtige logs \u2014 debug, warning osv., og efter 24 timer blev \"vigtige\" logs flyttet fra de \"varme\" noder.<\/p>\n

For ikke at \u00f8ge antallet af sm\u00e5 indekser gik vi fra tidsrotation til et rollover-mekanisme. Der var mange oplysninger p\u00e5 forum om, at rotationsmetoden baseret p\u00e5 st\u00f8rrelsen af indekset var meget usikker, s\u00e5 vi besluttede at bruge rotation baseret p\u00e5 antallet af dokumenter i indekset. Vi analyserede hvert indeks og optegnede antallet af dokumenter, hvor efter rotation skulle finde sted. P\u00e5 den m\u00e5de opn\u00e5ede vi en optimal shardst\u00f8rrelse \u2014 ikke mere end 50 GB.\u00a0<\/p>\n

Klyngeoptimering<\/h3>\n

\n\"Hvordan
\n
\nMen vi slap ikke helt for problemerne. Desv\u00e6rre optr\u00e5dte der stadig sm\u00e5 indekser: de n\u00e5ede ikke den \u00f8nskede st\u00f8rrelse, blev ikke roteret og blev fjernet ved en global reng\u00f8ring af indekser, der var \u00e6ldre end tre dage, da vi fjernede rotationsmetoden baseret p\u00e5 dato. Dette f\u00f8rte til tab af data, fordi indexet forsvandt helt fra klyngen, og et fors\u00f8g p\u00e5 at skrive til et ikke-eksisterende indeks br\u00f8d logikken i curator\u2019en, som vi brugte til at styre. Alias til skrivning blev transformeret til indekset og br\u00f8d rollover-logikken, hvilket skabte ukontrolleret v\u00e6kst i nogle indekser op til 600 GB.\u00a0<\/p>\n

For eksempel for konfigurationen af rotation:<\/p>\n

curator-elk-rollover.yaml\n\n---\nactions:\n\u00a0\u00a01:\n\u00a0\u00a0\u00a0\u00a0action: rollover\n\u00a0\u00a0\u00a0\u00a0options:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0name: \"nginx_write\"\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0conditions:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0max_docs: 100000000\n\u00a0\u00a02:\n\u00a0\u00a0\u00a0\u00a0action: rollover\n\u00a0\u00a0\u00a0\u00a0options:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0name: \"python_error_write\"\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0conditions:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0max_docs: 10000000\n<\/code><\/pre>\n
I frav\u00e6ret af rollover alias opstod der en fejl:<\/p>\n
ERROR \u00a0 \u00a0 alias \"nginx_write\" not found.\nERROR \u00a0 \u00a0 Failed to complete action: rollover.\u00a0 <type 'exceptions.ValueError'>: Unable to perform index rollover with alias \"nginx_write\".\n<\/code><\/pre>\n
Vi efterlod l\u00f8sning af dette problem til n\u00e6ste iteration og fokuserede p\u00e5 et andet sp\u00f8rgsm\u00e5l: vi gik over til pull-logik for Logstash, som h\u00e5ndterer behandling af indg\u00e5ende logs (fjernelse af overfl\u00f8dig information og berigelse). Vi satte det i docker, som vi k\u00f8rer gennem docker-compose, hvor vi ogs\u00e5 placerede logstash-exporter, der sender metrikker til Prometheus for hurtig overv\u00e5gning af logstr\u00f8mmen. P\u00e5 den m\u00e5de gav vi os selv mulighed for glat at \u00e6ndre antallet af logstash-instanser, der h\u00e5ndterer hver type log.<\/p>\n
Mens vi forbedrede klyngen, voksede bes\u00f8get p\u00e5 cian.ru til 12,8 millioner unikke brugere om m\u00e5neden. Som resultat stod vi over for, at vores transformationer lidt forsinkede sig i forhold til \u00e6ndringerne i produktionen, og vi oplevede, at de \"varme\" noder ikke kunne h\u00e5ndtere belastningen og bremse hele leveringen af logs. De \"kolde\" data modtog vi uden problemer, men til leveringen af de andre m\u00e5tte vi gribe ind og lave manuel rollover for j\u00e6vnt at fordele indeksene.\u00a0<\/p>\n
Samtidig blev skalering og \u00e6ndring af indstillingerne for logstash-instanserne i klyngen kompliceret af, at dette var en lokal docker-compose, og alle handlinger blev udf\u00f8rt manuelt (for at tilf\u00f8je nye endepunkter var det n\u00f8dvendigt manuelt at g\u00e5 igennem alle serverne og udf\u00f8re docker-compose up -d overalt).<\/p>\n
Genfordeling af logs<\/h3>\n
\nI september i \u00e5r fortsatte vi stadig med at sk\u00e6re monolitten, belastningen p\u00e5 klyngen steg, og logstr\u00f8mmen n\u00e6rmede sig 30.000 beskeder i sekundet.\u00a0<\/p>\n
\"Hvordan
\n
\nVi begyndte den n\u00e6ste iteration med opgradering af hardwaren. Fra fem koordinatorer gik vi ned til tre, vi udskiftede datanoder og vandt b\u00e5de penge og lagerkapacitet. Til noderne bruger vi to konfigurationer:\u00a0<\/p>\n