Rédiger une alerte avec constat et parcours de réponse

Une alerte utile indique ce qui ne fonctionne pas dans une application et le premier parcours de réponse prévu. Son destinataire doit la comprendre sans devoir deviner le service à partir d’un nom de serveur inconnu.

Partir de la tâche utilisateur

Commencez par une tâche importante, comme charger la liste des projets d’un portail client. Pour les services interactifs, Prometheus recommande notamment les erreurs visibles par l’utilisateur et des vues adaptées à l’analyse des causes. Un taux d’utilisation des ressources peut donner du contexte ; il n’explique pas à lui seul si la liste fonctionne.

Définissez les requêtes et réponses prises en compte. Les appels répétés sont des requêtes supplémentaires, pas automatiquement des personnes touchées en plus. Le taux d’erreur exige donc un dénominateur clair.

Un exemple d’alerte détaillé

L’équipe logicielle, les mesures et les règles ci-dessous sont fictives. Il ne s’agit ni d’un incident ASES, ni de seuils universels, ni d’un engagement de support. Le dénominateur comprend ici toutes les requêtes enregistrées pour l’opération indiquée. La règle évalue une fenêtre de 5 minutes, sans durée de maintien supplémentaire.

Ici, le nombre minimal de requêtes et le seuil d’erreur sont tous deux dépassés. Les 20 % décrivent les requêtes dans cette fenêtre. Ils ne prouvent ni la même proportion d’utilisateurs touchés ni une cause précise.

Préparer la première réponse

Le runbook est une courte procédure pour le diagnostic prévu. La personne responsable confirme d’abord la prise en charge et vérifie si le problème persiste. Cet accusé ne signifie pas que la panne est résolue. Les filtres présélectionnés doivent reprendre le même service, la même opération et la même période.

Délimitez ensuite les instances, versions et dépendances touchées. Une mise en production à 09:08 serait ici un événement à examiner, pas une preuve de cause. Un retour arrière exige un parcours adapté et vérifié à l’avance ; l’alerte n’autorise pas des redémarrages ou changements arbitraires.

Vérifier aussi le parcours de notification

Alertmanager peut regrouper les alertes similaires et les acheminer aux destinataires configurés. Les instances concernées doivent rester visibles. Des problèmes indépendants ne doivent pas être fusionnés seulement parce que leurs noms se ressemblent.

Avec une notification clairement marquée comme test, vérifiez aussi réception, prise en charge et recours prévu. Prometheus demande explicitement de surveiller la surveillance elle-même. Des mesures redevenues normales peuvent mettre fin à l’état d’alerte ; elles ne remplacent ni le contrôle de la tâche utilisateur ni l’analyse des causes. Les réponses réussies mais incorrectes au niveau métier ou les réponses lentes échappent à cette simple règle d’erreur serveur.

Sources

• Google SRE — Monitoring Distributed Systems

• Prometheus — Alerting best practices

• Prometheus — Alertmanager

• GitLab — Incident Diagnosis in a Symptom-based World