Alertes sur le burn rate

1. Les limites des alertes à seuil #

Trop de bruit ou trop tard.

Le problème #

Une alerte « taux d'erreur > 0,1 % pendant 5 min » se déclenche pour des pics sans importance (bruit) et ne voit pas une dégradation lente de 0,09 % qui épuise pourtant le budget. Le bon critère est la vitesse de consommation du budget.

2. Les alertes multi-fenêtres multi-taux #

La méthode du SRE Workbook.

Les quatre seuils #

La fenêtre longue garantit que la consommation est significative ; la fenêtre courte (1/12 de la longue) garantit qu'elle est toujours en cours, ce qui fait retomber l'alerte rapidement après la résolution.

En PromQL #

- alert: CheckoutErrorBudgetBurn
  expr: |
    (
      slo:sli_error:ratio_rate1h{slo="checkout-availability"} > (14.4 * 0.001)
      and
      slo:sli_error:ratio_rate5m{slo="checkout-availability"} > (14.4 * 0.001)
    )
    or
    (
      slo:sli_error:ratio_rate6h{slo="checkout-availability"} > (6 * 0.001)
      and
      slo:sli_error:ratio_rate30m{slo="checkout-availability"} > (6 * 0.001)
    )
  labels: { severity: critical }
  annotations:
    summary: "checkout consomme son budget d'erreur trop vite" 

Bonne Pratique : Ces alertes remplacent avantageusement la plupart des alertes à seuil d'un service : une ou deux alertes par SLO suffisent pour l'astreinte.

3. Faible trafic #

Quand chaque erreur compte trop.

Pièges #

• Avec 10 requêtes par heure, une seule erreur fait 10 % d'erreurs : les alertes deviennent bruyantes.
• Solutions : générer du trafic synthétique (k6, sondes), regrouper plusieurs services dans un SLO commun, allonger les fenêtres ou exiger un nombre minimal d'événements.