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 , prečo sme to napísali a prečo sme opustili brubeck.
Z našich predchádzajúcich článkov (, ) môžete zistiť, že až do určitej doby sme zbierali známky pomocou . Je napísaný v jazyku C. Z hľadiska kódu je jednoduchý ako zástrčka (to je dôležité, keď chcete prispieť) a čo je najdôležitejšie, zvláda naše objemy 2 milióny metrík za sekundu (MPS) v špičkovom bez akýchkoľvek problémov. Dokumentácia uvádza podporu pre 4 milióny MPS s hviezdičkou. To znamená, že uvedený údaj získate, ak si správne nakonfigurujete sieť na Linuxe. (Nevieme, koľko MPS môžete získať, ak ponecháte sieť tak, ako je). Napriek týmto výhodám sme mali na brubeck niekoľko vážnych sťažností.
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 , čo sa môže stať vážnou prekážkou pri zavádzaní nových funkcií.
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ť . Týmto sme vyriešili problém s toleranciou chýb, ale... nie veľmi dobre. Spočiatku sa všetko zdalo skvelé: každý brubeck zbiera svoju vlastnú verziu agregácie, zapisuje údaje do Graphite raz za 30 sekúnd, pričom prepisuje starý interval (to sa robí na grafitovej strane). Ak jeden server náhle zlyhá, vždy máme druhý s vlastnou kópiou agregovaných údajov. Ale tu je problém: ak server zlyhá, na grafoch sa objaví „píla“. Je to spôsobené tým, že brubeckove 30-sekundové intervaly nie sú synchronizované a v momente havárie sa jeden z nich neprepíše. Keď sa spustí druhý server, stane sa to isté. Celkom tolerovateľné, ale chcem lepšie! Problém škálovateľnosti tiež nezmizol. Všetky metriky stále „lietajú“ na jeden server, a preto sme obmedzení na rovnaké 2-4 milióny MPS, v závislosti od úrovne siete.
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 ( k 11.12.2017) sme nenašli absolútne nič. Očividne sa vývojári ani používatelia týchto riešení ešte nestretli s TAKÝMI metrikami, inak by určite niečo vymysleli.
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 , no v budúcnosti siahajú autorove ambície do Raft, kde ten najhodnejší bude, samozrejme, uzol vedúceho konsenzu. Okrem konsenzu uzly pomerne často (štandardne raz za sekundu) posielajú svojim susedom tie časti vopred agregovaných metrík, ktoré sa im podarilo zhromaždiť v danej sekunde. Ukazuje sa, že škálovanie a odolnosť voči chybám sú zachované – každý uzol stále obsahuje celú sadu metrík, ale metriky sú odosielané už agregované, cez TCP a zakódované do binárneho protokolu, takže náklady na duplikáciu sú výrazne znížené v porovnaní s UDP. Napriek pomerne veľkému počtu prichádzajúcich metrík akumulácia vyžaduje veľmi málo pamäte a ešte menej CPU. Pre naše vysoko komprimovateľné mertics je to len niekoľko desiatok megabajtov dát. Ako ďalší bonus nedostávame žiadne zbytočné prepisovanie údajov v grafite, ako to bolo v prípade burbecku.
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 s veľkými nárazníkmi (a nárazníky, páni dôstojníci, nie sú nič pre vás!). Podpora bežného UDP je vyhradená pre ľahké prípady, keď recvmmsg nie je potrebný. V režime multimessage je možné dosiahnuť to hlavné: v drvivej väčšine času sieťové vlákno prehrabuje front OS – číta dáta zo soketu a prenáša ich do vyrovnávacej pamäte používateľského priestoru, len občas prejde na vyplnenie vyplneného buffera. agregátory. Fronta v zásuvke sa prakticky nehromadí, počet zahodených paketov prakticky nerastie.
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