Prediktivní monitoring ML

Proč prediktivní monitoring: od reaktivních alarmů k předvídání incidentů

Prediktivní monitoring využívá statistické metody a strojové učení k odhalování odchylek dříve, než se projeví incident. Oproti tradičním prahovým alarmům, které reagují až na porušení limitu, pracuje s trendem, sezónností a kontextem (závislosti mezi metrikami). V prostředích se stovkami služeb a krátkými releasy je to klíčový krok k vyšší dostupnosti, nižšímu MTTR a lepší optimalizaci nákladů.

Datový základ: časové řady, cardinalita a kvalita metadat

Úspěch začíná u dat. Prediktivní modely potřebují stabilní časové řady, rozumnou granularitu a kvalitní popisky.

• Granularita: pro aplikační metriky obvykle 10–60 s; pro infrastrukturu 1–5 min. Příliš hrubá ztrácí signál, příliš jemná zvyšuje šum a náklady.
• Kardinalita labelů (Prometheus): sledujte explozivní kombinace (např. user_id v labelu). Omezujte je na úrovni exportérů či relabelingu.
• Missing data: modely musí znát „ticho” (down exportéru) vs. „nulu”. Používejte sentinelové hodnoty a explicitní metriky up.
• Kontext: metadata o releasu, regionech, feature flagách; pomohou vysvětlit odchylku a snížit falešné poplachy.

Modelové přístupy: od statistiky k hlubokému učení

Neexistuje jeden univerzální model. Kombinujte dle typu metriky, šumu a požadavků na vysvětlitelnost.

• Statistické baseline: klouzavé průměry, robustní medián + MAD, Holt–Winters (sezóny), ARIMA/SARIMA pro krátkodobé predikce.
• Regresní predikce: prophet/aditivní modely pro výraznou sezónnost a svátky, regresní stromové metody pro multivariační závislosti.
• Detekce odlehlých hodnot: Isolation Forest, One-Class SVM, Random Cut Forest; vhodné pro „nové” anomálie bez labelů.
• Sekvenční modely: LSTM/GRU/Temporal Convolution pro komplexní dynamiku; náročnější na data i MLOps.
• Hybridy: statistická predikce trendu + učení reziduí (stacking) → nižší falešná pozitivita.

Feature engineering pro provozní metriky

Dobré příznaky zjednoduší model a zlepší stabilitu.

• Dezagrace trendu/sezóny: odstraňte denní a týdenní periodicitu (např. STL dekompozice); učte model na reziduích.
• Lagové a rollup příznaky: hodnoty T-1, T-5, T-10, roll min/max/std; pomáhají zachytit náběh incidentu.
• Relativní metriky: poměr chybovosti k provozu (5xx/req), CPU per pod, P95 latence / P50; odolnější vůči změnám zátěže.
• Kontextové příznaky: release window, region, instance type, autoscaling level.

Integrace s Prometheus: PromQL, predikce a alerting

PromQL nabízí jednoduché prediktivní funkce, které lze kombinovat s ML mimo Prometheus.

• Krátkodobá projekce: predict_linear(http_requests_total[10m], 15m) – lineární extrapolace do 15 minut.
• Sezónní vyhlazení: holt_winters(series[6h], 0.1, 0.003) – adaptivní smoothing pro hladké baseline.
• Multivládno alertů (SRE): burn rate pro SLO – krátké i dlouhé okno současně; snižuje flapping a zachová citlivost.
• ML sidecar: model běží vedle TSDB, počítá predikci/anomálie a publikuje je jako nové metriky (pushgateway či vlastní exporter). Alertmanager pak spouští notifikace nad „anomálie > práh”.

Integrace se Zabbix: zabudované funkce a napojení modelů

Zabbix poskytuje nativní funkce pro časové řady a spouštěče, a zároveň webhooky pro externí ML.

• Holt–Winters, trend, forecast: využijte vestavěné funkce pro adaptivní baseline a predikci „time to threshold”.
• Trigger expression: kombinujte statistické odchylky s kontextem (údržba, release tag) pro snížení falešných alarmů.
• Externí ML: periodický export history do datového jezera; model vrací skóre/anomálie zpět přes trapper item nebo HTTP agent.

Prahování a rozhodování: od skóre k akci

Detekce bez akce je akademické cvičení. Definujte převod anomálního skóre na incident a nápravný krok.

• Práh per službu: odlišná tolerance pro latenci plateb vs. sporadické 5xx ve stagingu.
• Adaptivní prahy: škálujte podle úrovně provozu (např. chybovost > baseline + k·σ).
• Alert suppression: během releasů / známých událostí potlačte alerty (maintenance okna, feature flagy).
• Auto-remediation: pro opakovatelné vzory připojte „runbook actions” (restart podu, scale-out, flush cache) s bezpečnostními pojistkami.

Hodnocení kvality: metriky, backtesting a cost–benefit

Vyhodnocení prediktivního monitoringu je jiné než u klasických klasifikátorů.

