Dnes na našem projektu kromě monolitického kódu fungují desítky mikroslužeb. Každý z nich vyžaduje sledování. Je problematické to udělat v takových objemech inženýry DevOps. Vyvinuli jsme monitorovací systém, který funguje jako služba pro vývojáře. Mohou nezávisle zapisovat metriky do monitorovacího systému, používat je, sestavovat na nich řídicí panely, připojovat k nim výstrahy, které se spustí při dosažení prahových hodnot. S inženýry DevOps – pouze infrastruktura a dokumentace.
Tento příspěvek je přepisem mého projevu z našeho na RIT++. Mnozí nás žádali, abychom odtud vytvořili textové verze zpráv. Pokud jste byli na konferenci nebo sledovali video, nic nového nenajdete. A všem ostatním - vítejte pod kat. Řeknu vám, jak jsme k takovému systému přišli, jak funguje a jak ho plánujeme aktualizovat.
Minulost: schémata a plány
Jak jsme se dostali ke stávajícímu monitorovacímu systému? Chcete-li odpovědět na tuto otázku, musíte jít do roku 2015. Zde je návod, jak to tehdy vypadalo:
Měli jsme asi 24 uzlů, které byly zodpovědné za monitorování. Existuje celá hromada různých cronů, skriptů, démonů, kteří někde něco sledují, posílají zprávy, provádějí funkce. Mysleli jsme si, že čím dále, tím méně bude takový systém životaschopný. Nemá smysl ho rozvíjet: je příliš těžkopádný.
Rozhodli jsme se vybrat ty prvky monitoringu, které opustíme a budeme je rozvíjet, a ty, které opustíme. Bylo jich 19. Zůstaly jen grafity, agregátory a Grafana jako palubní deska. Jak ale bude nový systém vypadat? Takhle:
Máme úložiště metrik: to jsou grafity, které budou založeny na rychlých SSD discích, to jsou určité agregátory pro metriky. Další - Grafana pro zobrazení dashboardů a Moira jako upozornění. Chtěli jsme také vyvinout systém pro vyhledávání anomálií.
Standard: Monitoring 2.0
Tak vypadaly plány v roce 2015. Museli jsme ale připravit nejen infrastrukturu a samotnou službu, ale i dokumentaci k ní. Vyvinuli jsme pro sebe firemní standard, který jsme nazvali monitoring 2.0. Jaké byly požadavky na systém?
- stálá dostupnost;
- metrický interval ukládání = 10 sekund;
- strukturované ukládání metrik a dashboardů;
- SLA > 99,99 %
- sběr metrik událostí přes UDP (!).
Potřebovali jsme UDP, protože máme velký provoz a události, které generují metriky. Pokud jsou všechny napsány v grafitu najednou, úložiště se zhroutí. Pro všechny metriky jsme také zvolili předpony první úrovně.
Každá z předpon má nějakou vlastnost. Existují metriky pro servery, sítě, kontejnery, prostředky, aplikace a tak dále. Bylo implementováno jasné, přísné, zadané filtrování, kde přijímáme metriky první úrovně a zbytek jednoduše vynecháme. Takto jsme tento systém plánovali v roce 2015. Co je v současnosti?
Současnost: schéma interakce monitorovacích komponent
Především sledujeme aplikace: náš PHP kód, aplikace a mikroslužby – jedním slovem vše, co naši vývojáři píší. Všechny aplikace odesílají metriky přes UDP do agregátoru Brubeck (statsd, přepsáno v C). Ukázalo se, že je nejrychlejší podle výsledků syntetických testů. A posílá již agregované metriky do Graphite přes TCP.
Má takový typ metrik jako časovače. To je velmi šikovná věc. Například pro každé připojení uživatele ke službě odešlete Brubeckovi metriku doby odezvy. Přišlo milion odpovědí a agregátor vydal pouze 10 metrik. Máte počet lidí, kteří přišli, maximální, minimální a průměrnou dobu odezvy, medián a 4 percentily. Poté se data přenesou do Graphite a my je všechny vidíme naživo.
Máme také agregaci pro hardware, software, systémové metriky a náš starý monitorovací systém Munin (fungoval u nás do roku 2015). To vše sbíráme přes C'ish daemon CollectD (je v něm zašita celá hromada různých plug-inů, umí se dotazovat na všechny zdroje hostitelského systému, na kterém je nainstalován, stačí v konfiguraci určit, kam se mají zapisovat data ) a zapisovat data přes něj v Graphite. Podporuje také python pluginy a shell skripty, takže si můžete psát svá vlastní řešení: CollectD shromáždí tato data z místního nebo vzdáleného hostitele (za předpokladu, že je Curl dostupný) a odešle je do Graphite.
Dále jsou všechny metriky, které jsme shromáždili, odeslány do Carbon-c-relay. Toto je řešení Carbon Relay od Graphite upravené v C. Jedná se o router, který shromažďuje všechny metriky, které posíláme z našich agregátorů, a směruje je přes uzly. Také ve fázi směrování kontroluje platnost metrik. Za prvé musí odpovídat schématu předpon, které jsem ukázal dříve, a za druhé musí být platné pro grafit. Jinak padají.
Poté Carbon-c-relay odešle metriky do grafitového shluku. Jako hlavní úložiště metrik používáme Carbon-cache přepsanou v Go. Go-carbon je díky svému vícevláknovému zpracování mnohem lepší ve výkonu než Carbon-cache. Vezme data do sebe a zapíše je na disk pomocí balíčku whisper (standardní, napsaný v pythonu). Abychom mohli číst data z našich úložišť, používáme Graphite API. Funguje mnohem rychleji než standardní Graphite WEB. Co se stane s daty dále?
Jdou do Grafany. Jako hlavní zdroj dat používáme naše grafitové clustery a navíc máme Grafanu jako webové rozhraní pro zobrazování metrik, vytváření dashboardů. Pro každou ze svých služeb si vývojáři vytvářejí svůj vlastní dashboard. Poté na základě nich sestavují grafy, které zobrazují metriky, které píší ze svých aplikací. Kromě Grafany máme i SLAM. Toto je pythonic démon, který počítá SLA na základě dat z grafitu. Jak jsem řekl, máme několik desítek mikroslužeb, z nichž každá má své vlastní požadavky. S pomocí SLAMu přejdeme do dokumentace a porovnáme ji s tím, co je v Graphite a porovnáme, jak požadavky odpovídají dostupnosti našich služeb.
Jdeme dále: upozornění. Je organizován silným systémem - Moira. Je nezávislá, protože má pod kapotou svůj vlastní Grafit. Vyvinutý kluky z SKB Kontur, napsaný v pythonu a Go, plně open source. Moira přijímá stejný tok, který jde do grafitů. Pokud z nějakého důvodu vaše úložiště zemře, bude vaše upozornění fungovat.
Nasadili jsme Moiru v Kubernetes, používá cluster serverů Redis jako hlavní databázi. Výsledkem je systém odolný proti chybám. Porovnává tok metrik se seznamem spouštěčů: pokud v něm nejsou žádné zmínky, metriku vypustí. Je tedy schopna strávit gigabajty metrik za minutu.
Přidali jsme k němu i firemní LDAP, s jehož pomocí si může každý uživatel firemního systému vytvářet upozornění na stávající (nebo nově vytvořené) triggery. Protože Moira obsahuje grafit, podporuje všechny jeho funkce. Nejprve tedy vezmete řádek a zkopírujete jej do Grafany. Podívejte se, jak se data zobrazují v grafech. A pak vezmete stejný řádek a zkopírujete ho do Moiry. Zavěste to s limity a získejte upozornění na výstupu. K tomu všemu nepotřebujete žádné specifické znalosti. Moira může upozorňovat přes SMS, e-mail, Jira, Slack… Podporuje také vlastní skripty. Když má spouštěč a je přihlášena k odběru vlastního skriptu nebo binárního souboru, spustí ho a odešle tento binární soubor JSON do stdin. V souladu s tím by jej váš program měl analyzovat. Co s tímto JSON uděláte, je jen na vás. Pokud chcete, pošlete to na Telegram, pokud chcete, otevřete úkoly v Jira, dělejte, co chcete.
K upozorňování využíváme i vlastní vývoj – Imagotag. Panel, který se běžně používá pro elektronické cenovky v obchodech, jsme přizpůsobili našim potřebám. Přinesli jsme tam spouště od Moiry. Označuje, v jakém jsou stavu, kdy k nim došlo. Někteří kluci z vývoje opustili oznámení ve Slacku a v poště ve prospěch tohoto panelu.
No a jelikož jsme progresivní firma, tak jsme v tomto systému sledovali i Kubernetes. Zahrnutý do systému pomocí Heapster, který jsme nainstalovali do clusteru, sbírá data a posílá je do Graphite. V důsledku toho schéma vypadá takto:
Monitorovací komponenty
Zde je seznam odkazů na komponenty, které jsme pro tento úkol použili. Všechny jsou open source.
Grafit:
- go-carbon:
- šepot:
- grafit-api:
Carbon-c-relé:
Brubeck:
Shromážděno:
Moira:
Grafana:
heapster:
Statistika
A zde jsou některá čísla o tom, jak nám systém funguje.
Agregátor (brubeck)
Počet metrik: ~ 300 000/s
Interval odesílání grafitových metrik: 30 sekund
Využití zdrojů serveru: ~ 6 % CPU (mluvíme o plnohodnotných serverech); ~ 1 GB RAM; ~ 3 Mbps LAN
Grafit (uhlíkový)
Počet metrik: ~ 1 600 000 / min
Interval aktualizace metriky: 30 sekund
Schéma ukládání metrik: 30 s 35 d, 5 min 90 d, 10 min 365 d (umožňuje pochopit, co se stane se službou po dlouhou dobu)
Využití prostředků serveru: ~10 % CPU; ~ 20 GB RAM; ~ 30 Mbps LAN
Flexibilita
My ve společnosti Avito opravdu oceňujeme flexibilitu naší monitorovací služby. Proč vlastně takhle dopadl? Za prvé, jeho součásti jsou vzájemně zaměnitelné: jak samotné komponenty, tak jejich verze. Za druhé, udržovatelnost. Vzhledem k tomu, že celý projekt je postaven na open source, můžete kód sami upravovat, provádět změny a implementovat funkce, které nejsou dostupné ihned po vybalení. Používají se celkem běžné zásobníky, hlavně Go a Python, takže se to dělá docela jednoduše.
Zde je příklad skutečného problému. Metrika v Graphite je soubor. Má to jméno. Název souboru = název metriky. A existuje způsob, jak se tam dostat. Názvy souborů v Linuxu jsou omezeny na 255 znaků. A máme (jako „interní zákazníky“) lidi z databázového oddělení. Říkají nám: „Chceme monitorovat naše SQL dotazy. A nemají 255 znaků, ale 8 MB každý. Chceme je zobrazit v Grafaně, vidět parametry pro tento požadavek, a ještě lépe, chceme vidět vrchol takových požadavků. Bude skvělé, když se zobrazí v reálném čase. A bylo by opravdu skvělé je strčit do pohotovosti.“
Příklad dotazu SQL je převzat jako příklad z
Vytváříme server Redis a naše Collected pluginy, které jdou do Postgresu a odtud berou všechna data, posíláme metriky do Graphite. Název metriky ale nahrazujeme hashe. Stejný hash je současně odeslán do Redis jako klíč a celý SQL dotaz jako hodnota. Zůstává na nás, abychom umožnili Grafaně jet do Redis a vzít si tyto informace. Otevíráme Graphite API, protože toto je hlavní rozhraní pro interakci všech monitorovacích komponent s grafitem a zadáme tam novou funkci s názvem aliasByHash () - získáme název metriky z Grafany a použijeme ji v požadavku na Redis jako klíč, v odpověď dostaneme hodnotu klíče, což je náš „SQL dotaz“. Do Grafany jsme tak přinesli zobrazení SQL dotazu, který tam teoreticky nešlo zobrazit spolu se statistikami (volání, řádky, celkový_čas, ...).
Výsledky
Dostupnost. Naše monitorovací služba je dostupná 24/7 z jakékoli aplikace a jakéhokoli kódu. Pokud máte přístup k úložištím, můžete do služby zapisovat data. Jazyk není důležitý, rozhodnutí nejsou důležitá. Potřebujete pouze vědět, jak otevřít socket, hodit tam metriku a zavřít socket.
Spolehlivost. Všechny komponenty jsou odolné proti chybám a dobře zvládají naši pracovní zátěž.
Nízký vstupní práh. Abyste mohli tento systém používat, nemusíte se v Grafaně učit programovací jazyky a dotazy. Stačí otevřít aplikaci, přidat do ní zásuvku, která bude odesílat metriky do Graphite, zavřít ji, otevřít Grafana, vytvořit tam dashboardy a podívat se na chování vašich metrik, přijímat upozornění přes Moira.
Nezávislost. To vše můžete udělat sami, bez pomoci inženýrů DevOps. A to je nadstandardní funkce, protože svůj projekt můžete sledovat hned teď, nemusíte nikoho žádat – ani o zahájení práce, ani o změny.
O co usilujeme?
Vše níže uvedené nejsou jen abstraktní myšlenky, ale něco, k čemu byly učiněny alespoň první kroky.
- detektor anomálií. Chceme vytvořit službu, která půjde do našich úložišť Graphite a bude kontrolovat každou metriku pomocí různých algoritmů. Již existují algoritmy, které chceme zobrazit, existují data, víme, jak s nimi pracovat.
- metadata. Máme mnoho služeb, mění se v čase, stejně jako lidé, kteří s nimi pracují. Ruční vedení záznamů není možné. Metadata jsou proto nyní součástí našich mikroslužeb. Uvádí, kdo jej vyvinul, jazyky, se kterými spolupracuje, požadavky SLA, kam a komu zasílat upozornění. Při nasazení služby jsou všechna data entity vytvořena nezávisle. Ve výsledku získáte dva odkazy – jeden pro spouštěče, druhý pro řídicí panely v Grafaně.
- Monitoring v každé domácnosti. Věříme, že všichni vývojáři by měli takový systém používat. V tomto případě vždy rozumíte, kde je váš provoz, co se s ním děje, kam padá, kde má slabá místa. Pokud například něco přijde a spadne vám služba, pak se o tom dozvíte ne během hovoru od manažera, ale z upozornění a můžete okamžitě otevřít čerstvé protokoly a podívat se, co se tam stalo.
- Vysoký výkon. Náš projekt neustále roste a dnes zpracovává zhruba 2 000 000 metrických hodnot za minutu. Před rokem to bylo 500 000. A růst pokračuje, což znamená, že po nějaké době Graphite (šepot) začne velmi silně zatěžovat diskový subsystém. Jak jsem řekl, tento monitorovací systém je díky zaměnitelnosti komponent poměrně univerzální. Někdo speciálně pro Graphite udržuje a neustále rozšiřuje svou infrastrukturu, ale my jsme se rozhodli jít jinou cestou: používat jako úložiště pro naše metriky. Tento přechod je téměř dokončen a velmi brzy vám řeknu podrobněji, jak to bylo provedeno: jaké byly potíže a jak byly překonány, jak probíhal proces migrace, popíšu komponenty vybrané jako závazné a jejich konfigurace.
Děkuji za pozornost! Ptejte se na své otázky k tématu, pokusím se odpovědět zde nebo v následujících příspěvcích. Možná má někdo zkušenosti s budováním podobného monitorovacího systému nebo přechodem na Clickhouse v podobné situaci - podělte se o ně v komentářích.
Zdroj: www.habr.com