Prediktivní monitoring strojového učení

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 překroč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, kardinalita a kvalita metadat

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

Granularita: u aplikačních metrik obvykle 10–60 s; u infrastruktury 1–5 min. Příliš hrubá granularita 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 přejmenovávání (relabelingu).
Chybějící data: modely musí rozlišovat „ticho” (nedostupnost exportéru) od „nuly”. Používejte sentinelové hodnoty a explicitní metriky up.
Kontext: metadata o releasu, regionech, feature flagách; pomáhají vysvětlit odchylky a snížit falešné poplachy.

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

Neexistuje jeden univerzální model. Kombinujte podle 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 štítků.
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

Kvalitní příznaky zjednoduší model a zlepší stabilitu.

Dekompozice 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 na 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í vyhlazení pro hladkou baseline.
Víceúrovňový alerting (SRE): burn rate pro SLO – krátké i dlouhé časové okno současně; snižuje flapping a zachovává citlivost.
ML sidecar: model běží vedle TSDB, počítá predikce a 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 historie do datového jezera; model vrací skóre a anomálie zpět přes trapper item nebo HTTP agenta.

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

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

Práh pro každou službu: odlišná tolerance pro latenci plateb vs. sporadické 5xx ve stagingu.
Adaptivní prahy: škálujte podle úrovně provozu (např. chybovost > baseline + k·σ).
Potlačení alertů: během releasů či známých událostí potlačte alarmy (okna údržby, feature flagy).
Auto-remediace: 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 se liší od klasických klasifikátorů.

Včasnost (lead time): kolik minut před incidentem vznikl alarm.
Falešné poplachy: precision, false positive rate, „alert fatigue” u on-call služeb.
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 náklady na GPU/CPU, úložiště a inženýrský čas s ušetřenými výpadky (pokuty za SLA, 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, příznaky, normalizační statistiky) a datové schéma.
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í pipeline:

Sběr: exportéry (Node, cAdvisor, aplikační), Zabbix agenti, logy → TSDB/message bus.
Transformace: downsampling, imputace mezer, příznaky, sezónní dekompozice.
Model: inference nad oknem (např. posledních 2 h, krok 1 min), výstup = predikce + interval spolehlivosti / anomální skóre.
Publikace: výsledky zpět jako metriky (model_prediction, anomaly_score).
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; příznaky materializované ve feature store.

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

Vysvětlitelnost: SHAP/feature importance pro stromové modely; klíčové u rozhodnutí s dopadem na SRE procesy.
Bezpečnost: izolujte inference službu, rate-limitujte požadavky, 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

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

Nejčastější proti-vzory 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á kapacitou on-call.
„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é příznaky, vhodné modely, měření přínosu a zakotvení 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.