Prometheus + Grafana — moderní monitoring infrastruktury

Nagios nám sloužil roky. Pak přišly kontejnery, mikroslužby a dynamická infrastruktura — a Nagios se začal dusit. Přechod na Prometheus s Grafanou nebyl jen výměna nástroje. Byl to úplně jiný způsob myšlení o monitoringu.

Proč Prometheus¶

Nagios, Zabbix, Icinga — všechny fungují na principu push modelu. Agent na serveru posílá metriky do centrální instance. To funguje skvěle, dokud máte statickou infrastrukturu s pojmenovanými servery. Jakmile přijdou kontejnery, které žijí minuty a nemají stabilní hostname, push model se hroutí.

Prometheus funguje obráceně — pull model. Prometheus sám chodí na HTTP endpointy aplikací a sbírá metriky. Díky service discovery automaticky najde nové instance v Kubernetes, Consul nebo EC2. Kontejner nastartuje, Prometheus ho objeví, začne scrapovat. Kontejner zmizí, Prometheus přestane. Žádná konfigurace, žádné agenty.

Instrumentace — metriky z první ruky¶

Klíčový koncept Promethea je, že aplikace samy exportují metriky. Žádný externí agent, který parsuje logy nebo monitoruje porty. Aplikace vystavuje /metrics endpoint s aktuálními hodnotami — request count, latence, error rate, velikost queue.

# HELP http_requests_total Total HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET",path="/api/users",status="200"} 48293
http_requests_total{method="POST",path="/api/orders",status="201"} 7841
http_requests_total{method="GET",path="/api/users",status="500"} 23

# HELP http_request_duration_seconds Request latency
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.1"} 41209
http_request_duration_seconds_bucket{le="0.5"} 47891
http_request_duration_seconds_bucket{le="1.0"} 48102

Klientské knihovny existují pro Go, Java, Python, Node.js, .NET — prakticky cokoliv. Instrumentace jedné služby zabere hodinu. A od té chvíle máte metriky, které opravdu odpovídají tomu, co se v aplikaci děje.

PromQL — jazyk, který změní váš monitoring¶

Většina monitorovacích systémů umí zobrazit „CPU je na 87 %”. Prometheus umí odpovědět na otázky jako „jaký je 95. percentil latence za posledních 5 minut pro službu X, filtrovaný podle HTTP metody”.

# Error rate za posledních 5 minut
rate(http_requests_total{status=~"5.."}[5m])
  / rate(http_requests_total[5m]) * 100

# 95. percentil latence
histogram_quantile(0.95,
  rate(http_request_duration_seconds_bucket[5m])
)

# Top 5 nejpomalejších endpointů
topk(5,
  avg by (path) (rate(http_request_duration_seconds_sum[5m])
    / rate(http_request_duration_seconds_count[5m]))
)

PromQL má křivku učení. Ale jakmile ho pochopíte, nebudete chtít nic jiného. Agregace, filtry, rate výpočty — všechno v jednom dotazu. A ten samý dotaz použijete v dashboardu i v alert pravidle.

Grafana — vizualizace, která dává smysl¶

Prometheus má vlastní UI, ale je spartánské. Grafana je vizualizační vrstva, která z Prometheus dat dělá čitelné dashboardy. Grafy, heatmapy, tabulky, single-stat panely — všechno konfigurovatelné, všechno sdílitelné.

Náš setup: jeden dashboard per služba (RED metriky — Rate, Errors, Duration), jeden infrastructure dashboard (CPU, memory, disk, network) a jeden „war room” dashboard pro on-call inženýra s přehledem celého systému. Dashboardy verzujeme v Gitu jako JSON — provisioning přes Grafana API při deployi.

Alerting — Alertmanager v praxi¶

Alert pravidla definujeme v Prometheus configu. Když podmínka platí déle než stanovenou dobu, Prometheus pošle alert do Alertmanageru. Ten se stará o deduplikaci, groupování, silencing a routing — alert jde do Slacku, PagerDuty nebo e-mailu podle severity.

groups:
  - name: sla
    rules:
      - alert: HighErrorRate
        expr: |
          rate(http_requests_total{status=~"5.."}[5m])
          / rate(http_requests_total[5m]) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Error rate > 5 % na {{ $labels.instance }}"

Klíčové poučení: alertujte na symptomy, ne na příčiny. Nealertujte „CPU > 90 %”. Alertujte „latence p99 > 2 s” nebo „error rate > 5 %”. CPU může být na 90 % a všechno funguje. Ale když uživatelé čekají 5 sekund na odpověď, to je problém.

Kubernetes service discovery¶

V Kubernetes prostředí Prometheus automaticky objevuje pody přes Kubernetes API. Stačí přidat anotace na pod a Prometheus začne scrapovat. Žádná ruční konfigurace, žádné udržování seznamu targetů.

Node Exporter na každém nodu sbírá systémové metriky. cAdvisor (integrovaný v kubelet) poskytuje kontejnerové metriky. kube-state-metrics exportuje stav Kubernetes objektů — deploymenty, replica sety, pody. Dohromady máte kompletní obraz celého clusteru.

Co nás překvapilo¶

Retention — Prometheus není long-term storage. Defaultně drží data 15 dní. Pro dlouhodobé trendy potřebujete remote storage (Thanos, Cortex, VictoriaMetrics). My jsme začali s 30denní retencí a pro kapacitní plánování posíláme agregovaná data do InfluxDB.

High availability — Prometheus nemá nativní clustering. Řešení: dvě nezávislé instance scrapují stejné targety. Alertmanager má vlastní clustering pro deduplikaci. Funguje to, ale je to jiný model než „jeden cluster, který se stará o všechno”.

Cardinality — příliš mnoho unikátních label kombinací zabije Prometheus. Jeden tým přidal user_id jako label na HTTP metriky. 50 000 unikátních uživatelů × 10 metrik × 3 HTTP metody = exploze paměti. Label values musí být nízko-kardinalitní.

Monitoring jako kultura¶

Prometheus + Grafana nejsou jen nástroje — jsou to katalyzátory kulturní změny. Vývojáři přidávají metriky do kódu, protože chtějí vidět, jak se jejich služba chová v produkci. Ops tým má dashboardy místo ručního SSH. On-call inženýr vidí problém dřív, než zavolá zákazník. Začněte s jednou službou, instrumentujte ji, vytvořte dashboard. Zbytek přijde sám.