• Včasnost (lead time): kolik minut před incidentem vznikl alarm.
• Falešné poplachy: precision, false positive rate, „alert fatigue” na on-call.
• Pokrytí incidentů: recall na historických post-mortem případech.
• Backtesting: walk-forward validace přes měsíce provozu; stabilita napříč sezónami.
• Ekonomika: porovnejte cenu GPU/CPU, úložiště a engineering času s ušetřeným výpadkem (SLA penalty, reputace).

MLOps pro monitoring: verzování, drift a výměna modelů

Životní cyklus modelu je stejně důležitý jako jeho přesnost.

• Verzování: ukládejte artefakty (model, featury, normalizační statistiky) a data schema.
• Datový a konceptuální drift: sledujte posun distribucí (PSI, KL divergence) a kvalitu predikcí; automatizujte re-trénink.
• Canary/Shadow deploy: nové modely nejprve vyhodnocujte „ve stínu” proti produkční baseline.
• Observabilita modelu: vlastní metriky (latence inference, hit-rate, lead time, chybovost) do Promethea.

Architektura řešení: datový tok od sběru po alert

Příklad referenčního pipeline:

1. Sběr: exportéry (Node, cAdvisor, aplikační), Zabbix agenty, logy → TSDB/Message bus.
2. Transformace: downsampling, imputace mezer, featury, sezónní dekompozice.
3. Model: inference nad oknem (např. posledních 2 h, krok 1 min), výstup = predikce + interval spolehlivosti / anomální skóre.
4. Publikace: výsledky zpět jako metriky (model_prediction, anomaly_score).
5. Alerting: pravidla v Alertmanageru/Zabbix triggeru, směrování a deduplikace, runbook.

Specifika metrik: latence, chybovost, kapacita, business KPI

• Latence: modelujte P95/P99 zvlášť; změny tvaru rozdělení (heavytail) vyžadují robustní metriky.
• Chybovost: predikujte error budget burn rate v čase; kombinujte krátké a dlouhé okno.
• Kapacita: CPU/RAM/disk IOPS – predikce vyčerpání („time-to-full”) pro proaktivní škálování.
• Business KPI: objednávky/min, úspěšné platby; propojte s incidenty (dopad na tržby).

Praktické vzory nasazení: sidecar, mikroservisy a data lake

• Sidecar inference: lehký model běžící vedle služby; nízká latence, lokální kontext.
• Centralizovaná inference: samostatná služba nad Kafka/HTTP; lepší škálování a správa verzí.
• Data lake: historická data pro trénink; featury materializované v feature store.

Řízení rizik: vysvětlitelnost, bezpečnost a compliance

• Vysvětlitelnost: SHAP/feature importance pro stromové modely; důležitá u rozhodnutí s dopadem na SRE procesy.
• Bezpečnost: izolujte inference službu, rate-limit, auditní logy přístupu k metrikám.
• Compliance: uchovávání metrik a alertů dle interních politik; anonymizace citlivých labelů.

Organizační dopady: role SRE, Data/ML a vlastnictví modelu

Jasně definujte zodpovědnosti: kdo model trénuje, kdo provozuje inference a kdo reaguje na alerty. Runbooky musí odrážet prediktivní signály (např. „anomálie latence API v regionu eu-central-1, lead time ~12 min”) a vést k preventivním krokům (scale-out, rollback, circuit breaker).

Roadmap zavedení: od pilotu k plošnému provozu

1. Výběr metrik: 3–5 kritických SLI (latence, chybovost, saturace) s čistou historií.
2. Pilotní model: statistická baseline + jednoduchá anomální detekce; definujte metriky úspěchu (lead time, precision).
3. Integrace alertingu: Alertmanager/Zabbix s deduplikací a potlačením během releasů.
4. Iterace: přidejte kontextové featury, hybridní model, auto-remediation na triviální zásahy.
5. MLOps: verzování, monitoring driftu, canary release modelů, pravidelný re-trénink.

Nejčastější proti-vzorce a jak se jim vyhnout

• Přeučení na šum: příliš komplexní model bez regularizace a cross-validace.
• Ignorování sezónnosti: absence dekompozice vede k poplachům každý víkend či noc.
• Bez runbooku: alert bez akčního kroku plýtvá on-call kapacitou.
• „Set and forget”: modely bez sledování driftu postupně degenerují.
• Vendor-lock: uzavřené black-boxy bez exportu metrik a verzování rozhodování.

Závěr: prediktivní monitoring jako součást SRE kultury

Prediktivní monitoring není jen „lepší alerting”, ale kultura práce s daty: kvalitní časové řady, promyšlené featury, vhodné modely, měření přínosu a ukotvení v procesech SRE. V kombinaci s Prometheem, Zabbixem a osvědčenými MLOps praktikami pomůže zkrátit dobu do detekce, předejít výpadkům a zefektivnit provoz od infrastruktury po byznysové služby.