Vyvinout backendovou aplikaci, sestavit ji, otestovat a nasadit — to je ta zábavná část. Právě to si většina lidí představí pod tím, co vývojáři celý den dělají. V ideálním případě z toho vznikne aplikace, kterou budou lidé opravdu používat. A zatímco investoři si přejí, aby ji používalo co nejvíc lidí, vývojáři by si možná přáli, aby jich zas tolik nebylo.
Proč? Protože produkční provoz přináší jeden zásadní závazek: že aplikace bude dostupná a bude fungovat bez chyb. A to se samo od sebe nikdy nestane.
Nic vaši aplikaci neprověří tolik jako ostrý provoz. Ten navíc většinou nezůstává stejný — stabilně roste. A s každým dalším požadavkem přichází i další rizika. Nasazením do produkce to totiž celé teprve začíná. Zadání je jasné: ať aplikace běží bez chyb.
Monitoring, aneb jak se dozvědět, že hoří
Jak vlastně zjistíme, že aplikace nefunguje tak, jak má? Jedna možnost je počkat, až si začnou stěžovat uživatelé. Ideálně rovnou zahlcovat podporu, nebo ještě lépe — úplně přestat naši aplikaci používat.
To ale asi není scénář, podle kterého bychom chtěli řídit provoz moderní služby. Reaktivní hašení požárů necháme minulosti.
My chceme vědět dřív než uživatel — ideálně dřív, než se vůbec něco pokazí. Proto nastupuje námi preferovaná varianta: aplikaci aktivně sledujeme a při blížícím se problému včas zasahujeme. Tento přístup má jméno: monitoring aplikace.
Co monitorovat
Co všechno je potřeba sledovat, závisí na samotné aplikaci. Pokud se bavíme o běžné webové aplikaci, nejčastěji nás budou zajímat aplikační servery, databáze, napojení na externí webové služby, síťové prvky, ostatní komunikační komponenty, keše, datov á úložiště, zálohování, náklady na provoz, ale i zranitelnosti v knihovnách, billing a další.
Pár konkrétních příkladů pro představu:
- Aplikace hlásí chyby – nejspíš něco nefunguje tak, jak má.
- Aplikace je pomalá a vytěžuje zdroje na maximum – dochází jí paměť, restartuje se, nebo nestíhá odbavovat požadavky kvůli přetíženému CPU.
- Databáze je pomalá a jede nadoraz – může jít o nedostatek výpočetních zdrojů, neoptimalizované dotazy nebo špatnou konfiguraci.
- Databáze má nedostatek místa na disku – a bez místa se zapisovat nedá.
- Výpadek funkce systému – třeba když aplikace zničehonic přestane posílat SMS.
- Výpadek části systému – například když aplikace ztratí přístup k datovým úložištím.
Monitorovací nástroje
Možností, jak aplikaci sledovat, je dnes celá řada. Sentry. Datadog. Logstash. New Relic. Prometheus. Snyk. Grafana… a mohl bych pokračovat dál.
Tohle povídání ale není o tom tyto nástroje srovnávat nebo hodnotit. Každý z nich nabízí určitou službu, která může váš problém řešit. Ale důležitá myšlenka je i tahle: není vždy nutné používat specializovaný nástroj, pokud si danou věc zvládnete ohlídat s tím, co už máte k dispozici.
Tento blog ale není o tom existující nástroje porovnávat, hodnotit ani doporučovat. Každý zmíněný nástroj nabízí nějakou službu, která může řešit váš problém. Nemusí být ale nutné použít jedinou, pokud to zvládnete bez nich.
V Ackee máme zkušenosti s většinou výše zmíněných nástrojů. Momentálně je nám nejbližší Sentry, ale ani to primárně nepoužíváme pro backendové aplikace. Zejména kvůli tomu, že dokáže sledovat pouze běžící aplikaci. Co ale pády aplikace? Co ostatní části systému, bez kterých se aplikace neobejde?
Prometheus a Grafanu bych označil za industry standard. A přesto – ani to není naše první volba. Důvod? Cena. Ne nutně finanční, ale provozní: nastavení, údržba, integrace… nejsou to nezvládnutelné věci, ale ve finále přidávají další vrstvy složitosti, které často nejsou nezbytné.
Naše nastavení
Ackee je Google Cloud partner a naše aplikace provozujeme primárně na platformě Google Cloud (GCP). Vznikne-li potřeba sledovat produkční aplikaci a zajistit její funkčnost, snažíme se efektivně využít nástroje, které máme k dispozici.
GCP samo o sobě nabízí pro potřeby monitoringu hotové dashboardy pro sledování metrik všech komponent, které jsem zmínil výše – aplikační servery, databáze, vyrovnávač zátěže, fronty zpráv atp.
Pokud aplikaci umíme sledovat, měli bychom nastavit i upozornění. To umí i GCP. Kromě e-mailů nabízí i integraci s Slackem, který v Ackee používáme. Když některá metrika překročí nastavenou hranici, GCP pošle zprávu do Slacku, kde ji rovnou odbavíme, aniž bychom museli neustále sledovat dashboard.
Slack je místo, kde vývojáři každý den sledují alerty a klasifikují je podle závažnosti: kritické chyby, standardní chyby, chyby neomezující systém ale těžké vyřešit, a chybně reportované události nebo již opravené problémy.
Podle závažnosti incidentu se propojí s historickými alerty a vytvoří se ticket v našem interním systému s návrhem řešení. V případě zásadních chyb dochází ke konzultaci s projektovým týmem a někdy i klientem kvůli koordinaci řešení incidentu.
Automatická upozornění jsou skvělá pro rychlou reakci. Ale mají své limity – fungují až ve chvíli, kdy se překročí nastavená hranice. Pomalu rostoucí problémy ale často poznáme jen z vývoje trendů, které automat zatím ignoruje.
Proto v Ackee děláme i pravidelné ruční kontroly systému. Projdeme dashboardy, porovnáme vývoj metrik a hledáme neobvyklé chování. Zkušené oko vývojáře si všimne varovných signálů dřív než systém.
Každá taková kontrola se řídí jasným checklistem a výstupy zaznamenáváme. Slouží jako sdílená znalost i historická stopa, která se hodí při zpětném dohledávání souvislostí.
Monitoring je začátek
Aby aplikace běžela, jak má, nestačí jen mít správné nástroje – klíčová je disciplína vývojářů. Monitoring a alerting dnes zvládne i základní sada nástrojů. Čas na jejich nastavení, údržbu a řešení problémů si většina týmů dokáže vyčlenit. Ale právě disciplína rozhoduje, jestli upozornění někdo opravdu sleduje, jestli na ně včas reagujeme a jestli se z incidentů poučíme.
Disciplína znamená:
- Reagovat na chyby dřív, než si jich všimne uživatel
- Pravidelně kontrolovat systém, i když zrovna „všechno funguje“
- Dlouhodobě udržovat systém zdravý, i když je lákavější psát nový kód
Monitoring není jednorázová záležitost, ale dlouhodobý závazek. Když ho vývojáři berou vážně, aplikace běží tak, jak má.
