Takésystem monitoring, application monitoring, infrastructure monitoring, observability monitoringPokročilý
Definice
Monitoring je soustavné sledování stavu systému pomocí metrik, logů, událostí, trace záznamů a alertů. V softwaru a provozu ukazuje, zda aplikace, infrastruktura nebo služba plní očekávání, pomáhá rychle odhalit poruchu a poskytuje data pro rozhodnutí o kapacitě, výkonu i bezpečnosti.
Nezaměňujte: Monitoring může mimo IT znamenat obecné sledování médií, prostředí nebo obchodních ukazatelů; toto heslo popisuje hlavně provozní monitoring softwaru a infrastruktury.
Co se u monitoringu vlastně měří
Monitoring v provozu softwaru převádí chování systému na signály, které lze průběžně sledovat. Typické metriky jsou dostupnost, latence, chybovost, využití CPU, paměť, zaplnění disku, délka fronty nebo počet požadavků. Logy doplňují kontext jednotlivých událostí a trace záznamy ukazují cestu požadavku přes více služeb, například přes API Gateway, databázi a externí platební službu.
Samotné sbírání dat nestačí. Užitečný monitoring má hranice očekávaného chování, alerty, odpovědnost za reakci a postup řešení incidentu. Bez těchto vazeb vzniká jen drahý archiv čísel, ve kterém se problém hledá až ve chvíli, kdy si stěžují uživatelé.
Proč monitoring řeší dopad na uživatele
Dobrá sada signálů začíná otázkou, co uživatel nebo navazující systém skutečně pocítí. Výpadek jednoho kontejneru nemusí vadit, pokud provoz přebere další replika. Naopak malý nárůst latence může být kritický, když způsobí timeout v mobilní aplikaci nebo rozpadne objednávkový proces.
Provozní týmy proto často kombinují technické ukazatele s produktovými signály. Dostupnost endpointu, počet neúspěšných přihlášení a poměr dokončených plateb mohou dohromady vysvětlit víc než jeden graf vytížení procesoru. V prostředí jako Kubernetes je navíc důležité rozlišovat mezi stavem podu, stavem služby a skutečnou odezvou pro klienta.
Kdy metrika nestačí bez logu a trace
Metrika rychle řekne, že se něco změnilo. Log často vysvětlí, co se v konkrétním okamžiku stalo. Trace pomůže tam, kde požadavek prochází více službami a chyba se projeví jinde, než vznikla. U distribuovaných systémů je právě tato návaznost klíčová, protože lokálně zdravá služba může selhávat kvůli pomalé závislosti.
Monitoring také souvisí s kapacitním řízením. Pokud fronty rostou rychleji, než je systém zpracuje, může se objevit backpressure. Včasný alert pak nehlásí jen aktuální poruchu, ale varuje před trendem, který za několik minut nebo hodin způsobí degradaci služby.
Dva příklady z provozu
Výpadek plateb po nasazení nové verze
E-shop nasadí novou verzi checkoutu a monitoring ukáže běžnou dostupnost serverů, ale prudce klesne počet úspěšně dokončených plateb. Dashboard s technickými metrikami by vypadal téměř zdravě, produktová metrika však odhalí obchodní dopad. Tým dohledá v logu chybný formát požadavku pro platební bránu a vrátí nasazení zpět.
Alert na rostoucí chybovost API
Veřejné API začne vracet více odpovědí řady 5xx během pětiminutového okna. Alert je navázaný na poměr chyb, ne na absolutní počet, takže funguje ve špičce i v noci. Operátor dostane upozornění dřív, než incident zasáhne většinu klientů.
- alert: HighErrorRate
expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05
for: 10mPříklady z praxe
Výpadek plateb po nasazení nové verze
E-shop nasadí novou verzi checkoutu a monitoring ukáže běžnou dostupnost serverů, ale prudce klesne počet úspěšně dokončených plateb. Dashboard s technickými metrikami by vypadal téměř zdravě, produktová metrika však odhalí obchodní dopad. Tým dohledá v logu chybný formát požadavku pro platební bránu a vrátí nasazení zpět.
Alert na rostoucí chybovost API
Veřejné API začne vracet více odpovědí řady 5xx během pětiminutového okna. Alert je navázaný na poměr chyb, ne na absolutní počet, takže funguje ve špičce i v noci. Operátor dostane upozornění dřív, než incident zasáhne většinu klientů.
- alert: HighErrorRate expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.05 for: 10m
Časté omyly
- MýtusKdyž máme dashboard, máme monitoring vyřešený.
- Ve skutečnostiDashboard je jen jedna část monitoringu. Funkční monitoring potřebuje také sběr správných signálů, alerty, odpovědnost za reakci a postup pro vyhodnocení incidentu.
- MýtusMonitoring má sbírat všechno, co jde.
- Ve skutečnostiNekritické metriky mohou prodražit ukládání a ztížit orientaci při incidentu. Lepší je měřit signály, které vysvětlují zdraví služby, dopad na uživatele a kapacitní rizika.
Časté dotazy
- Kolik metrik má mít dobrý monitoring?
- Dobrý monitoring má tolik metrik, kolik tým skutečně používá pro rozhodování o zdraví služby, kapacitě a incidentech. Příliš málo metrik skryje důležité souvislosti, ale příliš mnoho metrik vytvoří šum, drahé ukládání a nečitelná upozornění. Praktický začátek bývá dostupnost, latence, chybovost a saturace klíčových zdrojů, doplněné o několik metrik přímo spojených s byznysem nebo uživatelskou cestou.
- Proč monitoring někdy neukáže skutečnou příčinu výpadku?
- Monitoring někdy ukáže pouze symptom, protože měřený signál vzniká až na konci řetězce závislostí. Vysoká latence API může být způsobená databází, DNS, externí službou, frontou nebo chybou v nové verzi aplikace. K nalezení příčiny pomáhá korelace metrik, logů a trace záznamů, společné identifikátory požadavků a časová osa nasazení, konfigurací a incidentů.
- Patří do monitoringu i bezpečnostní události?
- Bezpečnostní monitoring patří do širšího obrazu provozu, ale sleduje jiné signály než běžné výkonové grafy. Důležité jsou například neobvyklé pokusy o přihlášení, změny oprávnění, blokované požadavky, podezřelá komunikace nebo zásahy do auditních logů. Pro bezpečnostní události je zvlášť důležitá integrita záznamů, časová synchronizace a jasné rozlišení mezi informativní událostí a incidentem.
- Jaký rozdíl řeší alert proti dashboardu?
- Alert je akční upozornění, které má někoho přimět k reakci v určitém čase. Dashboard je vizuální přehled, který pomáhá chápat stav systému, trendy a souvislosti. Monitoring může používat obojí, ale špatně nastavený alert unavuje tým falešnými poplachy, zatímco samotný dashboard nikomu nezaručí, že si problému všimne včas.
Zdroje
- Cloud Monitoring documentation(otevře se v novém okně)
- Azure Monitor overview(otevře se v novém okně)
- Amazon CloudWatch(otevře se v novém okně)
- Resource metrics pipeline(otevře se v novém okně)
- Guide to Computer Security Log Management(otevře se v novém okně)
Související pojmy
