Prometheus a Grafana: moderní stack pro monitorování metrik

Proč Prometheus a Grafana tvoří moderní monitorovací stack

Prometheus a Grafana se staly de facto standardem pro monitorování cloud-native a hybridních prostředí. Prometheus poskytuje časové řady metrik s výkonným dotazovacím jazykem PromQL a modelem „pull“ se service discovery, zatímco Grafana nabízí univerzální vizualizace, správu alertů a observabilitu napříč metrikami, logy a trasováním. Kombinace otevřených standardů (OpenMetrics), bohatého ekosystému exporterů a horizontální škálovatelnosti (Cortex/Thanos/Mimir) umožňuje pokrýt vše od zařízení IoT přes clustery Kubernetes až po podnikové datové sály.

Architektura stacku a datové toky

Expozice metrik: aplikace a služby publikují endpoint /metrics ve formátu Promethea (obvykle textový OpenMetrics).
Scrape: Prometheus v pravidelných intervalech „stahuje“ metriky podle scrape_configs a ukládá je do lokální TSDB.
Alerting: pravidla v Prometheu generují alerty, které se směrují do Alertmanageru. Ten zajišťuje deduplikaci, potlačování a směrování.
Vizualizace: Grafana čte data přímo z Promethea nebo z dlouhodobého úložiště (Thanos/Cortex/Mimir), vykresluje panely a spravuje notifikace.
Logy & trasování (volitelné): Loki (logy) a Tempo/Jaeger (trasování) propojují metriky s kontextem událostí a trasování.

Datový model Promethea: metriky, štítky a časové řady

Časová řada = název metriky + sada štítků (klíč–hodnota) → jedinečná identita řady.
Typy metrik: counter (monotónně rostoucí), gauge (libovolně se měnící), histogram (rozdělení do intervalů), summary (percentily/kvantily vypočítávané na klientovi).
Štítky definují dimenze (např. job, instance, pod, path) a umožňují agregace bez nutnosti používat složité názvy metrik.
Kardinalita: počet jedinečných kombinací štítků; klíčový faktor ovlivňující nároky na paměť a výkon.

Expozice a exportéry

Klientské knihovny: instrumentace aplikací (Go, Java, Python, Ruby, .NET). Pro latence upřednostňujte histogramy a pro chybovost countery.
Node Exporter: metriky operačního systému (CPU, paměť, I/O, souborové systémy, síť, hardwarové senzory).
Blackbox Exporter: syntetické testy (HTTP/TCP/ICMP/TLS).
SNMP Exporter: mapování OID → metriky pro síťové prvky a starší systémy.
Windows Exporter a další exportéry pro konkrétní oblasti (NGINX, HAProxy, PostgreSQL, Redis, Kafka…).
Pushgateway: pro krátkodobé dávkové úlohy (používejte střídmě; nenahrazuje model pull).

Service Discovery a relabeling

Prometheus podporuje dynamické service discovery (Kubernetes, Consul, EC2, Azure, GCE, statické seznamy). Relabeling upravuje a filtruje cíle ještě před jejich stahováním:

Selektivní zahrnutí nebo odstranění cílů podle štítků (např. kubernetes_namespace, app).
Normalizace a odvození štítků (__meta_kubernetes_pod_annotation_* → štítky pod/service).
Ochrana před příliš vysokou kardinalitou: odstraňte štítky s vysokou proměnlivostí (např. dynamické path, query).

PromQL: dotazovací jazyk a analytické postupy

Rychlosti a derivace: rate(http_requests_total[5m]), irate() pro krátkodobé špičky.
Agregace: sum by (status) (...) , avg_over_time(), quantile_over_time().
Latence z histogramů: histogram_quantile(0.95, sum by (le)(rate(http_request_duration_seconds_bucket[5m]))).
Spojení a operátory: on(), group_left / group_right pro obohacení řad.
Časová okna: vektorové selektory [5m], offset pro porovnání s minulostí.

Pravidla: recording rules a alerting rules

Recording rules předpočítávají náročné dotazy do nových metrik → šetří CPU a stabilizují panely.
Alerting s podmínkami, dobou trvání for a štítky (severity, team). Zásada: pokud je informace důležitá pro člověka, vytvořte alert; jinak panel.
Uspořádejte pravidla do skupin (groups) a nastavte konzervativní evaluation_interval, aby bylo chování předvídatelné.

Alertmanager: směrování, deduplikace a potlačování

Strom směrování: pravidla podle štítků (např. severity=critical → pohotovostní služba; env=dev → pouze chatops).
Inhibition: potlačení méně důležitých alertů, když je aktivní nadřazený alert (např. host down potlačí service down).
Umlčení: dočasné potlačení alertů s komentářem a dobou platnosti.
Integrace s e-mailem, Slackem/Teams, PagerDuty/Opsgenie a webhooky (SOAR).

Grafana: model panelů, proměnné a šablony

Proměnné (templating): dynamické filtry podle štítků ($cluster, $namespace) pro opakované použití dashboardů.
Transformace: slučování řad, výpočty odvozených sloupců, redukce (reduce) na jedinou hodnotu.
Anotace: události vydání verzí, incidenty; vizuální korelace metrik s událostmi.
Grafana Alerting: jednotný systém alertů napříč datovými zdroji; contact points, notification policies, silences.

Metriky observability: USE, RED a SLO/chybový rozpočet

USE (Utilization, Saturation, Errors) pro infrastrukturu (CPU, I/O, paměť, hloubka fronty).
RED (Rate, Errors, Duration) pro služby a API.
SLO: cíle dostupnosti a latence; alerty podle burn rate (např. v oknech 2 a 6 hodin) navázané na chybový rozpočet.

Monitorování Kubernetes: kube-state-metrics, cAdvisor a síť

