Volám sa Anton Baderin. Pracujem v High Technology Center a robím správu systému. Pred mesiacom sa skončila naša firemná konferencia, kde sme sa podelili o nazbierané skúsenosti s IT komunitou nášho mesta. Hovoril som o monitorovaní webových aplikácií. Materiál bol určený pre juniorov alebo strednú úroveň, ktorí tento proces nevybudovali od nuly.
Základným kameňom každého monitorovacieho systému je riešenie obchodných problémov. Monitorovanie kvôli monitorovaniu nikoho nezaujíma. Čo chce biznis? Aby všetko fungovalo rýchlo a bez chýb. Firmy chcú byť proaktívne, aby sme sami identifikovali problémy v službe a čo najrýchlejšie ich opravili. To sú vlastne problémy, ktoré som riešil celý minulý rok na projekte pre jedného z našich zákazníkov.
o
Projekt je jedným z najväčších vernostných programov v krajine. Pomáhame obchodným reťazcom zvyšovať frekvenciu predaja prostredníctvom rôznych marketingových nástrojov ako sú bonusové karty. Celkovo projekt zahŕňa 14 aplikácií, ktoré bežia na desiatich serveroch.
Počas procesu rozhovoru som si opakovane všimol, že správcovia nie vždy pristupujú k monitorovaniu webových aplikácií správne: mnohí sa stále zameriavajú na metriky operačného systému a príležitostne sledujú služby.
V mojom prípade bol zákaznícky monitorovací systém predtým založený na Icinga. Vyššie uvedené problémy to nijako nevyriešilo. Často nás o problémoch informoval sám klient a častejšie sme jednoducho nemali dostatok údajov, aby sme sa dostali k podstate.
Okrem toho bolo jasné pochopenie nezmyselnosti jeho ďalšieho rozvoja. Myslím, že tí, ktorí poznajú Icingu, ma pochopia. Preto sme sa rozhodli pre projekt kompletne prerobiť monitorovací systém webových aplikácií.
Prometheus
Prometheus sme si vybrali na základe troch hlavných ukazovateľov:
- Obrovské množstvo dostupných metrík. V našom prípade je ich 60 tisíc. Samozrejme, stojí za zmienku, že drvivú väčšinu z nich (pravdepodobne okolo 95 %) nepoužívame. Na druhej strane sú všetky relatívne lacné. Pre nás je to druhý extrém v porovnaní s doteraz používanou Icingou. V ňom bolo pridávanie metrík zvláštnou bolesťou: existujúce boli drahé (stačí sa pozrieť na zdrojový kód akéhokoľvek pluginu). Akýkoľvek plugin bol skript v Bash alebo Pythone, ktorého spustenie je drahé z hľadiska spotrebovaných zdrojov.
- Tento systém spotrebúva relatívne malé množstvo zdrojov. Na všetky naše metriky stačí 600 MB RAM, 15 % jedného jadra a niekoľko desiatok IOPS. Samozrejme, musíte spustiť exportéry metrík, ale všetky sú napísané v Go a tiež nie sú veľmi hladné. Nemyslím si, že v modernej realite je to problém.
- Poskytuje možnosť migrovať na Kubernetes. Vzhľadom na plány zákazníka je voľba jasná.
ELK
Predtým sme protokoly nezbierali ani nespracovávali. Nedostatky sú každému jasné. Vybrali sme si ELK, pretože sme už s týmto systémom mali skúsenosti. Ukladáme tam iba denníky aplikácií. Hlavným kritériom výberu bolo fulltextové vyhľadávanie a jeho rýchlosť.
Сlickhouse
Spočiatku padla voľba na InfluxDB. Uvedomili sme si potrebu zhromažďovať denníky Nginx, štatistiky z pg_stat_statements a ukladať historické údaje Prometheus. Influx sa nám nepáčil, pretože pravidelne začal spotrebovávať veľké množstvo pamäte a havaroval. Okrem toho som chcel zoskupiť dotazy podľa remote_addr, ale zoskupenie v tomto DBMS je len podľa značiek. Tagy sú drahé (pamäť), ich počet je podmienečne obmedzený.
Začali sme znova hľadať. Potrebná bola analytická databáza s minimálnou spotrebou zdrojov, najlepšie s kompresiou dát na disku.
Clickhouse spĺňa všetky tieto kritériá a svoju voľbu sme nikdy neoľutovali. Nezapisujeme do nej žiadne mimoriadne množstvo údajov (počet vložení je len okolo päťtisíc za minútu).
NewRelic
NewRelic je s nami historicky, pretože to bola voľba zákazníka. Používame ho ako APM.
Zabbix
Zabbix používame výhradne na monitorovanie čiernej skrinky rôznych API.
Definovanie monitorovacieho prístupu
Chceli sme rozložiť úlohu a tým systematizovať prístup k monitorovaniu.
Aby som to urobil, rozdelil som náš systém do nasledujúcich úrovní:
- hardvér a VMS;
- operačný systém;
- systémové služby, balík softvéru;
- aplikácia;
- obchodná logika.
Prečo je tento prístup pohodlný:
- vieme, kto je zodpovedný za prácu každej úrovne a na základe toho môžeme posielať upozornenia;
- štruktúru môžeme použiť pri potláčaní upozornení – bolo by zvláštne posielať upozornenie o nedostupnosti databázy, keď je virtuálny stroj ako celok nedostupný.
Keďže našou úlohou je identifikovať porušenia pri fungovaní systému, musíme na každej úrovni vyzdvihnúť určitý súbor metrík, ktorým sa oplatí venovať pozornosť pri písaní pravidiel upozorňovania. Ďalej prejdime cez úrovne „VMS“, „Operačný systém“ a „Systémové služby, softvérový zásobník“.
Virtuálne stroje
Hosting nám prideľuje procesor, disk, pamäť a sieť. A s prvými dvoma sme mali problémy. Takže metriky:
CPU ukradnutý čas - keď si kúpite virtuálny stroj na Amazone (napríklad t2.micro), mali by ste pochopiť, že vám nie je pridelené celé jadro procesora, ale iba kvóta jeho času. A keď ho vyčerpáte, procesor vám zoberú.
Táto metrika vám umožňuje sledovať takéto momenty a robiť rozhodnutia. Je napríklad potrebné použiť hrubšiu tarifu alebo distribuovať spracovanie úloh na pozadí a požiadaviek API na rôzne servery?
IOPS + CPU iowait time – z nejakého dôvodu veľa cloudových hostingov hreší tým, že neposkytuje dostatok IOPS. Navyše harmonogram s nízkym IOPS pre nich nie je argument. Preto sa oplatí zbierať CPU iowait. S touto dvojicou grafov – s nízkym IOPS a vysokým čakaním na vstup/výstup – už môžete hovoriť s hostingom a vyriešiť problém.
Operačný systém
Metriky operačného systému:
- množstvo dostupnej pamäte v %;
- aktivita používania swapu: vmstat swapin, swapout;
- počet dostupných inodov a voľné miesto v súborovom systéme v %
- priemerné zaťaženie;
- počet spojení v tw stave;
- conntrack plnosť stola;
- Kvalitu siete je možné sledovať pomocou utility ss, balíka iproute2 – z jeho výstupu získajte indikátor RTT spojení a zoskupte ho podľa cieľového portu.
Aj na úrovni operačného systému máme takú entitu ako procesy. Je dôležité identifikovať v systéme súbor procesov, ktoré zohrávajú dôležitú úlohu v jeho fungovaní. Ak máte napríklad niekoľko pgpoolov, musíte zbierať informácie pre každý z nich.
Sada metrík je nasledovná:
- CPU;
- pamäť je primárne rezidentná;
- IO - najlepšie v IOPS;
- FileFd - otvoriť a obmedziť;
- významné zlyhania stránky – týmto spôsobom môžete pochopiť, aký proces sa zamieňa.
Všetko monitorovanie nasadzujeme v Dockeri a na zhromažďovanie údajov o metrikách používame Advisor. Na iných strojoch používame proces-exportér.
Systémové služby, softvérový zásobník
Každá aplikácia má svoje špecifiká a je ťažké vyčleniť konkrétny súbor metrík.
Univerzálna sada je:
- rýchlosť dopytu;
- počet chýb;
- latencia;
- sýtosť.
Naše najvýraznejšie príklady monitorovania na tejto úrovni sú Nginx a PostgreSQL.
Najviac zaťažovanou službou v našom systéme je databáza. V minulosti sme mali často problém zistiť, čo databáza robí.
Videli sme vysoké zaťaženie diskov, ale pomalé protokoly v skutočnosti nič neukázali. Tento problém sme vyriešili pomocou pg_stat_statements, zobrazenia, ktoré zhromažďuje štatistiky dopytov.
To je všetko, čo správca potrebuje.
Vytvárame grafy aktivity požiadaviek na čítanie a zápis:
Všetko je jednoduché a prehľadné, každá požiadavka má svoju farbu.
Rovnako nápadným príkladom sú denníky Nginx. Nie je prekvapujúce, že len málo ľudí ich rozoberá alebo ich spomína v zozname must have. Štandardný formát nie je príliš informatívny a je potrebné ho rozšíriť.
Osobne som pridal request_time, upstream_response_time, body_bytes_sent, request_length, request_id. Vykresľujeme čas odozvy a počet chýb:
Vytvárame grafy času odozvy a počtu chýb. Pamätáte si? Hovoril som o obchodných úlohách? Rýchlo a bez chýb? Tieto problémy sme už pokryli dvoma grafmi. A pomocou nich už môžete volať aj službukonajúcim správcom.
Zostáva však ešte jeden problém – zabezpečiť rýchle odstránenie príčin incidentu.
Riešenie incidentu
Celý proces od identifikácie až po vyriešenie problému možno rozdeliť do niekoľkých krokov:
- identifikácia problému;
- oznámenie správcovi povinnosti;
- reakcia na incident;
- odstránenie príčin.
Je dôležité, aby sme to urobili čo najrýchlejšie. A ak vo fázach identifikácie problému a odoslania upozornenia nemôžeme získať veľa času - v každom prípade im strávime dve minúty, potom sú nasledujúce jednoducho pole pre vylepšenia.
Predstavme si, že úradníkovi zazvonil telefón. čo bude robiť? Hľadajte odpovede na otázky – čo sa zlomilo, kde sa to zlomilo, ako reagovať? Na tieto otázky odpovedáme takto:
Všetky tieto informácie jednoducho zahrnieme do textu oznámenia, dáme mu odkaz na stránku wiki, ktorá popisuje, ako na tento problém reagovať, ako ho vyriešiť a eskalovať.
Stále som nepovedal nič o aplikačnej vrstve a obchodnej logike. Bohužiaľ, naše aplikácie zatiaľ neimplementujú zber metrík. Jediným zdrojom akýchkoľvek informácií z týchto úrovní sú denníky.
Pár bodov.
Najprv napíšte štruktúrované protokoly. V texte správy nie je potrebné uvádzať kontext. To sťažuje ich zoskupovanie a analýzu. Logstash trvá dlho, kým to všetko znormalizuje.
Po druhé, správne používajte úrovne závažnosti. Každý jazyk má svoj vlastný štandard. Osobne rozlišujem štyri úrovne:
- žiadna chyba;
- chyba na strane klienta;
- chyba je na našej strane, nestrácame peniaze, nenesieme riziká;
- Chyba je na našej strane, prichádzame o peniaze.
Zhrniem to. Musíte sa pokúsiť vybudovať monitorovanie založené na obchodnej logike. Skúste sledovať samotnú aplikáciu a operujte s takými metrikami, ako je počet predajov, počet registrácií nových používateľov, počet aktuálne aktívnych používateľov a pod.
Ak je celá vaša firma jedným tlačidlom v prehliadači, musíte sledovať, či kliká a funguje správne. Na všetkom ostatnom nezáleží.
Ak to nemáte, môžete sa to pokúsiť dohnať v protokoloch aplikácií, protokoloch Nginx atď., Ako sme to urobili my. Mali by ste byť čo najbližšie k aplikácii.
Metriky operačného systému sú samozrejme dôležité, ale biznis ich nezaujíma, nie sme za ne platení.
Zdroj: hab.com