{"id":52113,"date":"2019-11-01T00:00:00","date_gmt":"2019-10-31T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik"},"modified":"2020-02-18T13:59:47","modified_gmt":"2020-02-18T10:59:47","slug":"bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","status":"publish","type":"post","link":"https:\/\/prohoster.info\/ro\/blog\/administrirovanie\/bioyino-raspredelyonnyj-masshtabiruemyj-agregator-metrik","title":{"rendered":"Bioyino \u2014 un agregator distribuit \u0219i scalabil de metrici","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A\u0219adar, aduna\u021bi metrici. Ca \u0219i noi. De asemenea, adun\u0103m metrici. Bine\u00een\u021beles, cele necesare pentru afaceri. Ast\u0103zi v\u0103 vom vorbi despre primul link din sistemul nostru de monitorizare \u2014 un server de agregare compatibil cu statsd bioyino<\/a><\/noindex>, de ce l-am scris \u0219i de ce am renun\u021bat la brubeck. <\/p>\n

<\/p>\n

\"Bioyino<\/p>\n

<\/a><\/noindex><\/p>\n

Din articolele noastre anterioare (1<\/a><\/noindex>, 2<\/a><\/noindex>) pute\u021bi afla c\u0103, p\u00e2n\u0103 \u00eentr-un anumit moment, am adunat etichete folosind brubeck<\/a><\/noindex>. Este scris \u00een C. Din punctul de vedere al codului \u2014 simplu ca o dop, ceea ce este important atunci c\u00e2nd dori\u021bi s\u0103 contribui\u021bi \u0219i, cel mai important, face fa\u021b\u0103 f\u0103r\u0103 probleme volumului nostru de 2 milioane de metrici pe secund\u0103 (MPS) \u00een v\u00e2rf. Documenta\u021bia afirm\u0103 suport pentru 4 milioane MPS cu o stea. Aceasta \u00eenseamn\u0103 c\u0103 cifra declarat\u0103 o ve\u021bi ob\u021bine dac\u0103 configura\u021bi corect re\u021beaua pe Linux. (C\u00e2te MPS se pot ob\u021bine l\u0103s\u00e2nd re\u021beaua a\u0219a cum este, nu \u0219tim). \u00cen ciuda acestor avantaje, aveam c\u00e2teva pl\u00e2ngeri serioase fa\u021b\u0103 de brubeck.<\/p>\n

<\/p>\n

Pl\u00e2ngerea 1.<\/em> Github \u2014 dezvoltatorul proiectului \u2014 a \u00eencetat s\u0103-l mai sus\u021bin\u0103: nu public\u0103 patch-uri \u0219i corecturi, nu accept\u0103 PR-urile noastre (\u0219i nu doar ale noastre). \u00cen ultimele c\u00e2teva luni (undeva din februarie-martie 2018) activitatea a re\u00eenceput, dar \u00eenainte de acest moment a fost aproape 2 ani de lini\u0219te total\u0103. \u00cen plus, proiectul este dezvoltat pentru nevoile interne ale Gihub<\/a><\/noindex>, ceea ce poate deveni un obstacol serios \u00een implementarea de noi func\u021bionalit\u0103\u021bi.<\/p>\n

<\/p>\n

Pl\u00e2ngerea 2.<\/em> Precizia calculelor. Brubeck colecteaz\u0103 pentru agregare doar 65536 de valori. \u00cen cazul nostru, pentru anumite metrici \u00een perioada de agregare (30 secunde) pot veni mult mai multe valori (1.527.392 \u00een v\u00e2rf). Ca urmare a acestui e\u0219antion, valorile maximelor \u0219i minimelor par inutile. De exemplu, astfel: <\/p>\n

<\/p>\n

\"Bioyino
\nCum a fost<\/em><\/p>\n

<\/p>\n

\"Bioyino
\nCum ar fi trebuit s\u0103 fie<\/em><\/p>\n

<\/p>\n

Din acela\u0219i motiv, sumele sunt calculate gre\u0219it. Ad\u0103uga\u021bi aici un bug cu dep\u0103\u0219irea valorii float pe 32 de bi\u021bi, care trimite serverul \u00een segfault la primirea unei metrici aparent inofensive, \u0219i devine cu adev\u0103rat excelent. Bug-ul, de altfel, nu a fost corectat.<\/p>\n

<\/p>\n

\u0218i, \u00een sf\u00e2r\u0219it, Pl\u00e2ngerea X<\/em>. La momentul scrierii acestui articol, suntem preg\u0103ti\u021bi s\u0103-l prezent\u0103m tuturor celor 14 implement\u0103ri mai mult sau mai pu\u021bin func\u021bionale ale statsd, pe care am reu\u0219it s\u0103 le g\u0103sim. S\u0103 presupunem c\u0103 o anumit\u0103 infrastructur\u0103 a crescut at\u00e2t de mult \u00eenc\u00e2t a primi 4 milioane MPS nu mai este suficient. Sau poate c\u0103 nu a crescut \u00eenc\u0103, dar metricele pentru dvs. sunt deja at\u00e2t de importante \u00eenc\u00e2t chiar \u0219i scurtcircuit\u0103rile de 2-3 minute pe grafice pot deveni critice \u0219i pot provoca episoade de depresie profund\u0103 \u00een r\u00e2ndul managerilor. Deoarece tratamentul depresiei este o sarcin\u0103 dificil\u0103, sunt necesare solu\u021bii tehnice.<\/p>\n

<\/p>\n

\u00cen primul r\u00e2nd, fiabilitate, astfel \u00eenc\u00e2t o problem\u0103 nea\u0219teptat\u0103 pe server s\u0103 nu provoace un apocalips\u0103 psihiatric\u0103 \u00een birou. \u00cen al doilea r\u00e2nd, scalabilitate, pentru a avea capacitatea de a primi mai mult de 4 milioane MPS, f\u0103r\u0103 a s\u0103pa ad\u00e2nc \u00een stiva de re\u021bea Linux \u0219i cresc\u00e2nd \u201e\u00een l\u0103\u021bime\u201d p\u00e2n\u0103 la dimensiunile necesare.<\/p>\n

<\/p>\n

Av\u00e2nd \u00een vedere c\u0103 aveam o rezerv\u0103 pentru scalabilitate, am decis s\u0103 \u00eencepem cu fiabilitatea. \u201eO! Fiabilitate! Este simplu, \u0219tim cum s\u0103 facem asta\u201d, ne-am g\u00e2ndit \u0219i am pornit 2 servere, ridic\u00e2nd pe fiecare o copie a brubeck. Pentru aceasta, a fost necesar s\u0103 copiem traficul cu metrice pe ambele servere \u0219i chiar s\u0103 scriem pentru asta o mic\u0103 unealt\u0103<\/a><\/noindex>. Am rezolvat problema fiabilit\u0103\u021bii cu aceasta, dar\u2026 nu foarte bine. La \u00eenceput, totul p\u0103rea grozav: fiecare brubeck adun\u0103 propria variant\u0103 de agregare, scrie date \u00een Graphite la fiecare 30 de secunde, supra\u00eenregistr\u00e2nd intervalul anterior (acest lucru se face pe partea Graphite). Dac\u0103, dintr-o dat\u0103, un server se defecteaz\u0103, avem \u00eentotdeauna un al doilea cu propria copie de date agregate. Dar problema este: dac\u0103 serverul se defecteaz\u0103, pe grafice apare un \u201edinte de fer\u0103str\u0103u\u201d. Acest lucru este legat de faptul c\u0103 intervalele de 30 de secunde la brubeck nu sunt sincronizate, iar \u00een momentul pic\u0103rii, unul dintre ele nu se supra\u00eenregistreaz\u0103. Atunci c\u00e2nd se porneste al doilea server, se \u00eent\u00e2mpl\u0103 acela\u0219i lucru. Este destul de tolerabil, dar vrem mai bine! Problema scalabilit\u0103\u021bii nu a disp\u0103rut nici ea. Toate metricele continu\u0103 s\u0103 \u201ezboare\u201d c\u0103tre un server singular, a\u0219a c\u0103 suntem restric\u021biona\u021bi de acelea\u0219i 2-4 milioane MPS, \u00een func\u021bie de capacitatea re\u021belei.<\/p>\n

<\/p>\n

Dac\u0103 te g\u00e2nde\u0219ti pu\u021bin la problem\u0103 \u0219i sapi z\u0103pada \u00een acela\u0219i timp, poate s\u0103-\u021bi vin\u0103 o idee evident\u0103: este nevoie de un statsd care s\u0103 func\u021bioneze \u00een mod distribuit. Adic\u0103 un statsd care s\u0103 implementeze sincronizarea \u00eentre noduri pe baza timpului \u0219i a metodelor de m\u0103surare. \u201eDesigur, o astfel de solu\u021bie cu siguran\u021b\u0103 exist\u0103 deja\u201d, ne-am spus \u0219i am \u00eenceput s\u0103 c\u0103ut\u0103m pe Google... \u0219i nu am g\u0103sit nimic. Trec\u00e2nd prin documenta\u021bia diferitelor statsd (https:\/\/github.com\/etsy\/statsd\/wiki#server-implementations<\/a><\/noindex> la data de 11.12.2017), nu am g\u0103sit nimic. Se pare c\u0103 nici dezvoltatorii, nici utilizatorii acestor solu\u021bii cu un ASEMENEA num\u0103r de metode de m\u0103surare nu s-au confruntat \u00eenc\u0103 cu aceast\u0103 problem\u0103, altfel cu siguran\u021b\u0103 ar fi inventat ceva.<\/p>\n

<\/p>\n

\u0218i atunci ne-am amintit de statsd-ul \u201ejuc\u0103rie\u201d \u2014 bioyino, pe care l-am scris la hackathon doar pentru distrac\u021bie (numele proiectului a fost generat de un script \u00eenainte de \u00eenceperea hackathon-ului) \u0219i am realizat c\u0103 avem nevoie urgent\u0103 de propriul nostru statsd. De ce?<\/p>\n

<\/p>\n