Takže zbierate metriky. Akí sme my. Zhromažďujeme aj metriky. Samozrejme, nevyhnutné pre podnikanie. Dnes si povieme o úplne prvom prepojení nášho monitorovacieho systému – agregačnom serveri kompatibilnom so statsd
Z našich predchádzajúcich článkov (
Nárok 1. Github, vývojár projektu, ho prestal podporovať: zverejňovať záplaty a opravy, akceptovať naše a (nielen naše) PR. V posledných mesiacoch (niekde od februára-marca 2018) sa činnosť obnovila, no predtým bol takmer 2 roky úplný kľud. Okrem toho sa projekt pripravuje
Nárok 2. Presnosť výpočtov. Brubeck zhromažďuje celkovo 65536 hodnôt pre agregáciu. V našom prípade pre niektoré metriky môže počas obdobia agregácie (30 sekúnd) prísť oveľa viac hodnôt (1 527 392 na vrchole). V dôsledku tohto vzorkovania sa maximálne a minimálne hodnoty javia ako zbytočné. Napríklad takto:
Ako to bolo
Ako to malo byť
Z rovnakého dôvodu sú sumy vo všeobecnosti vypočítané nesprávne. Pridajte sem chybu s 32-bitovým float overflow, ktorá vo všeobecnosti pošle server do segfaultu, keď dostane zdanlivo nevinnú metriku, a všetko bude skvelé. Chyba, mimochodom, nebola opravená.
A konečne, Nárok X. V čase písania tohto článku sme pripravení ho predstaviť všetkým 14 viac či menej funkčným implementáciám statsd, ktoré sa nám podarilo nájsť. Predstavme si, že nejaká jednotná infraštruktúra sa rozrástla natoľko, že akceptovať 4 milióny MPS už nestačí. Alebo aj keď ešte nenarástla, ale metriky sú pre vás už také dôležité, že aj krátke, 2-3-minútové poklesy v grafoch sa už môžu stať kritickými a spôsobiť záchvaty neprekonateľnej depresie medzi manažérmi. Keďže liečba depresie je nevďačná úloha, sú potrebné technické riešenia.
Po prvé, odolnosť voči chybám, aby náhly problém na serveri nespôsobil v kancelárii psychiatrickú zombie apokalypsu. Po druhé, škálovanie tak, aby bolo možné akceptovať viac ako 4 milióny MPS, bez toho, aby ste sa hlboko zahrabávali do sieťového zásobníka Linuxu a pokojne rástli „do šírky“ na požadovanú veľkosť.
Keďže sme mali priestor na škálovanie, rozhodli sme sa začať s odolnosťou voči chybám. „O! Odolnosť proti chybám! Je to jednoduché, dokážeme to,“ pomysleli sme si a spustili sme 2 servery, pričom na každom sme vyzdvihli kópiu brubecku. Aby sme to dosiahli, museli sme skopírovať návštevnosť s metrikami na oba servery a dokonca na to písať
Ak sa nad problémom trochu zamyslíte a zároveň vyhrabete sneh lopatou, potom vám môže napadnúť nasledujúca zrejmá myšlienka: potrebujete statsd, ktorý dokáže pracovať v distribuovanom režime. Teda taký, ktorý implementuje synchronizáciu medzi uzlami v čase a metrikách. „Samozrejme, takéto riešenie už pravdepodobne existuje,“ povedali sme a šli do Googlu…. A nenašli nič. Po prečítaní dokumentácie pre rôzne štatistiky (
A potom sme si spomenuli na „hračku“ statsd - bioyino, ktorá bola napísaná na hackathone Just for Fun (názov projektu vygeneroval skript pred začiatkom hackathonu) a uvedomili sme si, že naliehavo potrebujeme vlastný statsd. Prečo?
- pretože na svete je príliš málo statsd klonov,
- pretože je možné poskytnúť požadovanú alebo takmer požadovanú odolnosť voči chybám a škálovateľnosť (vrátane synchronizácie agregovaných metrík medzi servermi a riešenia problému odosielania konfliktov),
- pretože je možné vypočítať metriky presnejšie ako brubeck,
- pretože podrobnejšie štatistiky si môžete zozbierať sami, ktoré nám brubeck prakticky neposkytol,
- pretože som mal možnosť naprogramovať si vlastnú hypervýkonnú laboratórnu aplikáciu v distribuovanom meradle, ktorá nebude úplne opakovať architektúru iného podobného hyperforu... no, to je všetko.
Na čo písať? Samozrejme, v Ruste. prečo?
- pretože už existovalo prototypové riešenie,
- pretože autor článku už vtedy Rust poznal a mal chuť do neho niečo napísať do produkcie s možnosťou dať to do open-source,
- pretože jazyky s GC nie sú pre nás vhodné kvôli povahe prijímanej prevádzky (takmer v reálnom čase) a GC pauzy sú prakticky neprijateľné,
- pretože potrebujete maximálny výkon porovnateľný s C
- pretože Rust nám poskytuje nebojácnu súbežnosť a ak by sme ho začali písať v C/C++, dostali by sme ešte viac zraniteľností, pretečení vyrovnávacej pamäte, rasových podmienok a iných strašidelných slov ako brubeck.
Objavil sa aj argument proti Rustovi. Spoločnosť nemala žiadne skúsenosti s vytváraním projektov v Ruste a teraz ich tiež neplánujeme použiť v hlavnom projekte. Preto boli vážne obavy, že nič nevyjde, no rozhodli sme sa riskovať a skúsili sme to.
Čas uplynul...
Konečne po niekoľkých neúspešných pokusoch bola hotová prvá pracovná verzia. Čo sa stalo? Toto sa stalo.
Každý uzol prijíma svoju vlastnú množinu metrík a zhromažďuje ich a neagreguje metriky pre tie typy, kde je na konečnú agregáciu potrebný ich úplný súbor. Uzly sú navzájom prepojené akýmsi distribuovaným zámkovým protokolom, ktorý vám umožňuje vybrať medzi nimi ten jediný (tu sme si poplakali), ktorý je hodný odoslania metrík Veľkému. Tento problém momentálne rieši
Pakety UDP s metrikami sú nevyvážené medzi uzlami na sieťových zariadeniach prostredníctvom jednoduchého Round Robin. Sieťový hardvér samozrejme neanalyzuje obsah paketov, a preto môže ťahať oveľa viac ako 4 milióny paketov za sekundu, nehovoriac o metrikách, o ktorých nevie vôbec nič. Ak vezmeme do úvahy, že metriky neprichádzajú po jednom v každom pakete, potom na tomto mieste nepredpokladáme žiadne problémy s výkonom. Ak dôjde k zlyhaniu servera, sieťové zariadenie rýchlo (do 1-2 sekúnd) túto skutočnosť zistí a vyradí havarovaný server z rotácie. Výsledkom je, že pasívne (t. j. nevodiace) uzly možno zapínať a vypínať prakticky bez toho, aby ste si všimli poklesy na grafoch. Maximum, čo stratíme, je súčasťou metrík, ktoré prišli v poslednej sekunde. Náhla strata/vypnutie/prepnutie lídra stále vytvorí menšiu anomáliu (30 sekundový interval je stále nesynchronizovaný), ale ak existuje komunikácia medzi uzlami, tieto problémy sa dajú minimalizovať, napríklad rozoslaním synchronizačných paketov .
Trochu o vnútornej štruktúre. Aplikácia je, samozrejme, viacvláknová, ale architektúra vlákien je odlišná od tej, ktorá sa používa v brubecku. Vlákna v brubecku sú rovnaké - každé z nich je zodpovedné za zber aj agregáciu informácií. V bioyino sú pracovníci rozdelení do dvoch skupín: tí zodpovední za sieť a tí, ktorí sú zodpovední za agregáciu. Toto rozdelenie umožňuje flexibilnejšie spravovať aplikáciu v závislosti od typu metrík: tam, kde je potrebná intenzívna agregácia, môžete pridať agregátory, kde je veľká sieťová prevádzka, môžete pridať počet sieťových tokov. V súčasnosti na našich serveroch pracujeme v 8 sieťových a 4 agregačných tokoch.
Počítacia (zodpovedná za agregáciu) časť je dosť nudná. Buffery naplnené sieťovými tokmi sú rozdelené medzi počítacie toky, kde sú následne analyzované a agregované. Na požiadanie sú uvedené metriky na odoslanie do iných uzlov. Toto všetko, vrátane posielania dát medzi uzlami a práce s Consul, prebieha asynchrónne, beží na frameworku
Oveľa viac problémov pri vývoji spôsobila sieťová časť zodpovedná za príjem metrík. Hlavným cieľom oddelenia sieťových tokov do samostatných entít bola túžba skrátiť čas, ktorý tok strávi nie na čítanie údajov zo zásuvky. Možnosti využívajúce asynchrónny UDP a pravidelný recvmsg rýchlo zmizli: prvá spotrebováva príliš veľa užívateľského priestoru CPU na spracovanie udalostí, druhá vyžaduje príliš veľa kontextových prepínačov. Preto sa teraz používa
Poznámka
V predvolenom nastavení je veľkosť vyrovnávacej pamäte nastavená na dosť veľkú. Ak sa zrazu rozhodnete server vyskúšať sami, môžete sa stretnúť s tým, že po odoslaní malého počtu metrík nedorazia do grafitu a zostanú vo vyrovnávacej pamäti sieťového streamu. Ak chcete pracovať s malým počtom metrík, musíte v konfigurácii nastaviť veľkosť bufsize a task-queue-size na menšie hodnoty.
Na záver pár grafov pre milovníkov grafov.
Štatistiky o počte prichádzajúcich metrík pre každý server: viac ako 2 milióny MPS.
Zakázanie jedného z uzlov a prerozdelenie prichádzajúcich metrík.
Štatistiky o odchádzajúcich metrikách: vždy posiela len jeden uzol – raid boss.
Štatistika prevádzky každého uzla, berúc do úvahy chyby v rôznych moduloch systému.
Podrobnosti o prichádzajúcich metrikách (názvy metrík sú skryté).
Čo s tým všetkým plánujeme ďalej robiť? Samozrejme, píšte kód, sakra...! Projekt bol pôvodne plánovaný ako open-source a zostane ním počas celej životnosti. Naše bezprostredné plány zahŕňajú prechod na vlastnú verziu Raftu, zmenu partnerského protokolu na prenosnejší, zavedenie dodatočných interných štatistík, nové typy metrík, opravy chýb a ďalšie vylepšenia.
Samozrejme, každý je vítaný pomôcť pri vývoji projektu: vytvorte PR, Issues, ak je to možné, odpovieme, zlepšíme atď.
Keď už bolo povedané, to je všetko, ľudia, kúpte si naše slony!
Zdroj: hab.com