Hogyan terveznél meg egy alkalmazás monitoring rendszerét a semmiből?

Question

Accepted Answer

Kezdj **fentről lefelé haladva, azzal, amit a felhasználók éreznek**, nem alulról felfelé az infrastruktúrától. A legrelevanciább host flotta értéktelen, ha a kérések meghibásodnak, ezért kezd felhasználó-felé néző **SLI**-kkel — **latencia**, **hibaarány**, **elérhetőség** — majd add hozzá a négy aranyszabályt, végül az infrastruktúra metrikákat.

## A rétegzés, kívülről befelé

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

Ha csak CPU-t és lemez-használatot figyelsz (alulról felfelé), teljesen zöld lehet az állapot, miközben a felhasználók 500-as hibákat kapnak. Az SLI-k figyelése először (fentről lefelé) azt jelenti, hogy olyan **tüneti alapú riasztásokat** állítasz be, amelyeket a felhasználók ténylegesen éreznek, majd a golden signalok és infra métrикák segítségével deríted ki az okot.

## A pipeline: instrumentáció → gyűjtés → dashboard → riasztás

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

## Egy konkrét kiindulópont

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

Határozz meg egy **SLO**-t minden SLI-re (pl. 99,9%-os elérhetőség, p99 < 300ms), dashboardozd őket, és riassz, amikor az SLO veszélybe kerül — nem minden apró ingadozáson.

## Miért számít

Az alulról felfelé épített monitoring azt mondja meg, hogy a lemez 80%-os, de nem azt, hogy az ügyfelek nem tudnak fizetni. A felhasználó-felé néző SLI-kből indulva minden dashboard és riasztás a tényleges felhasználói hatáshoz köthető, alacsony a zaj, és világos a drill-down útvonal (tünet → golden signal → infra ok), amikor valami elromlik.