{"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\/et\/blog\/administrirovanie\/kak-my-v-tsian-ukroshhali-terabajty-logov","title":{"rendered":"Kuidas me CIAN-is taltsutasime terabaitide logisid","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kuidas
\n
\nTere, minu nimi on Aleksandr, ma t\u00f6\u00f6tan CIANis insenerina ja tegelema s\u00fcsteemiadministreerimise ning infrastruktuuri protsesside automatiseerimisega. \u00dches eelmises artiklis palusime kommenteerida, kust me v\u00f5tame 4 TB logisid p\u00e4evas ja mida nendega teeme. Jah, meil on palju logisid, ning nende t\u00f6\u00f6tlemiseks on loodud eraldi infrastruktuuri klaster, mis v\u00f5imaldab meil kiiresti probleeme lahendada. Selles artiklis r\u00e4\u00e4gin, kuidas me aasta jooksul kohandasime seda pidevalt kasvava andmevooga toimetamiseks.
\n<\/a><\/noindex><\/p>\n

Kust me alustasime<\/h3>\n

\n\"Kuidas
\n
\nViimastel aastatel on cian.ru koormus kiiresti kasvanud ja 2018. aasta kolmandaks kvartaliks saavutas ressursi k\u00fclastatavus 11,2 miljonit unikaalset kasutajat kuus. Tol ajal kaotasime kriitilistel hetkedel kuni 40% logidest, mist\u00f5ttu ei suutnud me kiiresti juhtumeid lahendada ja kulutasime nende lahendamisele palju aega ja vaeva. Samuti ei suutnud me sageli leida probleemi p\u00f5hjust, mist\u00f5ttu see kordus m\u00f5ne aja p\u00e4rast. See oli p\u00f5rgu, millega tuli midagi ette v\u00f5tta.<\/p>\n

Tollal kasutasime logide salvestamiseks 10 andmeklastri node'ist koosnevat klastrit ElasticSearch versioonis 5.5.2 tavaliste indeksiseadetega. See rakendati \u00fcle aasta tagasi populaarse ja kergesti k\u00e4tte saadava lahendusena: siis ei olnud logide voog nii suur, et oleks olnud m\u00f5tet v\u00e4lja m\u00f5elda mittestandardseid konfiguratsioone.\u00a0<\/p>\n

Sissetulevate logide t\u00f6\u00f6tlemist tagas Logstash erinevatel portidel viiel ElasticSearchi koordinaatoril. \u00dcks indeks, olenemata suurusest, koosnes viiest shardist. Oli korraldatud tunnine ja p\u00e4evaste rotatsioonide s\u00fcsteem, mille tulemuseks oli see, et klastris ilmus iga tunni jooksul umbes 100 uut shard'i. Kui logisid ei olnud veel palju, siis klaster suutis sellega toime tulla ning keegi ei p\u00f6\u00f6ranud t\u00e4helepanu selle seadistamisele.\u00a0<\/p>\n

Kiire kasvu probleemid<\/h3>\n

\nGenereeritud logide maht kasvas kiiresti, kuna kahel protsessil oli \u00fcksteisele m\u00f5ju. \u00dchelt poolt kasvas teenuse kasutajate arv. Teiselt poolt hakkasime aktiivselt liikuma mikroteenuste arhitektuuri suunas, jagades meie vanu monoliite C# ja Pythoni peale. Mitmed tosinad uued mikroteenused, mis asendasid monoliidi osi, genereerisid infrastruktuuri klastri jaoks m\u00e4rgatavalt rohkem logisid.\u00a0<\/p>\n

Just scaling led us to the point where the cluster became almost unmanageable. When logs started coming in at a rate of 20,000 messages per second, frequent useless rotation increased the number of shards to 6,000, with more than 600 shards per node.\u00a0<\/p>\n

This caused issues with memory allocation, and when a node failed, all the shards would be moved simultaneously, multiplying traffic and burdening the remaining nodes, making it nearly impossible to write data to the cluster. During this time, we were without logs. And when there was an issue with serverilt<\/a> we lost 1\/10 of the cluster overall. The large number of small-sized indexes added complexity.<\/p>\n

Without logs, we didn\u2019t understand the causes of incidents and could sometime fall into the same traps again, which was unacceptable for our team\u2019s ideology, as all our work mechanisms are set to avoid repeating the same problems. For this, we needed the complete volume of logs delivered almost in real time, since the on-call engineering team monitored alerts not only from metrics but also from logs. To understand the scale of the problem \u2014 at that time, the total volume of logs was about 2 TB per day.\u00a0<\/p>\n

We set the task to completely eliminate log loss and reduce the delivery time to the ELK cluster to a maximum of 15 minutes during emergencies (we later relied on this figure as an internal KPI).<\/p>\n

New rotation mechanism and hot-warm nodes<\/h3>\n

\n\"Kuidas
\n
\nWe began transforming the cluster by updating the ElasticSearch version from 5.5.2 to 6.4.3. Our cluster of the 5th version crashed again, and we decided to shut it down and completely update it \u2014 after all, there were no logs. So we made this transition in just a couple of hours.<\/p>\n

Selle etapi k\u00f5ige ulatuslikumaks muudatuseks oli Apache Kafka juurutamine kolmes s\u00f5lmes koordinaatorina vahepealse puhvrina. S\u00f5numite vahendaja vabastas meid logide kadumise probleemist ElasticSearchiga. Samuti lisasime me klastrisse 2 s\u00f5lme ja \u00fclemineku hot-warm arhitektuurile kolme \u201ekuuma\u201d s\u00f5lmega, paigutatuna erinevatesse aluskappidest andmekeskuses. Neile suunati logid, mida ei tohtinud mingil juhul kaotada \u2014 nginx ja rakenduste vealogid. \u00dclej\u00e4\u00e4nud s\u00f5lmedele suunati v\u00e4hemolulised logid \u2014 debug, warning jne., ja 24 tunni p\u00e4rast viidi \u201eolulised\u201d logid \u201ekuumadest\u201d s\u00f5lmedest edasi.<\/p>\n

Selleks, et mitte suurendada v\u00e4ikeste indeksite arvu, l\u00e4ksime ajap\u00f5hiselt p\u00f6\u00f6rdl\u00f6\u00f6kide mehhanismile. Foorumites oli palju teavet selle kohta, et suuruse j\u00e4rgi p\u00f6\u00f6rdl\u00f6\u00f6k on v\u00e4ga ebausaldusv\u00e4\u00e4rne, seet\u00f5ttu otsustasime kasutada p\u00f6\u00f6rdl\u00f6\u00f6ki dokumentide arvu j\u00e4rgi indeksis. Anal\u00fc\u00fcsisime iga indeksit ja m\u00e4\u00e4rasime dokumentide arvu, p\u00e4rast mille \u00fcletamist p\u00f6\u00f6rdl\u00f6\u00f6k peab toimuma. Nii saavutasime optimaalse shard'i suuruse \u2014 mitte \u00fcle 50 GB.\u00a0<\/p>\n

Klastri optimeerimine<\/h3>\n

\n\"Kuidas
\n
\nKuid t\u00e4ielikult probleemidest ei vabanenud. Kahjuks ilmnesid ikkagi v\u00e4ikesed indeksid: need ei saavutanud m\u00e4\u00e4ratud mahtu, ei p\u00f6\u00f6rdl\u00f6\u00f6kid ja eemaldati globaalsete indeksite puhastamise kaudu, mis on vanemad kui kolm p\u00e4eva, kuna olime eemaldanud p\u00f6\u00f6rdl\u00f6\u00f6gid kuup\u00e4eva j\u00e4rgi. See viis andmete kadumise probleemideni, kuna indeks kadus klastrist t\u00e4ielikult ning katse kirjutada mitteseksisteerivasse indeksisse rikkus meie halduse loogikat, milleks oli curator. Kirjutamine m\u00f5eldud alias muutus indeksiks ja rikkus p\u00f6\u00f6rdl\u00f6\u00f6giprotsessi, p\u00f5hjustades m\u00f5nede indeksite kontrollimatut kasvu kuni 600 GB.\u00a0<\/p>\n

N\u00e4iteks p\u00f6\u00f6rdl\u00f6\u00f6gi konfiguratsiooni jaoks:<\/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
Rollover aliasi puudumisel tekkis viga:<\/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
Selle probleemi lahendamise j\u00e4tame j\u00e4rgmisse iteratsiooni ja keskendume muule: oleme \u00fcle l\u00e4inud pull-loogikale, mida haldab Logstash, mis tegeleb sisendlogide t\u00f6\u00f6tlemisega (liigse teabe eemaldamine ja rikastamine). Oleme selle paigutanud dockerisse, mida k\u00e4ivitame docker-compose kaudu, ning seal oleme paigutanud logstash-exporteri, mis edastab metrika Prometheusele logivoogude kiireks j\u00e4lgimiseks. Nii oleme endale v\u00f5imaldanud sujuvalt muuta logstashide instantside arvu, mis vastutavad iga logit\u00fc\u00fcbi t\u00f6\u00f6tlemise eest.<\/p>\n
Kuni me t\u00e4iustasime klastrit, kasvas cian.ru k\u00fclastatavus 12,8 miljoni unikaalse kasutajani kuus. Tulemuseks oli see, et meie muudatused ei j\u00f5udnud veidi produktsiooni muutustega sammu pidada ja seisime silmitsi olukorraga, kus \u201esoe\u201d nood ei suutnud koormusega toime tulla ning pidurdasid kogu logide edastamise. \u201eK\u00fcpset\u201d andmed saime probleemideta, kuid \u00fclej\u00e4\u00e4nud edastamisel tuli sekkuda ja teha k\u00e4sitsi rollover, et jagada indeksid \u00fchtlaselt.\u00a0<\/p>\n
Samas muutis logstashide instantside klastris skaleerimine ja seadistuste muutmine keeruliseks, kuna see oli lokaalne docker-compose ja k\u00f5ik toimingud viidi l\u00e4bi k\u00e4sitsi (uute l\u00f5ppude lisamiseks tuli k\u00f5ik serverid k\u00e4sitsi l\u00e4bi k\u00e4ia ja igal pool teha docker-compose up -d).<\/p>\n
Logide \u00fcmberjaotamine<\/h3>\n
\nSelle aasta septembris j\u00e4tkasime endiselt monoliidi l\u00f5hkumist, klastrile avaldatud koormus kasvas ja logide voog j\u00f5udis 30 000 s\u00f5numini sekundis.\u00a0<\/p>\n
\"Kuidas
\n
\nJ\u00e4rgmise iteratsiooni alustasime riistvara v\u00e4rskendamisega. Viie koordinaatori asemel l\u00e4ksime kolme peale, vahetasime v\u00e4lja andme noodid ja v\u00f5itsime raha ja salvestusmahtu. Noodide jaoks kasutame kahte konfiguratsiooni:\u00a0<\/p>\n