kube-state-metrics: stav objektů (Deployments, DaemonSets, Jobs, kvóty, limity).
cAdvisor/CRI: metriky běhového prostředí kontejnerů (CPU, paměť, souborové systémy).
Síť: metriky CNI, exportéry eBPF (Cilium Hubble metrics), metriky apiserveru a scheduleru.
kube-prometheus-stack (Helm): názorově koncipovaný balík Prometheus, Alertmanager, Grafana, pravidel a dashboardů.

Škálování, dlouhodobé uchovávání a vysoká dostupnost

Replikace Promethea: nezávislé instance pro vysokou dostupnost (se sdílenými cíli scrape) + deduplikace v Thanos/Cortex/Mimir.
Thanos/Cortex/Mimir: horizontální dělení zátěže, objektové úložiště (S3/GCS), downsampling a globální dotazování.
Remote write/read: export do systémů pro dlouhodobé uchovávání nebo centralizovaných platforem observability.
Retence a kompakce: pečlivě nastavte --storage.tsdb.retention.time, diskové IOPS a samostatné disky pro WAL.

Výkon a náklady: kardinalita, limity a plánování zdrojů

Kontrola kardinality: vyhněte se štítkům s vysokou entropií (ID požadavků, ID uživatelů, URL query).
Vzorkování: u vysokofrekvenčních metrik zvažte delší intervaly scrape nebo předběžné agregace (recording rules).
Dotazy v Grafaně: používejte $__rate_interval a bezdůvodně se vyhýbejte offset s dlouhými časovými okny.
Velikost clusteru: dimenzujte CPU/RAM podle počtu řad a frekvence scrape; sledujte Prometheus TSDB head a query time.

Bezpečnost: izolace, TLS a víceklientská architektura

Autentizace: reverzní proxy s OIDC (Grafana jej podporuje nativně), mTLS pro interní přístup, autorizace prostřednictvím rolí v Grafaně.
Síťová segmentace: soukromé cíle scrape, zákaz přístupu k /metrics z internetu, network policies v K8s.
Víceklientská architektura: Thanos/Cortex/Mimir s oddělenými tenanty, limity kardinality a dotazů pro jednotlivé tenanty.

Standardy a formáty: OpenMetrics a exempláře

OpenMetrics: standardizovaný formát zahrnující metadata o typech a exempláře.
Exempláře: propojení metrik s konkrétním ID trace → rychlý přechod z panelu k trasování (Tempo/Jaeger).

Integrace logů a trasování: Loki a Tempo

Loki: logy indexované podle štítků (nikoli podle celého textu). Propojení s panely (přechod od metrik k logům).
Tempo: ukládání tras a dotazování nad nimi; span metrics vytvářejí metriky z trasování pro RED.
OpenTelemetry: jednotná instrumentace metrik, logů i trasování.

Migrace ze Zabbixu a hybridní soužití

Soužití: Zabbix pro SNMP a tradiční servery, Prometheus pro cloud-native prostředí; sjednocení v Grafaně pomocí více datových zdrojů.
Postupná migrace: nejprve infrastruktura (Node/Blackbox), poté aplikace; souběžné alertování s postupným vypínáním starých pravidel.
Mapování: převod klíčových metrik SLA na RED/USE a alerty SLO.

Osvědčené postupy pro návrh dashboardů

Hierarchie: přehled (SLO/SLA) → doména (API, databáze, fronty) → detail (instance).
Konzistence: stejné osy a názvy, barvy podle významu (chybovost, latence, propustnost).
Čitelnost: latence p95/p99, rate chyb, saturace; omezení „grafického šumu“.

Nejčastější antipatterny a jejich náprava

Explodující kardinalita (štítky user_id, session) → odstranit nebo normalizovat; agregovat dříve.
Únava z alertů: příliš podrobné alerty → zavést inhibition, úrovně závažnosti a schéma řízené SLO.
Nesprávné použití Pushgateway: dlouhodobé uchovávání metrik → přejít na model pull nebo zajistit rychlou expiraci dávkových metrik.
Rozrůstání dashboardů: duplicitní panely → standardizovat šablony, spravovat repozitář dashboardů a provádět revize.

Provisioning, GitOps a testování pravidel

Provisioning: definujte datové zdroje, složky a dashboardy jako kód (JSON/YAML) a spravujte je v Gitu.
GitOps: používejte ArgoCD/Flux k nasazování Promethea, Alertmanageru a Grafany; změny provádějte prostřednictvím PR.
Testy: jednotkové testy pravidel PromQL (např. promql-unit-testing), validace stromu alertů a simulace scénářů.

Plán implementace v podniku

Inventura: cíle (SLO), zdroje metrik, exportéry, síťové limity, retence.
Minimální životaschopná observabilita: Node/Blackbox, základní RED/USE, alerty na burn rate a saturaci.
Kubernetes a aplikace: kube-prometheus-stack, instrumentace služeb, integrace trasování/logů.
Škálování: Thanos/Cortex/Mimir, víceklientská architektura, objektové úložiště, vysoká dostupnost.
Správa a řízení: standardy štítků, revize pravidel, provisioning jako kód, pravidla přístupu.

Závěr: sjednocená observabilita jako konkurenční výhoda

Prometheus a Grafana poskytují solidní, otevřený a škálovatelný základ pro monitorování moderních systémů. Správně navržený model metrik, disciplinovaná práce s kardinalitou, alertování orientované na SLO a automatizovaný provisioning vytvářejí observabilitu, která zkracuje MTTR, snižuje provozní rizika a umožňuje týmům dodávat rychleji a ve vyšší kvalitě. Rozšíření o logy a trasování pak doplňuje úplný obraz systému v reálném čase.