Budgets d'erreur et alertes sur le taux de consommation : alerter pour les bonnes raisons
Comment transformer un SLO en alertes qui se déclenchent vite sur de vraies pannes, restent silencieuses face au bruit et s'arrêtent une fois le problème corrigé.
Les exemples sont génériques et illustratifs. Ils ne proviennent d'aucun environnement client : adaptez seuils et réglages à votre propre système.
Partir de ce que vivent les utilisateurs
La plupart des alertes bruyantes viennent d'alertes sur des causes — CPU, mémoire, un pod redémarré — plutôt que sur ce que ressentent les utilisateurs. Un indicateur de niveau de service (SLI) mesure directement ce ressenti : la part des requêtes valides qui ont été bonnes. Bonne peut vouloir dire une réponse sans erreur serveur, une réponse plus rapide qu'un seuil, ou les deux.
Un objectif de niveau de service (SLO) fixe une cible pour ce ratio sur une fenêtre — par exemple 99,9 % des requêtes réussies sur 30 jours. L'écart avec 100 % est le budget d'erreur : ici 0,1 % des requêtes, soit environ 43 minutes d'indisponibilité totale dans le mois.
Pourquoi les alertes à seuil fixe échouent
Une alerte du type « taux d'erreur supérieur à 1 % pendant 5 minutes » est à la fois trop sensible et trop lente. Elle se déclenche pour un pic bref qui n'a consommé qu'une infime part du budget, et ne se déclenche jamais pour un taux d'erreur de 0,5 % qui épuise silencieusement tout le budget en une semaine.
Le taux de consommation (burn rate) règle ce problème. C'est la vitesse à laquelle le budget est consommé par rapport au SLO : un taux de 1 dépense exactement le budget sur la fenêtre ; un taux de 14,4 dépense un budget de 30 jours en un peu plus de deux jours.
Alertes multifenêtres et à plusieurs taux
L'approche décrite dans le SRE Workbook de Google associe chaque seuil de taux de consommation à une fenêtre longue, qui prouve que le problème est significatif, et à une fenêtre courte, qui prouve qu'il est toujours en cours. Pour un SLO de 99,9 % sur 30 jours, un point de départ courant est :
- Alerte : taux supérieur à 14,4 sur 1 heure et sur 5 minutes — 2 % du budget consommés en une heure.
- Alerte : taux supérieur à 6 sur 6 heures et sur 30 minutes — 5 % du budget consommés.
- Ticket : taux supérieur à 1 sur 3 jours et sur 6 heures — 10 % du budget consommés.
# Fast-burn page for a 99.9% availability SLO (error budget = 0.001)
(
sum(rate(http_requests_total{job="api", code=~"5.."}[1h]))
/ sum(rate(http_requests_total{job="api"}[1h]))
) > (14.4 * 0.001)
and
(
sum(rate(http_requests_total{job="api", code=~"5.."}[5m]))
/ sum(rate(http_requests_total{job="api"}[5m]))
) > (14.4 * 0.001)La fenêtre courte compte autant que la longue : dès que le correctif est en place, le ratio sur 5 minutes baisse et l'alerte se résout, au lieu de sonner jusqu'à la fin de l'heure.
Les détails qui font que ça marche
- Recording rules : précalculez le ratio d'erreur de chaque fenêtre pour que les expressions d'alerte restent légères et lisibles.
- Faible trafic : avec quelques requêtes par minute, un seul échec représente un ratio élevé. Exigez un nombre minimal de requêtes, ou mesurez avec des sondes synthétiques.
- SLO de latence : comptez comme mauvais événements les requêtes plus lentes que le seuil, avec des buckets d'histogramme qui incluent la valeur du seuil.
- Exclusions : décidez à l'avance si les erreurs client et les health checks comptent, et écrivez-le à côté du SLO.
À quoi sert le budget
Le budget est un outil de décision, pas seulement un déclencheur d'astreinte. Tant qu'il est sain, l'équipe peut livrer plus vite et prendre des changements plus risqués. Quand il est épuisé, le travail de fiabilité passe devant les fonctionnalités jusqu'à ce que la tendance se rétablisse. Convenez de cette règle avec les responsables produit avant le premier dépassement, pas pendant.