Dnes náš projekt okrem monolitického kódu zahŕňa desiatky mikroslužieb. Každý z nich musí byť monitorovaný. Robiť to v takom rozsahu pomocou inžinierov DevOps je problematické. Vyvinuli sme monitorovací systém, ktorý funguje ako služba pre vývojárov. Môžu nezávisle zapisovať metriky do monitorovacieho systému, používať ich, zostavovať na nich dashboardy a pripájať k nim upozornenia, ktoré sa spustia pri dosiahnutí prahových hodnôt. Pre inžinierov DevOps iba infraštruktúra a dokumentácia.
Tento príspevok je prepisom môjho prejavu s naším v RIT++. Veľa ľudí nás žiadalo, aby sme odtiaľ spravili textové verzie správ. Ak ste boli na konferencii alebo ste si pozreli video, nič nové nenájdete. A všetci ostatní - vitajte v mačke. Poviem vám, ako sme sa k takémuto systému dostali, ako funguje a ako ho plánujeme aktualizovať.
Minulosť: schémy a plány
Ako sme sa dostali k súčasnému monitorovaciemu systému? Ak chcete odpovedať na túto otázku, musíte ísť do roku 2015. Takto to vtedy vyzeralo:
Mali sme asi 24 uzlov, ktoré boli zodpovedné za monitorovanie. Existuje celý balík rôznych korún, skriptov, démonov, ktorí nejakým spôsobom niečo monitorujú, posielajú správy a vykonávajú funkcie. Mysleli sme si, že čím ďalej, tým menej životaschopný bude takýto systém. Nemá zmysel ho rozvíjať: je príliš ťažkopádny.
Rozhodli sme sa vybrať tie monitorovacie prvky, ktoré si ponecháme a rozvinieme, a tie, od ktorých upustíme. Bolo ich 19. Zostali len grafity, agregátory a Grafana ako palubná doska. Ako však bude nový systém vyzerať? Páči sa ti to:
Máme úložisko metrík: to sú grafity, ktoré budú založené na rýchlych SSD diskoch, to sú určité agregátory metrík. Ďalej - Grafana na zobrazovanie dashboardov a Moira na upozorňovanie. Chceli sme vyvinúť aj systém na vyhľadávanie anomálií.
Štandard: Monitorovanie 2.0
Takto vyzerali plány v roku 2015. Museli sme ale pripraviť nielen infraštruktúru a samotnú službu, ale aj dokumentáciu k nej. Vyvinuli sme pre seba firemný štandard, ktorý nazývame monitoring 2.0. Aké boli požiadavky na systém?
- stála dostupnosť;
- interval ukladania metrík = 10 sekúnd;
- štruktúrované ukladanie metrík a dashboardov;
- SLA > 99,99 %
- zber metrík udalostí cez UDP (!).
Potrebovali sme UDP, pretože máme veľký tok návštevnosti a udalostí, ktoré generujú metriky. Ak ich všetky naraz zapíšete do grafitu, úložisko sa zrúti. Pre všetky metriky sme zvolili aj predpony prvej úrovne.
Každá z predpôn má nejakú vlastnosť. Existujú metriky pre servery, siete, kontajnery, zdroje, aplikácie atď. Bolo implementované jasné, prísne, zadávané filtrovanie, kde akceptujeme metriky prvej úrovne a zvyšok jednoducho vypustíme. Takto sme plánovali tento systém v roku 2015. Čo je v súčasnosti?
Súčasnosť: schéma interakcie komponentov monitorovania
V prvom rade monitorujeme aplikácie: náš PHP kód, aplikácie a mikroslužby – skrátka všetko, čo píšu naši vývojári. Všetky aplikácie posielajú metriky cez UDP do agregátora Brubeck (statsd, prepísané v C). Najrýchlejšie sa ukázalo v syntetických testoch. A posiela už agregované metriky do Graphite cez TCP.
Má typ metrík nazývaných časovače. Toto je veľmi pohodlná vec. Napríklad pri každom pripojení používateľa k službe odošlete Brubeckovi metriku s časom odozvy. Prišlo milión odpovedí, ale agregátor vrátil iba 10 metrík. Máte počet ľudí, ktorí prišli, maximálny, minimálny a priemerný čas odozvy, medián a 4 percentily. Potom sa dáta prenesú do Graphite a my to všetko vidíme naživo.
Máme tiež agregáciu metrík na hardvér, softvér, systémové metriky a náš starý monitorovací systém Munin (fungoval nám do roku 2015). To všetko zbierame cez C démon CollectD (má v sebe zabudovanú celú kopu rôznych pluginov, dokáže sa dotazovať na všetky zdroje hostiteľského systému, na ktorom je nainštalovaný, stačí v konfigurácii určiť, kam sa majú zapisovať dáta) a zapíšte cez ňu údaje do Graphite. Podporuje tiež python pluginy a shell skripty, takže si môžete napísať svoje vlastné riešenia: CollectD zhromaždí tieto dáta z lokálneho alebo vzdialeného hostiteľa (za predpokladu Curl) a pošle ich do Graphite.
Potom pošleme všetky metriky, ktoré sme zhromaždili, do Carbon-c-relay. Toto je riešenie Carbon Relay od spoločnosti Graphite upravené v jazyku C. Ide o smerovač, ktorý zhromažďuje všetky metriky, ktoré posielame z našich agregátorov, a smeruje ich do uzlov. Tiež vo fáze smerovania kontroluje platnosť metrík. Po prvé, musia zodpovedať schéme predpony, ktorú som ukázal skôr, a po druhé, platia pre grafit. Inak spadnú.
Carbon-c-relay potom odošle metriky do grafitového klastra. Ako hlavné úložisko metrík používame Carbon-cache, prepísanú v Go. Go-carbon vďaka svojmu multithreadingu ďaleko prevyšuje Carbon-cache. Prijíma dáta a zapisuje ich na disky pomocou balíka whisper (štandardný, napísaný v pythone). Na čítanie údajov z našich úložísk používame Graphite API. Je oveľa rýchlejší ako štandardný Graphite WEB. Čo sa stane s údajmi ďalej?
Idú do Grafany. Ako hlavný zdroj údajov používame naše grafitové klastre a navyše máme Grafana ako webové rozhranie na zobrazovanie metrík a vytváranie dashboardov. Pre každú zo svojich služieb si vývojári vytvárajú vlastný dashboard. Potom na základe nich zostavujú grafy, ktoré zobrazujú metriky, ktoré píšu zo svojich aplikácií. Okrem Grafany máme aj SLAM. Toto je démon python, ktorý vypočítava SLA na základe údajov z grafitu. Ako som už povedal, máme niekoľko desiatok mikroslužieb, z ktorých každá má svoje požiadavky. Pomocou SLAM prejdeme do dokumentácie a porovnáme ju s tým, čo je v Graphite a porovnáme, ako dobre zodpovedajú požiadavky dostupnosti našich služieb.
Poďme ďalej: varovanie. Organizuje sa pomocou silného systému – Moira. Je nezávislý, pretože má pod kapotou vlastný grafit. Vyvinutý chalanmi z SKB "Kontur", napísaný v pythone a Go, úplne open source. Moira dostáva rovnaký tok ako do grafitov. Ak sa vám z nejakého dôvodu vybije úložisko, vaše upozornenie bude stále fungovať.
Moiru sme nasadili v Kubernetes; ako hlavnú databázu používa klaster serverov Redis. Výsledkom bol systém odolný voči chybám. Porovnáva tok metrík so zoznamom spúšťačov: ak v ňom nie sú žiadne zmienky, metriku vypustí. Je teda schopný stráviť gigabajty metrík za minútu.
K nemu sme pripojili aj firemný LDAP, pomocou ktorého si môže každý používateľ firemného systému vytvárať notifikácie pre seba na základe existujúcich (alebo novovytvorených) spúšťačov. Keďže Moira obsahuje grafit, podporuje všetky jeho funkcie. Takže najprv vezmete riadok a skopírujete ho do Grafany. Pozrite sa, ako sa údaje zobrazujú v grafoch. A potom vezmete ten istý riadok a skopírujete ho do Moiry. Zavesíte to s limitmi a dostanete upozornenie na výstupe. K tomu všetkému nepotrebujete žiadne špecifické znalosti. Moira vie upozorňovať cez SMS, email, Jira, Slack... Podporuje aj vykonávanie vlastných skriptov. Keď sa jej stane spúšťač a ona je prihlásená na odber vlastného skriptu alebo binárneho súboru, spustí ho a odošle JSON na stdin pre tento binárny súbor. Váš program ho teda musí analyzovať. Je len na vás, čo s týmto JSON urobíte. Ak chcete, pošlite to do telegramu, ak chcete, otvorte úlohy v Jira, urobte čokoľvek.
Na upozorňovanie využívame aj vlastný vývoj – Imagotag. Panel, ktorý sa bežne používa na elektronické cenovky v obchodoch, sme prispôsobili našim potrebám. Priniesli sme naň spúšťače od Moiry. Označuje, v akom stave sa nachádzajú a kedy k nim došlo. Niektorí z vývojárov opustili upozornenia v Slacku a e-maily v prospech tohto panela.
No keďže sme progresívna firma, tak sme v tomto systéme sledovali aj Kubernetes. Do systému sme ho zaradili pomocou Heapster, ktorý sme nainštalovali do klastra, zbiera dáta a posiela ich do Graphite. V dôsledku toho vyzerá diagram takto:
Monitorovacie komponenty
Tu je zoznam odkazov na komponenty, ktoré sme použili na túto úlohu. Všetky z nich sú open source.
Grafit:
- go-carbon:
- šepkať:
- grafit-api:
Carbon-C-relé:
Brubeck:
Zhromaždené:
Moira:
Grafana:
Heapster:
štatistika
A tu je niekoľko čísel o tom, ako nám systém funguje.
Agregátor (brubeck)
Počet metrík: ~300 000/s
Interval odosielania metrík do Graphite: 30 sekúnd
Využitie zdrojov servera: ~ 6% CPU (hovoríme o plnohodnotných serveroch); ~ 1 GB RAM; LAN ~ 3 Mbps
Grafit (uhlíkový)
Počet metrík: ~ 1 600 000 / min
Interval aktualizácie metrík: 30 sekúnd
Schéma ukladania metrík: 30 s 35 d, 5 min 90 d, 10 min 365 d (poskytuje vám pochopenie toho, čo sa stane so službou počas dlhého časového obdobia)
Využitie prostriedkov servera: ~10 % CPU; ~ 20 GB RAM; LAN ~ 30 Mbps
flexibilita
My v Avito naozaj oceňujeme flexibilitu našej monitorovacej služby. Prečo vlastne takto dopadol? Po prvé, jeho komponenty sú vzájomne zameniteľné: ako samotné komponenty, tak aj ich verzie. Po druhé, podpora. Keďže celý projekt je open source, môžete kód upravovať sami, vykonávať zmeny a implementovať funkcie, ktoré nie sú dostupné hneď po vybalení. Používajú sa celkom bežné zásobníky, hlavne Go a Python, takže sa to robí celkom jednoducho.
Tu je príklad skutočného problému. Metrika v grafite je súbor. Má to meno. Názov súboru = názov metriky. A existuje spôsob, ako sa tam dostať. Názvy súborov v systéme Linux sú obmedzené na 255 znakov. A máme (ako „interných zákazníkov“) chalanov z databázového oddelenia. Hovoria nám: „Chceme monitorovať naše SQL dotazy. A nemajú 255 znakov, ale každý 8 MB. Chceme ich zobraziť v Grafane, pozrieť si parametre pre túto požiadavku, a ešte lepšie, chceme vidieť vrchol takýchto požiadaviek. Bude skvelé, ak sa zobrazí v reálnom čase. Bolo by naozaj skvelé dať ich do pohotovosti.“
Príklad SQL dotazu je prevzatý ako príklad z
Nastavili sme server Redis a používame naše Collected pluginy, ktoré idú do Postgresu a odtiaľ berú všetky dáta a posielajú metriky do Graphite. Názov metriky však nahrádzame hashmi. Súčasne posielame rovnaký hash do Redis ako kľúč a celý SQL dotaz ako hodnotu. Jediné, čo musíme urobiť, je uistiť sa, že Grafana môže ísť do Redis a vziať si tieto informácie. Otvárame Graphite API, pretože... toto je hlavné rozhranie pre interakciu všetkých monitorovacích komponentov s grafitom a zadáme tam novú funkciu s názvom aliasByHash() - z Grafany dostaneme názov metriky a použijeme ju v požiadavke na Redis ako kľúč, v odpoveď dostaneme hodnotu kľúča, čo je náš „SQL dotaz“ “ V Grafane sme teda zobrazili zobrazenie SQL dotazu, ktorý tam teoreticky nebolo možné zobraziť spolu so štatistikami o ňom (hovory, riadky, celkový_čas, ...).
Výsledky
Dostupnosť. Naša monitorovacia služba je dostupná 24 hodín denne, 7 dní v týždni z akejkoľvek aplikácie a akéhokoľvek kódu. Ak máte prístup k úložným zariadeniam, môžete do služby zapisovať údaje. Jazyk nie je dôležitý, rozhodnutia nie sú dôležité. Musíte len vedieť, ako otvoriť zásuvku, dať tam metriku a zatvoriť zásuvku.
Spoľahlivosť. Všetky komponenty sú odolné voči chybám a dobre zvládajú naše zaťaženie.
Nízka bariéra vstupu. Aby ste mohli používať tento systém, nemusíte sa učiť programovacie jazyky a dotazy v Grafane. Stačí otvoriť vašu aplikáciu, zadať do nej zásuvku, ktorá bude odosielať metriky do Graphite, zavrieť ju, otvoriť Grafana, vytvoriť tam dashboardy a pozrieť sa na správanie vašich metrík, dostávajúcich upozornenia cez Moira.
Nezávislosť. To všetko môžete urobiť sami, bez pomoci inžinierov DevOps. A to je výhoda, pretože svoj projekt môžete sledovať hneď teraz, nemusíte sa nikoho pýtať – či už o začatie práce, alebo o vykonanie zmien.
Na čo sa zameriavame?
Všetko, čo je uvedené nižšie, nie sú len abstraktné myšlienky, ale niečo, k čomu boli podniknuté aspoň prvé kroky.
- Detektor anomálií. Chceme vytvoriť službu, ktorá pôjde do našich grafitových úložísk a bude kontrolovať každú metriku pomocou rôznych algoritmov. Už existujú algoritmy, ktoré chceme zobraziť, existujú údaje, vieme s nimi pracovať.
- Metadáta. Máme veľa služieb, časom sa menia, rovnako ako ľudia, ktorí s nimi pracujú. Neustále manuálne udržiavanie dokumentácie nie je možné. Preto teraz vkladáme metadáta do našich mikroslužieb. Uvádza, kto ho vyvinul, jazyky, s ktorými komunikuje, požiadavky SLA, kam a komu sa majú posielať oznámenia. Pri nasadzovaní služby sa všetky údaje entity vytvárajú nezávisle. V dôsledku toho získate dva odkazy - jeden na spúšťače a druhý na panely v Grafane.
- Monitoring v každej domácnosti. Veríme, že takýto systém by mali používať všetci vývojári. V tomto prípade vždy rozumiete, kde je vaša návštevnosť, čo sa s ňou deje, kam padá, kde sú jej slabé stránky. Ak napríklad niečo príde a zrúti vašu službu, dozviete sa o tom nie počas hovoru od manažéra, ale z upozornenia a môžete okamžite otvoriť najnovšie protokoly a pozrieť sa, čo sa tam stalo.
- Vysoký výkon. Náš projekt neustále rastie a dnes spracováva okolo 2 000 000 metrických hodnôt za minútu. Pred rokom to bolo 500 000. A rast pokračuje, čo znamená, že po určitom čase Graphite (šepot) začne silne zaťažovať diskový subsystém. Ako som už povedal, tento monitorovací systém je pomerne univerzálny vďaka vzájomnej zameniteľnosti komponentov. Niekto udržiava a neustále rozširuje svoju infraštruktúru špeciálne pre Graphite, ale my sme sa rozhodli ísť inou cestou: používať ako úložisko pre naše metriky. Tento prechod je takmer dokončený a čoskoro vám podrobnejšie poviem, ako sa to stalo: aké ťažkosti sa vyskytli a ako boli prekonané, ako prebiehal proces migrácie, opíšem komponenty vybrané ako záväzné a ich konfigurácie.
Ďakujem za tvoju pozornosť! Opýtajte sa na svoje otázky k téme, pokúsim sa odpovedať tu alebo v nasledujúcich príspevkoch. Možno má niekto skúsenosti s budovaním podobného monitorovacieho systému alebo prechodom na Clickhouse v podobnej situácii - podeľte sa o ne v komentároch.
Zdroj: hab.com