Comment concevriez-vous la surveillance d'une application à partir de zéro ?

Question

Accepted Answer

Commencez **de haut en bas par ce que les utilisateurs ressentent**, pas de bas en haut à partir de l'infrastructure. La flotte d'hôtes la plus fiable est inutile si les demandes échouent, donc commencez par les **SLI** orientés vers l'utilisateur — **latence**, **taux d'erreur**, **disponibilité** — puis ajoutez les quatre signaux clés, puis les métriques infra en dernier.

## La hiérarchie, de l'utilisateur vers l'intérieur

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

Si vous ne surveillez que le CPU et le disque (de bas en haut), vous pouvez être entièrement au vert tandis que les utilisateurs reçoivent des 500. Surveiller d'abord les SLI (de haut en bas) signifie que vous alertez sur les **symptômes que les utilisateurs ressentent réellement**, puis vous explorez les signaux clés et l'infra pour trouver la cause.

## Le pipeline : instrumenter → collecter → tableau de bord → alerter

```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 point de départ 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])))
```

Définissez un **SLO** sur chaque SLI (par exemple 99,9 % de disponibilité, p99 < 300 ms), créez des tableaux de bord et alertez lorsque le SLO est en risque — pas à chaque variation.

## Pourquoi c'est important

La surveillance construite de bas en haut vous dit qu'un disque est plein à 80 % mais pas que les clients ne peuvent pas finaliser leurs achats. Commencer par les SLI orientés vers l'utilisateur relie chaque tableau de bord et chaque alerte à l'impact réel sur les utilisateurs, réduit le bruit et offre un chemin d'exploration clair (symptôme → signal clé → cause infra) lorsque quelque chose se casse.