Jak byste navrhli monitorování aplikace od začátku?

Question

Accepted Answer

Začněte **shora dolů tím, co cítí uživatelé**, ne zdola nahoru od infrastruktury. Nejvíce spolehlivá flotila hostitelů je k ničemu, pokud požadavky selhávají, takže začněte s uživatelsky orientovanými **SLIs** — **latencí**, **chybovostí**, **dostupností** — poté přidejte čtyři zlaté signály, nakonec metriky infrastruktury.

## Vrstvení, od uživatele dovnitř

```text
1. USER-FACING SLIs   → what the user experiences (latency, errors, availability)
2. GOLDEN SIGNALS     → latency, traffic, errors, saturation per service
3. INFRA METRICS      → CPU, memory, disk, network (causes, not symptoms)
```

Pokud pozorujete pouze CPU a disk (zdola nahoru), můžete být úplně zelení, zatímco uživatelé dostávají 500s. Pozorování SLIs nejdříve (shora dolů) znamená, že upozorňujete na **příznaky, které uživatelé skutečně cítí**, poté se podrobněji podíváte na zlaté signály a infrastrukturu, abyste našli příčinu.

## Potrubí: instrumentuj → sbírej → zobraz → varuj

```text
INSTRUMENT  app emits metrics/logs/traces (e.g. request_duration_seconds histogram)
   ↓
COLLECT     a TSDB scrapes/ingests them (Prometheus, Datadog agent)
   ↓
DASHBOARD   visualize SLIs + golden signals (Grafana) for humans to read
   ↓
ALERT       fire on SLO violations / burn rate, routed to on-call
```

## Konkrétní výchozí bod

```promql
# Availability SLI: fraction of requests that succeed
sum(rate(http_requests_total{status!~"5.."}[5m]))
  / sum(rate(http_requests_total[5m]))

# Latency SLI: p99 request latency
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))
```

Definujte **SLO** pro každé SLI (například dostupnost 99,9%, p99 < 300ms), zobrazte je na dashboardu a varujte, když je SLO ohroženo — ne při každé fluktuaci.

## Proč to je důležité

Monitorování postavené zdola nahoru vám řekne, že disk je zaplněn na 80%, ale ne že zákazníci nemohou dokončit nákup. Začátek s uživatelsky orientovanými SLIs vázne každý dashboard a varování zpět na skutečný dopad na uživatele, udržuje hluk nízký a poskytuje jasnou cestu k analýze (příznak → zlatý signál → příčina infrastruktury), když se něco rozbije.