Šum z monitoringu: z tisíců alertů pár situací

Ve dvě ráno spadne přepínač v jednom sále. Během několika minut přijdou stovky alertů: nedostupné servery, nedostupné databáze, chybující aplikace, překročené časy odezvy. Pohotovost dostane notifikace jednu za druhou a musí v nich najít to podstatné. Co je příčina a co jen důsledek? Které služby jsou opravdu zasažené? A není to náhodou kvůli změně, která v tu dobu běží?

Šum z monitoringu není jen technická nepříjemnost. Lidé na pohotovosti se postupně naučí, že většina alertů nic neznamená, a začnou je přehlížet. Pak přijde ten jeden, který něco znamená, a zapadne. Únava z alertů je jedním z nejtišších rizik provozu.

Proč přidávání pravidel nepomáhá

Běžnou reakcí je ladit prahy a přidávat výjimky přímo v monitoringu. Krátkodobě to pomůže, ale monitoring vidí jen svou část světa. Neví, že databáze běží na serveru, který je zapojený do přepínače, který právě vypadl. Neví ani, že na serveru právě probíhá schválená změna.

V praxi často vidíme tyto vzorce:

• stejný problém hlásí několik monitorovacích nástrojů zároveň,
• jedna služba „bliká“ mezi stavy a každá změna stavu je nový alert,
• plánovaná údržba vygeneruje desítky alertů, které nikdo nepotřebuje,
• z každého alertu vznikne incident a fronta se zaplní duplicitami.

Jak k tomu přistupovat

Šum se nedá odstranit na jednom místě. Je potřeba ho stlačovat postupně, jako trychtýřem. Nejdřív odstranit duplicity a blikání. Pak potlačit to, co je očekávané, například alerty během schválené změny. A nakonec seskupit zbylé alerty podle toho, jak spolu souvisejí v infrastruktuře.

Pro tento poslední krok je klíčová topologie. Když víme, co na čem závisí, dokážeme ze skupiny alertů odhadnout, který z nich je nejspíš příčinou. A víme také, které služby jsou zasažené.

Důležité je i to, aby každý krok trychtýře byl vidět a dal se vysvětlit. Pohotovost musí vědět, proč se nějaký alert neukázal, a vedoucí provozu musí mít možnost pravidla upravit. Jinak se z potlačení šumu stane černá skříňka, které nikdo nevěří, a lidé se vrátí ke sledování surových alertů.

Jak to řeší Eywo Stratum

Eywo Stratum přijímá události z monitoringu, ať už jde o Zabbix, Prometheus/Alertmanager, Checkmk, Grafanu nebo jiný zdroj přes generické API. Každou událost spáruje s položkou CMDB.

Na příchozí proud pak působí několik vrstev:

• deduplikace – opakované hlášení téhož problému se sloučí do jednoho alertu,
• detekce flappingu – stav, který se rychle mění tam a zpět, se rozpozná a nehlásí se při každé změně,
• pravidla filtrace a potlačení – co je známé a neškodné, se nemusí dostat k lidem,
• potlačení při probíhající změně – alerty z položek, na kterých běží schválená změna, se potlačí.

Zbývající alerty systém seskupí do situací podle topologie CMDB, podle služeb a podle času. U situace je uvedena pravděpodobná příčina, tedy položka, na které ostatní závisejí, a související změny. Pohotovost tak místo stovky alertů vidí jednu situaci s jasným dopadem.

Ze situace lze jedním krokem vytvořit incident, nebo ho nechat vznikat automaticky. Incident dostane navrženou zasaženou službu a řešitelský tým z CMDB. Pokud se problém po vyřešení vrátí, incident se znovu otevře místo zakládání nového. Celý trychtýř komprese šumu, tedy události, alerty, situace a incidenty, je vidět na jednom místě, takže je jasné, kde šum vzniká a kde se ztrácí.

Méně hluku, víc pozornosti

Cílem není, aby monitoring hlásil méně. Cílem je, aby k lidem došlo jen to, co vyžaduje jejich pozornost, a s kontextem, který potřebují k rozhodnutí. Pohotovost, která věří svým alertům, reaguje rychleji a klidněji. A ráno po noční službě se dá jít domů s pocitem, že se řešilo to podstatné.

Event management s korelací podle CMDB a kompresí šumu je součástí edice Business.