Cum ai proiecta monitoringul pentru o aplicație de la zero?

Question

Cum ai proiecta monitoringul pentru o aplicație de la zero?

Accepted Answer

Pornește **de sus cu ceea ce simt utilizatorii**, nu de jos dinspre infrastructură. Cea mai fiabilă flotă de gazde este inutilă dacă cererile eșuează, deci începe cu **SLI**uri **orientate către utilizator — **latency**, **error rate**, **availability** — apoi adaugă cele patru semnale de aur, apoi metricile infra la sfârșit.

## Stratificarea, de la utilizator spre interior

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

Dacă doar supraveghezi CPU și disk (de jos în sus), poți fi complet verde în timp ce utilizatorii primesc 500-uri. Supravegherea SLI-urilor mai întâi (de sus în jos) înseamnă că alertezi pe **simptomele pe care utilizatorii le simt de fapt**, apoi faci drilling în semnalele de aur și infra pentru a găsi cauza.

## Conducta: instrument → collect → dashboard → alert

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

## Un punct de plecare concret

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

Definește un **SLO** pe fiecare SLI (de exemplu, disponibilitate 99,9%, p99 < 300ms), pune-le pe dashboard și alertează atunci când SLO-ul este în pericol — nu la fiecare fluctuație.

## De ce conteaza

Monitoringul construit de jos în sus îți spune că un disk este 80% plin, dar nu că clienții nu pot finaliza cumparatura. Pornirea de la SLI-uri orientate către utilizator leagă fiecare dashboard și alertă la impactul real al utilizatorului, reduce zgomotul și furnizează o cale clară de investigație (simptom → semnal de aur → cauza infra) când ceva se rupe.