{"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\/hr\/blog\/administrirovanie\/kak-my-v-tsian-ukroshhali-terabajty-logov","title":{"rendered":"Kako smo u CIAN-u ukrotili terabajte logova","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kako
\n
\nBok svima, ja sam Aleksandar, radim kao in\u017eenjer u CIAN-u i bavim se sistemskim administriranjem i automatizacijom infrastrukturnih procesa. U komentarima na jedan od pro\u0161lih \u010dlanaka zamolili su nas da objasnimo odakle uzimamo 4 TB logova dnevno i \u0161to radimo s njima. Da, imamo puno logova, a za njihovu obradu stvoren je poseban infrastrukturni klaster koji nam omogu\u0107ava brzo rje\u0161avanje problema. U ovom \u010dlanku \u0107u objasniti kako smo u godinu dana prilagodili ovaj sustav za rad s kontinuirano rastu\u0107im tokom podataka.
\n<\/a><\/noindex><\/p>\n

Od \u010dega smo po\u010deli<\/h3>\n

\n\"Kako
\n
\nPosljednjih nekoliko godina optere\u0107enje na cian.ru brzo je raslo, a do tre\u0107eg kvartala 2018. godine posje\u0107enost resursa dostigla je 11.2 milijuna jedinstvenih korisnika mjese\u010dno. U to vrijeme, u kriti\u010dnim trenucima smo gubili do 40% logova, zbog \u010dega nismo mogli brzo reagirati na incidente i tro\u0161ili smo puno vremena i truda na njihovo rje\u0161avanje. Tako\u0111er smo \u010desto nismo mogli prona\u0107i uzrok problema, \u0161to je rezultiralo ponavljanjem istih nakon nekog vremena. To je bila katastrofa kojoj se trebalo posvetiti.<\/p>\n

Tada smo koristili klaster od 10 data-nodova s ElasticSearch verzije 5.5.2 s standardnim postavkama indeksa za pohranu logova. Uveden je vi\u0161e od godinu dana kao popularno i pristupa\u010dno rje\u0161enje: tada tok logova nije bio tako velik, pa nije bilo smisla smi\u0161ljati nestandardne konfiguracije.\u00a0<\/p>\n

Obradu dolaznih logova osiguravao je Logstash na razli\u010ditim portovima na pet koordinatora ElasticSearch. Jedan indeks, neovisno o veli\u010dini, sastojao se od pet shardova. Organizirana je rotacija na satnoj i dnevnoj bazi, te je rezultat bio da je svaki sat u klasteru dolazilo otprilike 100 novih shardova. Dok logova nije bilo previ\u0161e, klaster je dobro funkcionirao i nitko se nije usredoto\u010dio na njegove postavke.\u00a0<\/p>\n

Problemi brzi rast<\/h3>\n

\nObujam generiranih logova brzo je rastao, jer su se dva procesa preklapala. S jedne strane, broj korisnika usluge je rastao. S druge strane, po\u010deli smo aktivno prelaziti na mikroservisnu arhitekturu, razdvajaju\u0107i na\u0161e stare monolite napisane u C# i Pythonu. Nekoliko desetaka novih mikroservisa, koji su zamijenili dijelove monolita, generiralo je znatno vi\u0161e logova za infrastrukturni klaster.\u00a0<\/p>\n

Skaliranje je upravo dovelo do toga da je klaster postao gotovo neurediv. Kada su logovi po\u010deli pristizati brzinom od 20 tisu\u0107a poruka u sekundi, \u010desta beskorisna rotacija pove\u0107ala je broj shardova na 6 tisu\u0107a, a na jednu nodu je dolazilo vi\u0161e od 600 shardova.\u00a0<\/p>\n

To je dovodilo do problema s alokacijom radne memorije, a kada bi do\u0161lo do pada node, po\u010dinjao je simultani oporavak svih shardova, pove\u0107avaju\u0107i promet i optere\u0107uju\u0107i ostale node, \u0161to je gotovo onemogu\u0107ilo zapis podataka u klaster. U to vrijeme ostali smo bez logova. A pri problemu s serverom<\/a> gubili bismo 1\/10 klastera u su\u0161tini. Veliki broj malih indeksa dodatno je ote\u017eao situaciju.<\/p>\n

Bez logova nismo razumjeli uzroke incidenta i mogli smo na kraju ponovno naletjeti na iste probleme, a u ideologiji na\u0161e ekipe to je bilo neprihvatljivo, jer su svi na\u0161i radni mehanizmi usmjereni upravo na suprotno \u2014 nikada ne ponavljati iste probleme. Za to su nam bili potrebni puni logovi i dostava gotovo u stvarnom vremenu, jer je tim in\u017eenjera na du\u017enosti pratio alerte ne samo od metrika, nego i od logova. Da bismo razumjeli opseg problema \u2014 u to vrijeme ukupna koli\u010dina logova iznosila je oko 2 TB dnevno.\u00a0<\/p>\n

Postavili smo cilj \u2014 potpuno isklju\u010diti gubitak logova i skratiti vrijeme njihove dostave u ELK klaster na maksimalno 15 minuta tijekom izvanrednih situacija (na ovu brojku smo se kasnije oslanjali kao na unutarnji KPI).<\/p>\n

Novi mehanizam rotacije i hot-warm node<\/h3>\n

\n\"Kako
\n
\nTransformaciju klastera zapo\u010deli smo a\u017euriranjem verzije ElasticSearch s 5.5.2 na 6.4.3. Ponovno nam je klaster pete verzije pao, odlu\u010dili smo ga gasiti i potpuno a\u017eurirati \u2014 logova ionako nema. Tako smo ovaj prijelaz izvr\u0161ili za tek nekoliko sati.<\/p>\n

Najve\u0107a transformacija u ovoj fazi bilo je implementiranje na tri \u010dvora s koordinatorom kao me\u0111uspremnikom za Apache Kafka. Poslani\u010dka platforma oslobodila nas je od gubitka logova tijekom problema s ElasticSearch. Istovremeno smo dodali 2 \u010dvora u klaster i pre\u0161li na hot-warm arhitekturu s tri \u201evru\u0107a\u201c \u010dvora raspore\u0111ena u razli\u010ditim ormarima u podatkovnom centru. Na njih smo preusmjerili logove koje ne smijemo gubiti pod nikakvim uvjetima \u2014 nginx, kao i logove gre\u0161aka aplikacija. Na ostale \u010dvorove su odlazili manji logovi \u2014 debug, warning itd., a tako\u0111er su nakon 24 sata prelazili \u201eva\u017eni\u201c logovi s \u201evru\u0107ih\u201c \u010dvorova.<\/p>\n

Kako bismo izbjegli pove\u0107anje broja malih indeksa, pre\u0161li smo s rotacije prema vremenu na mehanizam rollover. Na forumima je bilo mnogo informacija da je rotacija prema veli\u010dini indeksa vrlo nepouzdana, pa smo odlu\u010dili koristiti rotaciju prema broju dokumenata u indeksu. Analizirali smo svaki indeks i zabilje\u017eili broj dokumenata nakon kojeg bi trebala uslijediti rotacija. Na taj na\u010din smo postigli optimalnu veli\u010dinu shard-a \u2014 ne vi\u0161e od 50 GB.\u00a0<\/p>\n

Optimizacija klastera<\/h3>\n

\n\"Kako
\n
\nMe\u0111utim, potpuno se nismo oslobodili problema. Na\u017ealost, i dalje su se pojavljivali mali indeksi: nisu dostizali zadani volumen, nisu se rotirali i brisani su globalnim \u010di\u0161\u0107enjem indeksa starijih od tri dana, budu\u0107i da smo uklonili rotaciju prema datumu. To je dovodilo do gubitka podataka jer je indeks potpuno nestajao iz klastera, a poku\u0161aj pisanja u nepostoje\u0107i indeks lomio je logiku curator-a, koji smo koristili za upravljanje. Alias za pisanje pretvarao se u indeks i lomio logiku rollover-a, uzrokuju\u0107i nekontrolirani rast nekih indeksa do 600 GB.\u00a0<\/p>\n

Na primjer, za konfiguraciju rotacije:<\/p>\n

curator-elk-rollover.yaml\n\n---\nactions:\n  1:\n    action: rollover\n    options:\n      name: \"nginx_write\"\n      conditions:\n        max_docs: 100000000\n  2:\n    action: rollover\n    options:\n      name: \"python_error_write\"\n      conditions:\n        max_docs: 10000000\n<\/code><\/pre>\n
U nedostatku rollover aliasa pojavila se gre\u0161ka:<\/p>\n
ERROR     alias \"nginx_write\" not found.\nERROR     Failed to complete action: rollover.  : Unable to perform index rollover with alias \"nginx_write\".\n<\/code><\/pre>\n
Rje\u0161enje ovog problema ostavili smo za sljede\u0107u iteraciju i pre\u0161li na drugo pitanje: primijenili smo pull logiku rada Logstasha, koji se bavi obradom dolaznih logova (uklanjanjem suvi\u0161nih informacija i oboga\u0107ivanjem). Smjestili smo ga u docker, koji pokre\u0107emo putem docker-compose, a tamo smo tako\u0111er postavili logstash-exporter, koji \u0161alje metrike u Prometheus za operativno pra\u0107enje protoka logova. Tako smo si omogu\u0107ili da postepeno mijenjamo broj instanci logstasha, koji su odgovarali za obradu svake vrste logova.<\/p>\n
Dok smo usavr\u0161avali klaster, posje\u0107enost cian.ru porasla je na 12,8 milijuna jedinstvenih korisnika mjese\u010dno. Kao rezultat, na\u0161i procesi transformacije malo su kasnili za promjenama na produkciji, i suo\u010dili smo se s tim da \"topli\" \u010dvorovi nisu izdr\u017eavali optere\u0107enje i usporavali su cijelu isporuku logova. \"Vru\u0107i\" podaci dolazili su bez gre\u0161aka, ali u isporuku ostalih morali smo intervenirati i napraviti ru\u010dni rollover kako bismo ravnomjerno rasporedili indekse.\u00a0<\/p>\n
Pri tome je skaliranje i promjena postavki instanci logstasha u klasteru bila ote\u017eana time \u0161to je to bio lokalni docker-compose, a sve radnje obavljale su se ru\u010dno (za dodavanje novih krajnjih to\u010daka bilo je potrebno ru\u010dno pro\u0107i kroz sve servere i svugdje izvr\u0161iti docker-compose up -d).<\/p>\n
Preusmjeravanje logova<\/h3>\n
\nU rujnu ove godine jo\u0161 uvijek smo nastavljali razdvajati monolit, optere\u0107enje na klasteru je raslo, a protok logova pribli\u017eavao se 30 tisu\u0107a poruka u sekundi.\u00a0<\/p>\n
\"Kako
\n
\nSljede\u0107u iteraciju zapo\u010deli smo s a\u017euriranjem hardvera. Od pet koordinatora pre\u0161li smo na tri, zamijenili smo data-nodove i ostvarili u\u0161tede i u novcu i u volumenu pohrane. Za nodove koristimo dvije konfiguracije:\u00a0<\/p>\n