{"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\/ro\/blog\/administrirovanie\/kak-my-v-tsian-ukroshhali-terabajty-logov","title":{"rendered":"Cum am \u00eembl\u00e2nzit teraby\u021bii de loguri la CIAN","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Cum
\n
\nBun\u0103, m\u0103 numesc Alexandru, lucrez la CIAN ca inginer \u0219i m\u0103 ocup de administrarea sistemelor \u0219i automatizarea proceselor infrastructurale. \u00cen comentariile uneia dintre articolele anterioare, am fost ruga\u021bi s\u0103 explic\u0103m de unde ob\u021binem 4 TB de jurnale pe zi \u0219i ce facem cu ele. Da, avem multe jurnale \u0219i pentru procesarea lor am creat un cluster infrastructural separat, care ne permite s\u0103 rezolv\u0103m rapid problemele. \u00cen acest articol voi povesti despre cum am adaptat acest sistem pe parcursul unui an pentru a lucra cu fluxul de date \u00een continu\u0103 cre\u0219tere.
\n<\/a><\/noindex><\/p>\n

De unde am \u00eenceput<\/h3>\n

\n\"Cum
\n
\n\u00cen ultimii c\u00e2\u021biva ani, sarcina pe cian.ru a crescut foarte rapid \u0219i, p\u00e2n\u0103 \u00een trimestrul trei din 2018, num\u0103rul de vizitatori unici a atins 11,2 milioane pe lun\u0103. La acea vreme, \u00een momente critice, pierdeam p\u00e2n\u0103 la 40% din jurnale, ceea ce ne \u00eengreuna s\u0103 analiz\u0103m rapid incidentele \u0219i cheltuiam foarte mult timp \u0219i efort pentru a le rezolva. De asemenea, adesea nu reu\u0219eam s\u0103 g\u0103sim cauza problemelor, iar acestea se repetau dup\u0103 o vreme. Era un co\u0219mar, ceva trebuia s\u0103 facem.<\/p>\n

\u00cen acel moment, pentru stocarea jurnalelor, foloseam un cluster format din 10 noduri de date cu ElasticSearch versiunea 5.5.2 \u0219i set\u0103ri standard pentru indec\u0219i. Acesta a fost implementat cu mai bine de un an \u00een urm\u0103 ca o solu\u021bie popular\u0103 \u0219i accesibil\u0103: atunci fluxul de jurnale nu era foarte mare, nu avea rost s\u0103 venim cu configura\u021bii non-standard.\u00a0<\/p>\n

Procesarea jurnalelor de intrare era asigurat\u0103 de Logstash pe diverse porturi pe cinci coordonatori ElasticSearch. Un index, indiferent de dimensiune, const\u0103 din cinci \u0219arduri. A fost organizat\u0103 o rota\u021bie orar\u0103 \u0219i zilnic\u0103; astfel, \u00een fiecare or\u0103, \u00een cluster ap\u0103reau aproximativ 100 de \u0219arduri noi. At\u00e2ta timp c\u00e2t num\u0103rul jurnalelor nu era foarte mare, clusterul f\u0103cea fa\u021b\u0103, iar nimeni nu punea accent pe set\u0103rile sale.\u00a0<\/p>\n

Problemele cre\u0219terii rapide<\/h3>\n

\nVolumul jurnalelor generate a crescut foarte rapid, deoarece s-au suprapus dou\u0103 procese. Pe de o parte, num\u0103rul utilizatorilor serviciului cre\u0219tea constant. Pe de alt\u0103 parte, am \u00eenceput s\u0103 trecem activ la o arhitectur\u0103 bazat\u0103 pe microservicii, diviz\u00e2nd vechile noastre monolith-uri scrise \u00een C# \u0219i Python. C\u00e2teva zeci de microservicii noi, care \u00eenlocuiau p\u0103r\u021bi ale monolith-ului, generau cu mult mai multe jurnale pentru clusterul infrastructural.\u00a0<\/p>\n

Scalarea a dus la faptul c\u0103 clusterul a devenit practic incontrolabil. C\u00e2nd logurile au \u00eenceput s\u0103 soseasc\u0103 cu o vitez\u0103 de 20.000 de mesaje pe secund\u0103, rota\u021bia frecvent\u0103 nefolositoare a crescut num\u0103rul de shard-uri p\u00e2n\u0103 la 6.000, iar pe un nod erau mai mult de 600 de shard-uri.\u00a0<\/p>\n

Aceasta a dus la probleme cu alocarea memoriei, iar c\u00e2nd un nod c\u0103dea, toate shard-urile \u00eencepeau s\u0103 migreze simultan, multiplic\u00e2nd traficul \u0219i \u00eenc\u0103rc\u00e2nd celelalte noduri, ceea ce f\u0103cea practic imposibil\u0103 scrierea de date \u00een cluster. \u00cen aceast\u0103 perioad\u0103, am r\u0103mas f\u0103r\u0103 loguri. Iar \u00een cazul unei probleme cu serverul<\/a> pierdeam 1\/10 din cluster \u00een principiu. Cantitatea mare de indec\u0219i mici a ad\u0103ugat complexitate.<\/p>\n

F\u0103r\u0103 loguri, nu \u00een\u021belegeam cauzele incidentului \u0219i riscam s\u0103 c\u0103lc\u0103m pe acelea\u0219i greble din nou, iar \u00een ideologia echipei noastre aceasta era inacceptabil, deoarece toate mecanismele noastre de lucru erau concepute exact pentru opus - s\u0103 nu repet\u0103m acelea\u0219i probleme. A\u0219adar, aveam nevoie de un volum complet de loguri \u0219i de livrarea lor aproape \u00een timp real, deoarece echipa de ingineri de gard\u0103 monitoriza alertele nu doar din metrici, ci \u0219i din loguri. Pentru a \u00een\u021belege amploarea problemei - la acea vreme, volumul total de loguri era de aproximativ 2 TB pe zi.\u00a0<\/p>\n

Am stabilit obiectivul - s\u0103 excluzem complet pierderea logurilor \u0219i s\u0103 reducem timpul de livrare \u00een clusterul ELK la maximum 15 minute \u00een timpul urgen\u021belor (aceast\u0103 cifr\u0103 a devenit ulterior KPI intern).<\/p>\n

Mecanism nou de rota\u021bie \u0219i noduri hot-warm<\/h3>\n

\n\"Cum
\n
\nTransformarea cluster-ului a \u00eenceput cu actualizarea versiunii ElasticSearch de la 5.5.2 la 6.4.3. Cluster-ul nostru de versiune 5 s-a pr\u0103bu\u0219it din nou, iar noi am decis s\u0103-l \u00eenchidem \u0219i s\u0103-l actualiz\u0103m complet - oricum nu aveam loguri. A\u0219a c\u0103 aceast\u0103 tranzi\u021bie am realizat-o \u00een doar c\u00e2teva ore.<\/p>\n

Cea mai ampl\u0103 transformare \u00een acest stadiu a fost implementarea pe trei noduri cu un coordonator ca buffer intermediar pentru Apache Kafka. Brokerul de mesaje ne-a sc\u0103pat de pierderile de loguri \u00een timpul problemelor cu ElasticSearch. \u00cen acela\u0219i timp, am ad\u0103ugat \u00een cluster 2 noduri \u0219i am trecut la arhitectura hot-warm cu trei noduri \u201ec\u0103ldu\u021be\u201d, plasate \u00een rack-uri diferite din data center. Pe acestea am redirec\u021bionat logurile care nu trebuiau pierdute sub nicio form\u0103 \u2014 nginx, precum \u0219i logurile de erori ale aplica\u021biilor. Pe celelalte noduri se trimiteau loguri minore \u2014 debug, warning etc., iar dup\u0103 24 de ore migr\u0103m logurile \u201eimportante\u201d de pe nodurile \u201ec\u0103ldu\u021be\u201d.<\/p>\n

Pentru a nu cre\u0219te num\u0103rul de indec\u0219i de dimensiuni mici, am trecut de la rota\u021bia pe timp la mecanismul rollover. Pe forumuri erau multe informa\u021bii despre faptul c\u0103 rota\u021bia pe dimensiunea indexului este foarte nesigur\u0103, a\u0219a c\u0103 am decis s\u0103 folosim rota\u021bia pe num\u0103rul de documente din index. Am analizat fiecare index \u0219i am fixat num\u0103rul de documente dup\u0103 care ar trebui s\u0103 se declan\u0219eze rota\u021bia. Astfel, am ob\u021binut o dimensiune optim\u0103 a shardului \u2014 nu mai mult de 50 GB.\u00a0<\/p>\n

Optimizarea clusterului<\/h3>\n

\n\"Cum
\n
\nCu toate acestea, nu ne-am eliberat complet de probleme. Din p\u0103cate, ap\u0103reau totu\u0219i indec\u0219i mici: ace\u0219tia nu atingeau volumul stabilit, nu erau rota\u021bi \u0219i erau elimina\u021bi printr-o cur\u0103\u021bare global\u0103 a indec\u0219ilor mai vechi de trei zile, av\u00e2nd \u00een vedere c\u0103 am eliminat rota\u021bia pe dat\u0103. Aceasta ducea la pierderi de date deoarece indexul dispare complet din cluster, iar \u00eencercarea de a scrie \u00eentr-un index inexistent deteriora logica curator-ului pe care \u00eel foloseam pentru gestionare. Alias-ul pentru scriere se transforma \u00een index \u0219i strica logica rollover-ului, provoc\u00e2nd o cre\u0219tere necontrolat\u0103 a unor indec\u0219i p\u00e2n\u0103 la 600 GB.\u00a0<\/p>\n

De exemplu, pentru configura\u021bia de rota\u021bie:<\/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
\u00cen absen\u021ba alias-ului rollover ap\u0103rea o eroare:<\/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
Am l\u0103sat solu\u021bionarea acestei probleme pentru urm\u0103toarea itera\u021bie \u0219i ne-am ocupat de o alt\u0103 \u00eentrebare: am trecut la logica de lucru pull a Logstash, care se ocup\u0103 cu procesarea jurnalelor de intrare (eliminarea informa\u021biilor inutile \u0219i \u00eembog\u0103\u021birea acestora). L-am plasat \u00een Docker, pe care \u00eel lans\u0103m prin docker-compose, unde am plasat \u0219i logstash-exporter, care ofer\u0103 metrici \u00een Prometheus pentru monitorizarea \u00een timp real a fluxului de jurnale. Astfel, ne-am dat posibilitatea de a schimba \u00een mod fluid num\u0103rul de instan\u021be Logstash responsabile pentru procesarea fiec\u0103rui tip de jurnale.<\/p>\n
\u00cen timp ce ne perfectionam clusterul, traffic-ul pe cian.ru a crescut la 12,8 milioane de utilizatori unici pe lun\u0103. Ca rezultat, s-a \u00eent\u00e2mplat c\u0103 transform\u0103rile noastre nu \u021bineau pasul cu modific\u0103rile din produc\u021bie, \u0219i ne-am confruntat cu faptul c\u0103 nodurile \"c\u0103ldu\u021be\" nu f\u0103ceau fa\u021b\u0103 sarcinilor \u0219i \u00eempiedicau livrarea \u00eentregii jurnale. Datele \"fierbin\u021bi\" le-am ob\u021binut f\u0103r\u0103 probleme, dar pentru livrarea celorlalte a fost nevoie s\u0103 intervenim manual \u0219i s\u0103 facem rollover manual, pentru a distribui uniform indexii.\u00a0<\/p>\n
\u00cen acela\u0219i timp, scalarea \u0219i modificarea set\u0103rilor instan\u021belor Logstash din cluster a fost complicat\u0103 de faptul c\u0103 acesta era un docker-compose local, iar toate ac\u021biunile se efectau manual (pentru a ad\u0103uga noi capete, era necesar s\u0103 trecem manual prin toate serverele \u0219i s\u0103 execut\u0103m docker-compose up -d peste tot).<\/p>\n
Redistribuirea jurnalele<\/h3>\n
\n\u00cen septembrie acestui an, am continuat s\u0103 desp\u0103r\u021bim monolitul, sarcina pe cluster cre\u0219tea, iar fluxul de jurnale se apropia de 30 de mii de mesaje pe secund\u0103.\u00a0<\/p>\n
\"Cum
\n
\nUrm\u0103toarea itera\u021bie am \u00eenceput-o prin actualizarea echipamentului. De la cinci coordonatori am trecut la trei, am \u00eenlocuit nodurile de date \u0219i am c\u00e2\u0219tigat at\u00e2t la bani, c\u00e2t \u0219i la capacitatea de stocare. Pentru noduri folosim dou\u0103 configura\u021bii:\u00a0<\/p>\n