Jmenuji se Anton Baderin. Pracuji v High Technology Center a dělám správu systému. Před měsícem skončila naše firemní konference, kde jsme sdíleli naše nasbírané zkušenosti s IT komunitou našeho města. Mluvil jsem o monitorování webových aplikací. Materiál byl určen pro juniory nebo střední úrovně, kteří tento proces nestavěli od nuly.
Základním kamenem každého monitorovacího systému je řešení obchodních problémů. Monitorování kvůli monitorování nikoho nezajímá. Co chce podnikání? Aby vše fungovalo rychle a bez chyb. Firmy chtějí být proaktivní, abychom sami identifikovali problémy ve službě a co nejrychleji je opravili. To jsou vlastně problémy, které jsem celý minulý rok řešil na projektu pro jednoho z našich zákazníků.
O projektu
Projekt je jedním z největších věrnostních programů v zemi. Obchodním řetězcům pomáháme zvyšovat frekvenci prodejů prostřednictvím různých marketingových nástrojů, jako jsou bonusové karty. Celkem projekt zahrnuje 14 aplikací, které běží na deseti serverech.
Během procesu pohovoru jsem si opakovaně všiml, že správci ne vždy přistupují k monitorování webových aplikací správně: mnozí se stále zaměřují na metriky operačního systému a příležitostně sledují služby.
V mém případě byl zákaznický monitorovací systém dříve založen na Icinga. Výše uvedené problémy to nijak nevyřešilo. Často nás o problémech informoval sám klient a často jsme prostě neměli dostatek dat, abychom se dostali k závěru.
Navíc došlo k jasnému pochopení marnosti jejího dalšího rozvoje. Myslím, že ti, kteří znají Icingu, mě pochopí. Proto jsme se rozhodli pro projekt kompletně předělat systém monitorování webových aplikací.
Prometheus
Prometheus jsme vybrali na základě tří hlavních ukazatelů:
- Obrovské množství dostupných metrik. V našem případě jich je 60 tisíc. Samozřejmě stojí za zmínku, že drtivou většinu z nich nepoužíváme (pravděpodobně asi 95 %). Na druhou stranu jsou všechny relativně levné. Pro nás je to druhý extrém oproti dříve používané Icingě. V něm bylo přidání metrik zvláštní bolestí: ty stávající byly drahé (stačí se podívat na zdrojový kód jakéhokoli pluginu). Jakýkoli plugin byl skript v Bash nebo Pythonu, jehož spuštění je drahé z hlediska spotřebovaných zdrojů.
- Tento systém spotřebovává relativně malé množství zdrojů. Na všechny naše metriky stačí 600 MB RAM, 15 % jednoho jádra a pár desítek IOPS. Samozřejmě musíte spouštět exportéry metrik, ale všechny jsou napsány v Go a také nejsou moc hladové. Nemyslím si, že v moderní realitě je to problém.
- Poskytuje možnost migrace na Kubernetes. S ohledem na plány zákazníka je volba jasná.
ELK
Dříve jsme protokoly nesbírali ani nezpracovávali. Nedostatky jsou každému jasné. ELK jsme zvolili, protože jsme s tímto systémem již měli zkušenosti. Ukládáme tam pouze protokoly aplikací. Hlavním kritériem výběru bylo fulltextové vyhledávání a jeho rychlost.
Сlickhouse
Zpočátku padla volba na InfluxDB. Uvědomili jsme si potřebu shromažďovat protokoly Nginx, statistiky z pg_stat_statements a ukládat historická data Prometheus. Influx se nám nelíbil, protože pravidelně začal spotřebovávat velké množství paměti a padal. Kromě toho jsem chtěl seskupovat dotazy podle remote_addr, ale seskupování v tomto DBMS je pouze podle značek. Tagy jsou drahé (paměť), jejich počet je podmíněně omezen.
Začali jsme znovu hledat. To, co bylo potřeba, byla analytická databáze s minimální spotřebou zdrojů, nejlépe s kompresí dat na disku.
Clickhouse splňuje všechna tato kritéria a nikdy jsme nelitovali naší volby. Nezapisujeme do něj žádné mimořádné množství dat (počet vložení je jen asi pět tisíc za minutu).
NewRelic
NewRelic je s námi historicky, protože to byla volba zákazníka. Používáme jej jako APM.
Zabbix
Zabbix používáme výhradně ke sledování Black Box různých API.
Definování monitorovacího přístupu
Chtěli jsme úkol rozložit a tím systematizovat přístup k monitorování.
K tomu jsem náš systém rozdělil do následujících úrovní:
- hardware a VMS;
- operační systém;
- systémové služby, softwarový balík;
- aplikace;
- obchodní logika.
Proč je tento přístup pohodlný:
- víme, kdo je zodpovědný za práci každé úrovně, a na základě toho můžeme posílat upozornění;
- strukturu můžeme použít při potlačování výstrah – bylo by divné posílat výstrahu o nedostupnosti databáze, když je nedostupný virtuální stroj jako celek.
Vzhledem k tomu, že naším úkolem je identifikovat porušení v provozu systému, musíme na každé úrovni vyzdvihnout určitou sadu metrik, které stojí za to věnovat pozornost při psaní pravidel upozornění. Dále projdeme úrovněmi „VMS“, „Operační systém“ a „Systémové služby, softwarový zásobník“.
Virtuální stroje
Hosting nám přiděluje procesor, disk, paměť a síť. A s prvními dvěma jsme měli problémy. Takže metriky:
CPU ukradený čas – když si koupíte virtuální stroj na Amazonu (například t2.micro), měli byste pochopit, že vám není přiděleno celé jádro procesoru, ale pouze kvóta jeho času. A až ho vyčerpáte, procesor vám odeberou.
Tato metrika vám umožňuje sledovat takové momenty a rozhodovat se. Je například nutné použít tučnější tarif nebo distribuovat zpracování úloh na pozadí a požadavků API na různé servery?
IOPS + CPU iowait time – z nějakého důvodu mnoho cloudových hostingů hřeší tím, že neposkytuje dostatek IOPS. Navíc rozvrh s nízkými IOPS pro ně není argument. Proto se vyplatí sbírat CPU iowait. S touto dvojicí grafů – s nízkými IOPS a vysokým I/O čekáním – již můžete mluvit s hostingem a problém vyřešit.
Operační systém
Metriky operačního systému:
- množství dostupné paměti v %;
- aktivita využití swapu: vmstat swapin, swapout;
- počet dostupných inodů a volné místo v systému souborů v %
- průměrné zatížení;
- počet spojení ve stavu tw;
- plnost stolu conntrack;
- Kvalitu sítě lze sledovat pomocí utility ss, balíčku iproute2 - z jejího výstupu získejte indikátor RTT spojení a seskupte jej podle cílového portu.
Také na úrovni operačního systému máme takovou entitu jako procesy. V systému je důležité identifikovat soubor procesů, které hrají důležitou roli v jeho fungování. Pokud máte například několik pgpoolů, musíte shromažďovat informace pro každý z nich.
Sada metrik je následující:
- PROCESOR;
- paměť je primárně rezidentní;
- IO - nejlépe v IOPS;
- FileFd - otevřít a omezit;
- významná selhání stránky – tímto způsobem můžete pochopit, jaký proces se zaměňuje.
Veškeré monitorování nasazujeme v Dockeru a ke sběru dat metrik používáme Advisor. Na ostatních strojích používáme proces-exporter.
Systémové služby, softwarový zásobník
Každá aplikace má svá specifika a je těžké vyčlenit konkrétní sadu metrik.
Univerzální sada je:
- sazba poptávky;
- počet chyb;
- latence;
- nasycení.
Naše nejvýraznější příklady monitorování na této úrovni jsou Nginx a PostgreSQL.
Nejzatíženější službou v našem systému je databáze. V minulosti jsme měli často problém zjistit, co databáze dělá.
Viděli jsme vysoké zatížení disků, ale pomalé protokoly ve skutečnosti nic neukazovaly. Tento problém jsme vyřešili pomocí pg_stat_statements, pohledu, který shromažďuje statistiky dotazů.
To je vše, co admin potřebuje.
Sestavujeme grafy aktivity požadavků na čtení a zápis:
Vše je jednoduché a přehledné, každý požadavek má svou barvu.
Neméně nápadným příkladem jsou protokoly Nginx. Není divu, že je jen málokdo rozebere nebo je zmíní v seznamu must have. Standardní formát není příliš informativní a je třeba jej rozšířit.
Osobně jsem přidal request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Vykreslujeme dobu odezvy a počet chyb:
Vytváříme grafy doby odezvy a počtu chyb. Pamatovat si? Mluvil jsem o obchodních cílech? Rychle a bez chyb? Tyto problémy jsme již pokryli dvěma grafy. A už se pomocí nich můžete dovolat správcům ve službě.
Zůstává ale ještě jeden problém – zajistit rychlé odstranění příčin incidentu.
Řešení incidentu
Celý proces od identifikace až po vyřešení problému lze rozdělit do několika kroků:
- identifikace problému;
- oznámení správci povinnosti;
- reakce na incident;
- odstranění příčin.
Je důležité, abychom to udělali co nejrychleji. A pokud ve fázích identifikace problému a zaslání upozornění nemůžeme získat mnoho času - v každém případě jim strávíme dvě minuty, pak jsou ty následující jednoduše zorané pole pro vylepšení.
Představme si, že úředníkovi zazvonil telefon. co bude dělat? Hledejte odpovědi na otázky – co prasklo, kde se to zlomilo, jak reagovat? Na tyto otázky odpovídáme takto:
Všechny tyto informace jednoduše zahrneme do textu oznámení, dáme mu odkaz na wiki stránku, která popisuje, jak na tento problém reagovat, jak jej vyřešit a eskalovat.
Stále jsem neřekl nic o aplikační vrstvě a obchodní logice. Naše aplikace bohužel zatím neimplementují sběr metrik. Jediným zdrojem jakýchkoli informací z těchto úrovní jsou protokoly.
Pár bodů.
Nejprve napište strukturované protokoly. Do textu zprávy není třeba uvádět kontext. To ztěžuje jejich seskupování a analýzu. Logstash trvá dlouho, než to všechno znormalizuje.
Za druhé, správně používejte úrovně závažnosti. Každý jazyk má svůj vlastní standard. Osobně rozlišuji čtyři úrovně:
- žádná chyba;
- chyba na straně klienta;
- chyba je na naší straně, neztrácíme peníze, neneseme rizika;
- Chyba je na naší straně, přicházíme o peníze.
Dovolte mi to shrnout. Musíte se pokusit vybudovat monitorování založené na obchodní logice. Zkuste sledovat samotnou aplikaci a operovat s takovými metrikami, jako je počet prodejů, počet registrací nových uživatelů, počet aktuálně aktivních uživatelů a podobně.
Pokud je celá vaše firma jedním tlačítkem v prohlížeči, musíte sledovat, zda kliká a funguje správně. Na všem ostatním nezáleží.
Pokud to nemáte, můžete to zkusit dohnat v protokolech aplikací, protokolech Nginx a tak dále, jako jsme to udělali my. Měli byste být co nejblíže aplikaci.
Metriky operačního systému jsou samozřejmě důležité, ale byznys o ně nemá zájem, nejsme za ně placeni.
Zdroj: www.habr.com