Les 4 "golden signals" (Google SRE book) : le strict minimum à surveiller pour N'IMPORTE QUEL service.

LATENCE     -> combien de temps prend une requête (séparer succès et échecs : un 500 rapide fausse la moyenne)
TRAFIC      -> quelle est la demande sur le système (req/s, connexions actives, messages/s en file)
ERREURS     -> quel taux de requêtes échoue (explicite : 5xx ; ou implicite : 200 avec contenu incorrect)
SATURATION  -> à quel point les ressources sont pleines (CPU, mémoire, connexions DB, file d'attente)

# Les 4 golden signals traduits en PromQL pour un service HTTP typique

# 1. Latence — SÉPARER succès et échecs, sinon la moyenne ment
histogram_quantile(0.95,
  sum(rate(http_request_duration_seconds_bucket{status!~"5.."}[5m])) by (le))   # P95 des SUCCÈS uniquement

# 2. Trafic
sum(rate(http_requests_total[5m]))                                              # requêtes/seconde, tous statuts

# 3. Erreurs
sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

# 4. Saturation — dépend fortement du système, exemples typiques :
sum(pg_stat_activity_count) / pg_settings_max_connections                        # % connexions PostgreSQL utilisées
avg(rate(process_cpu_seconds_total[5m])) by (instance)                            # CPU par instance
queue_depth / queue_max_capacity                                                  # remplissage d'une file de tâches

Golden signals appliqués à des systèmes NON-HTTP (le principe se généralise) :

File de messages (Kafka/RabbitMQ)
  Latence    -> temps entre publication et consommation d'un message
  Trafic     -> messages publiés/seconde
  Erreurs    -> messages en dead-letter-queue
  Saturation -> profondeur de la file, lag du consumer group

Base de données
  Latence    -> temps d'exécution des requêtes (p95 par type de requête)
  Trafic     -> requêtes/seconde, transactions/seconde
  Erreurs    -> requêtes en échec, deadlocks
  Saturation -> connexions actives / max, cache hit ratio, réplication lag

{
  "title": "Golden Signals — mon-api",
  "panels": [
    { "title": "Latence (P95, succès uniquement)", "targets": [
      { "expr": "histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{status!~\"5..\"}[5m])) by (le))" }
    ]},
    { "title": "Trafic (req/s)", "targets": [
      { "expr": "sum(rate(http_requests_total[5m]))" }
    ]},
    { "title": "Taux d'erreur (%)", "targets": [
      { "expr": "sum(rate(http_requests_total{status=~\"5..\"}[5m])) / sum(rate(http_requests_total[5m])) * 100" }
    ]},
    { "title": "Saturation DB (% connexions)", "targets": [
      { "expr": "sum(pg_stat_activity_count) / pg_settings_max_connections * 100" }
    ]}
  ]
}

Pourquoi ces 4 signaux et pas plus, en dashboard "de garde" (on-call) :

- Un dashboard avec 40 panels est INUTILISABLE à 3h du matin sous pression.
- Les golden signals répondent à la question immédiate : "le système va-t-il mal, et pourquoi, en 10 secondes ?"
- Les dashboards détaillés (par composant) viennent APRÈS, une fois le signal général identifié comme anormal.