Monitorování monitorování: strategie odolnosti proti selhání | IT-praxe

# Strategie monitorování monitorování: jak se vyhnout rekurzivní slepotě

Systémy monitorování vytvářejí iluzi bezpečnosti: když selže sám nástroj pro kontrolu, dashboardy nadále zobrazují zastaralá data a maskují skutečné poruchy. To není hypotetický problém – reálné případy s Prometheus ukazují, jak snadno přehlédnout kritické incidenty kvůli nefunkčnímu monitorování. Řešení vyžaduje odolnou architekturu, ale bez zbytečného složitého přístupu.

Proč se systém monitorování stává slepou skvrnou

Když Prometheus nebo podobný nástroj přestane fungovat, následky jsou katastrofické. V jednom případě se disk monitorovacího serveru zaplnil kvůli neomezenému ukládání dat Prometheus. Ve druhém kubelet zničil pod s Prometheus kvůli chybě OOM, a Pod Disruption Budget nebyl nastaven. V obou scénářích zůstaly dashboardy „zelené“, protože zobrazovaly data z posledních úspěšných sběrů. Alerty se nespouštěly, protože Alertmanager závisel na nefunkčním Prometheus.

Klíčový paradox: monitorování nemůže zkontrolovat samo sebe. Pokud padne hlavní systém kontroly, chybí mechanismus pro generování upozornění. To není abstraktní úloha – každý tým, který zavádí pokročilou observability, se setkává s nutností řešit tento rekurzivní problém. Existující přístupy se dělí do dvou kategorií: teoreticky ideální (ale ekonomicky neoplatné) a prakticky použitelné (s kompromisy).

Architektonické strategie pro odolnou kontrolu

Nezávislé domény selhání – základní princip. Doména selhání sdružuje komponenty, které selžou současně (VPS, Kubernetes-klastr, cloudová region). Nejběžnější chyba je umístění služeb a monitorování na stejný server. Řešení:

• Samostatný fyzický server pro monitorování (snižuje riziko, ale neeliminuje ho – společné datové centrum zůstává jednou bodem selhání)
• Rozložení do různých cloudů (Yandex Cloud + AWS), což snižuje pravděpodobnost současného selhání na 0,0001 % za měsíc
• Serverless architektura pro kritické kontroly (řetězec kontrol v Cloud Functions, nezávislý na hlavní infrastruktuře)

Meta-heartbeat realizuje jednoduchý watchdog mechanismus:

• Plánovač monitorování každou minutu aktualizuje časovou značku v nezávislém úložišti (Redis, soubor)
• Samostatná lambda funkce kontroluje aktuálnost značky každých 5 minut
• Při zjištění zastaralosti – alert se odešle přes alternativní kanál (SMS, samostatný Telegram-bot)

Kriticky důležité je, aby watchdog a kanál upozornění nezávisely na stejných komponentách jako hlavní monitorování. Jinak se přidává jen další bod selhání.

Dead Man’s Switch a křížové monitorování

Dead Man’s Switch – varianta meta-heartbeat s externí kontrolou. Služba jako Healthchecks.io nebo PagerDuty očekává pravidelné pingy od vašího systému. Při jejich absenci se aktivuje alert přes záložní kanál:

[Monitorovací systém] --ping--> [Externí Dead Man's Switch]
                                  |
                            (vynechání pingu)
                                  |
                        [Alert přes SMS/PagerDuty]

Tento přístup vytváří závislost na třetí straně, ale pravděpodobnost současného selhání vašeho monitorování a externí služby je zanedbatelná. Pro kriticky důležité systémy se používá křížové monitorování: dvě nezávislé systémy se navzájem kontrolují. Podpora dvou plnohodnotných řešení (např. Prometheus + Datadog) je však pro většinu projektů ekonomicky neoplatná. Realističtější je hybrid: hlavní monitorování + primitivní watchdog (cron-skript na samostatném serveru).

Praktický limit: princip „dost dobré“

Pravděpodobnosti selhání ukazují, že dva úrovně nezávislosti jsou optimální pro 99,9 % systémů:

• Váš VPS padne: ~0,1–1 % za měsíc
• Cloud je nedostupný: ~0,01 % za měsíc
• Dva cloudy padnou současně: ~0,0001 % za měsíc
• Tři cloudy: úroveň astrofyzikálních událostí

Racionální konfigurace zahrnuje:

• Hlavní monitorování v samostatné doméně selhání (SaaS nebo serverless)
• Dead Man’s Switch ve vnější službě
• Záložní kanály upozornění (Telegram + SMS)

Třetí úroveň ochrany se nevyplatí náklady na snížení již minimálního rizika. Pokud současně padnou hlavní monitorování, dead man’s switch a Telegram – setkáte se s problémy, kde kontrola infrastruktury už není prioritou (globální blackout, jaderná válka).

Kritické aspekty, které se často přehlížejí

Kanály upozornění jako doména selhání. I při funkčním monitorování se alert nemusí dostat kvůli selhání v Slacku nebo Telegramu. Řešení – duplikace kanálů: kritická upozornění se odesílají přes SMS a email současně. Pravděpodobnost selhání dvou kanálů je o řád nižší než jednoho.

Stateless vs stateful monitorování. Prometheus ukládá historii metrik, takže při selhání se ztrácejí data za dobu výpadku. Stateless kontroly („odpovídá na URL?“) tento problém nemají: po obnovení okamžitě pokračují. Kombinujte stateful systémy (Prometheus) se stateless kontrolou (externí pingy) – selhávají odlišně a pokrývají různé scénáře.

Testování monitorování. Mnoho týmů systém nastaví, ale nikdy ho nezkontroluje v praxi. Pravidelně provádějte game days: záměrně simulujte selhání ve staging prostředí a ověřte, že alerty fungují. Je to levnější než objevit nefunkční monitorování během reálného incidentu.

Co je důležité

• Rozdělte monitorování a monitorované služby do nezávislých domén selhání (různé cloudy, serverless)
• Realizujte dead man’s switch s odděleným kanálem upozornění (SMS/PagerDuty)
• Duplikujte kanály upozornění pro kritické alerty
• Testujte systém kontroly stejně jako kód a zálohy
• Pro 99 % projektů stačí dva úrovně ochrany – třetí je neoprávně drahý

— Editorial Team