Kako bi zasnovali spremljanje aplikacije od začetka?

Question

Accepted Answer

Začnite **od zgoraj navzdol od tega, kar občutijo uporabniki**, ne pa od spodaj navzgor od infrastrukture. Najbolj zanesljiva gostitelska flota je neuporabna, če zahtevki ne uspevajo, zato začnite z uporabniku dostopnimi **SLI** — **zakasnitev**, **stopnja napak**, **razpoložljivost** — nato dodajte štiri zlate signale, nato infrastrukturne metrike nazadnje.

## Plastenje, od uporabnika navznoter

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

Če opazujete samo CPU in disk (od spodaj navzgor), lahko ste povsem zeleni, medtem ko uporabniki dobijo 500s. Če opazujete SLI prve (od zgoraj navzdol), pomeni, da opozarjate na **simptome, ki jih uporabniki dejansko občutijo**, nato pa se poglabljate v zlate signale in infrastrukturo, da najdete vzrok.

## Cevovod: instrumentacija → zbiranje → nadzorna plošča → opozarjanje

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

## Konkreten začetni položaj

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

Definirajte **SLO** za vsak SLI (npr. 99,9% razpoložljivosti, p99 < 300ms), ju prikaži na nadzorni plošči in opozori, ko je SLO v nevarnosti — ne pa pri vsakem nihanju.

## Zakaj je to pomembno

Spremljanje, zgrajeno od spodaj navzgor, ti pove, da je disk 80% poln, ne pa da kupci ne morejo zaključiti nakupa. Začetek s SLI, dostopnimi uporabniku, veže vsako nadzorno ploščo in opozorilo nazaj na pravo uporabnikovo učinkovitost, drži hrup nizek in daje jasen pot vrtanja (simptom → zlati signal → vzrok infrastrukture), ko se kaj zlomi.