Les Golden Signals représentent le framework de monitoring le plus influent en Site Reliability Engineering. Codifiés par Google, ces quatre métriques offrent une vision condensée mais complète de la santé d'un service.
En se concentrant sur la latence, le trafic, les erreurs et la saturation, les équipes évitent la surcharge informationnelle tout en couvrant les problèmes impactant l'utilisateur.
Que sont les Golden Signals en SRE ?
Les Golden Signals constituent un ensemble de quatre métriques considérées comme les indicateurs les plus importants de la santé d'un système distribué.
Les quatre signaux
| Signal | Description | Exemple de métrique |
|---|---|---|
| Latence | Temps de traitement des requêtes | p99 response time |
| Trafic | Volume de demandes | Requêtes par seconde |
| Erreurs | Taux de requêtes échouées | % HTTP 5xx |
| Saturation | Utilisation des ressources | % CPU, mémoire |
Latence
La latence mesure le temps nécessaire pour traiter une requête. Elle capture directement la perception de performance par l'utilisateur.
# Latence p99 sur les 5 dernières minutes
histogram_quantile(0.99,
rate(http_request_duration_seconds_bucket[5m])
)
Trafic
Le trafic quantifie la demande sur le système. Cette métrique contextualise les autres signaux et révèle les patterns d'utilisation.
# Requêtes par seconde par endpoint
rate(http_requests_total[5m])
Un trafic anormalement bas peut signaler un problème autant qu'un pic inattendu.
Erreurs
Les erreurs mesurent le taux de requêtes qui échouent :
- Erreurs explicites : codes HTTP 5xx
- Erreurs implicites : timeouts, réponses incorrectes, violations de SLA
# Taux d'erreur en pourcentage
100 * (
rate(http_requests_total{status=~"5.."}[5m])
/
rate(http_requests_total[5m])
)
Saturation
La saturation indique le degré d'utilisation des ressources. Elle anticipe les problèmes avant qu'ils n'impactent les utilisateurs.
# Saturation mémoire
100 * (1 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes))
Pourquoi les Golden Signals sont Fondamentaux
Alignement sur l'expérience utilisateur
Les Golden Signals garantissent que vos alertes correspondent à des dégradations réellement perçues par les utilisateurs :
Approche traditionnelle:
Alerte sur CPU > 80%
→ Pas nécessairement d'impact utilisateur
→ Bruit potentiel
Approche Golden Signals:
Alerte sur latence p99 > 500ms
→ Impact utilisateur direct
→ Signal pertinent
Réduction du bruit
Moins de métriques signifie moins d'alertes potentielles. Les équipes utilisant ce framework rapportent une amélioration significative de leur ratio signal/bruit.
Universalité du framework
Les Golden Signals s'appliquent à pratiquement tout type de service :
- APIs REST
- Bases de données
- Systèmes de messaging
- Services gRPC
- Workers async
Complémentarité des signaux
Ensemble, les quatre signaux révèlent si le service :
- Répond (erreurs)
- Répond vite (latence)
- Sous quelle charge (trafic)
- Avec quelle marge (saturation)
Aucun problème significatif ne peut affecter les utilisateurs sans perturber au moins un de ces signaux.
Comment Implémenter les Golden Signals
Instrumentation de la latence
Instrumentez les points d'entrée de vos services :
// Exemple avec Prometheus en Go
var requestDuration = prometheus.NewHistogramVec(
prometheus.HistogramOpts{
Name: "http_request_duration_seconds",
Help: "HTTP request duration in seconds",
Buckets: []float64{.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10},
},
[]string{"handler", "method", "status"},
)
func instrumentHandler(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
start := time.Now()
// Wrapper pour capturer le status code
wrapped := &responseWriter{ResponseWriter: w}
next.ServeHTTP(wrapped, r)
duration := time.Since(start).Seconds()
requestDuration.WithLabelValues(
r.URL.Path,
r.Method,
strconv.Itoa(wrapped.status),
).Observe(duration)
})
}
Comptage du trafic
Comptez les requêtes entrantes par période :
# Prometheus recording rules pour le trafic
groups:
- name: traffic_signals
rules:
- record: service:http_requests:rate5m
expr: sum(rate(http_requests_total[5m])) by (service)
- record: service:http_requests:rate5m:by_endpoint
expr: sum(rate(http_requests_total[5m])) by (service, handler)
Capture des erreurs
Capturez les erreurs explicites et implicites :
# Alerte sur taux d'erreur
- alert: HighErrorRate
expr: |
(
sum(rate(http_requests_total{status=~"5.."}[5m])) by (service)
/
sum(rate(http_requests_total[5m])) by (service)
) > 0.01
for: 5m
labels:
severity: critical
annotations:
summary: "Taux d'erreur > 1% sur {{ $labels.service }}"
Mesure de la saturation
Identifiez les ressources limitantes de chaque service :
# Alertes de saturation
- alert: HighMemorySaturation
expr: |
(
container_memory_usage_bytes / container_spec_memory_limit_bytes
) > 0.9
for: 10m
labels:
severity: warning
annotations:
summary: "Mémoire à {{ $value | humanizePercentage }} de la limite"
- alert: HighCPUSaturation
expr: |
(
rate(container_cpu_usage_seconds_total[5m])
/
container_spec_cpu_quota / container_spec_cpu_period
) > 0.9
for: 10m
labels:
severity: warning
Dashboard Golden Signals
Agrégez les métriques dans un dashboard dédié par service :
{
"title": "Golden Signals - API Gateway",
"panels": [
{
"title": "Latency (p50, p95, p99)",
"type": "graph",
"targets": [
{"expr": "histogram_quantile(0.50, rate(http_request_duration_seconds_bucket{service=\"api-gateway\"}[5m]))"},
{"expr": "histogram_quantile(0.95, rate(http_request_duration_seconds_bucket{service=\"api-gateway\"}[5m]))"},
{"expr": "histogram_quantile(0.99, rate(http_request_duration_seconds_bucket{service=\"api-gateway\"}[5m]))"}
]
},
{
"title": "Traffic (req/s)",
"type": "graph",
"targets": [
{"expr": "sum(rate(http_requests_total{service=\"api-gateway\"}[5m]))"}
]
},
{
"title": "Error Rate (%)",
"type": "graph",
"targets": [
{"expr": "100 * sum(rate(http_requests_total{service=\"api-gateway\",status=~\"5..\"}[5m])) / sum(rate(http_requests_total{service=\"api-gateway\"}[5m]))"}
]
},
{
"title": "Saturation (CPU, Memory)",
"type": "graph",
"targets": [
{"expr": "avg(rate(container_cpu_usage_seconds_total{service=\"api-gateway\"}[5m])) / avg(container_spec_cpu_quota/container_spec_cpu_period)"},
{"expr": "avg(container_memory_usage_bytes{service=\"api-gateway\"}) / avg(container_spec_memory_limit_bytes)"}
]
}
]
}
Bonnes Pratiques pour les Golden Signals
Définir des SLO par signal
Quantifiez vos objectifs pour chaque signal :
slo:
service: api-gateway
objectives:
latency:
p99: 200ms
p95: 100ms
error_rate: 0.1% # 99.9% success
availability: 99.9%
Fenêtres de temps appropriées
Choisissez les bonnes fenêtres pour vos alertes :
| Signal | Fenêtre suggérée | Raison |
|---|---|---|
| Erreurs | 5 minutes | Détection rapide |
| Latence | 5-10 minutes | Lisser les spikes |
| Saturation | 15-30 minutes | Tendances |
| Trafic | Variable | Selon le pattern |
Corrélation des signaux
Utilisez les corrélations pour un diagnostic plus rapide :
Latence ↑ + Saturation CPU ↑
→ Problème de capacité
Erreurs ↑ + Saturation normale
→ Bug applicatif probable
Trafic ↓ + Erreurs ↑
→ Problème en amont (load balancer, DNS)
Détection d'anomalies
Automatisez la détection de déviations :
# Alerte sur anomalie de trafic
- alert: TrafficAnomaly
expr: |
abs(
rate(http_requests_total[5m])
-
avg_over_time(rate(http_requests_total[5m])[1d:5m])
) > 2 * stddev_over_time(rate(http_requests_total[5m])[1d:5m])
for: 10m
labels:
severity: warning
Conclusion
Les Golden Signals offrent un framework éprouvé pour construire un monitoring efficace centré sur l'expérience utilisateur.
En se concentrant sur la latence, le trafic, les erreurs et la saturation, vous maintenez une couverture complète des problèmes sans vous noyer dans une multitude de métriques.
Commencez par instrumenter ces quatre signaux sur vos services critiques, établissez des SLO réalistes et itérez sur vos seuils d'alerte.
WizStatus intègre nativement le monitoring des Golden Signals, vous permettant de visualiser ces métriques essentielles et de configurer des alertes intelligentes pour protéger vos SLO.
