Jak zaprojektowałbyś monitoring aplikacji od zera?

Question

Accepted Answer

Zacznij **od góry, od tego, co czują użytkownicy**, a nie od dołu, od infrastruktury. Najbardziej niezawodna flota hostów jest bezwartościowa, jeśli żądania się nie powodzą, więc zacznij od **SLI** skierowanych do użytkownika — **latency**, **error rate**, **availability** — a następnie dodaj cztery złote sygnały i ostatecznie metryki infrastruktury.

## Warstwy, od użytkownika na wewnątrz

```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)
```

Jeśli obserwujesz tylko CPU i disk (od dołu), możesz być całkowicie zielony, podczas gdy użytkownicy otrzymują 500. Obserwowanie SLI na pierwszym miejscu (od góry) oznacza, że wystawiasz alerty na **objawy, które użytkownicy faktycznie odczuwają**, a następnie drążysz w dół w złote sygnały i infrastrukturę, aby znaleźć przyczynę.

## Dlaczego to ważne

```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
```

## Konkretny punkt początkowy

```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])))
```

Zdefiniuj **SLO** dla każdego SLI (np. dostępność 99,9%, p99 < 300ms), umieść je na pulpicie nawigacyjnym i wyślij alert, gdy SLO jest zagrożone — nie przy każdym wahaniu.

## Dlaczego to ważne

Monitoring zbudowany od dołu mówi ci, że dysk jest w 80% pełny, ale nie mówi, że klienci nie mogą dokonać zakupu. Rozpoczęcie od SLI skierowanych do użytkownika wiąże każdy pulpit nawigacyjny i alert z rzeczywistym wpływem na użytkownika, zmniejsza szum i zapewnia wyraźną ścieżkę przeglądania (objaw → złoty sygnał → przyczyna infrastruktury), gdy coś się psuje.