Configurer les alertes
Introduction
Section titled “Introduction”Gward propose un système d’alerting intelligent : les alertes sont regroupées par problème métier via une problem_key, peuvent concerner plusieurs agents simultanément et suivent un cycle de vie structuré.
Prérequis
Section titled “Prérequis”- Au moins un check configuré et actif
- Accès à la section Alertes de la plateforme
Étapes
Section titled “Étapes”1. Activer l’alerting sur un check
Section titled “1. Activer l’alerting sur un check”Dans l’onglet Alerte du check, activez le toggle Alerte.
2. Configurer la condition de déclenchement
Section titled “2. Configurer la condition de déclenchement”Définissez la condition (opérateur + valeur) qui déclenche l’alerte. Cette condition est indépendante de la condition de succès du check (success_if) : vous pouvez par exemple considérer un check en succès mais déclencher une alerte si la valeur dépasse un seuil critique.
3. Définir la problem_key
Section titled “3. Définir la problem_key”La problem_key est générée automatiquement à partir du check. Elle permet de regrouper plusieurs impacts (provenant de différents agents) sous une même alerte. Vous pouvez la consulter en lecture seule sur la fiche du check.
Exemples de problem keys générées :
nginx-downdisk-full-productionapi-latency-high
4. Choisir le niveau de sévérité
Section titled “4. Choisir le niveau de sévérité”Chaque alerte est associée à un niveau de sévérité configuré sur le check :
| Niveau | Usage recommandé |
|---|---|
info |
Information, pas d’action requise |
low |
Anomalie mineure à surveiller |
medium |
Dégradation de service |
high |
Impact significatif sur la production |
critical |
Incident majeur, action immédiate requise |
5. Configurer le seuil d’échecs consécutifs
Section titled “5. Configurer le seuil d’échecs consécutifs”Le paramètre failure_threshold permet d’éviter les faux positifs : l’alerte n’est ouverte qu’après N échecs consécutifs. Par défaut, la valeur est 1 (ouverture dès le premier échec).
Exemples :
failure_threshold: 1— alerte immédiate dès le premier échecfailure_threshold: 3— alerte après 3 échecs consécutifs sans succès intermédiaire
6. Comprendre le cycle de vie d’une alerte
Section titled “6. Comprendre le cycle de vie d’une alerte”Une alerte passe par les états suivants :
- open — le problème est détecté et actif
- resolved — tous les impacts sont résolus (le check est repassé en succès sur tous les agents)
- closed — l’alerte est archivée manuellement via le bouton “Fermer l’alerte”
Si le problème réapparaît après résolution (état resolved), l’alerte est automatiquement réouverte (open) sans en créer une nouvelle.
7. Gérer les multi-impacts
Section titled “7. Gérer les multi-impacts”Une même alerte peut regrouper plusieurs impacts provenant de différents agents. Chaque impact conserve :
- le
triggerStdout: sortie standard ayant déclenché le problème - le
triggerStderr: sortie d’erreur associée - les entrées de contexte (
checkEntries) : résultats des scripts de contexte configurés sur le check - les horodatages : début (
startedAt), dernière vue (lastSeenAt), résolution (resolvedAt)
8. Configurer les notifications Teams (optionnel)
Section titled “8. Configurer les notifications Teams (optionnel)”Dans l’onglet Intégrations du check, renseignez un Webhook Microsoft Teams. Une notification est envoyée automatiquement lors de :
- la création d’une nouvelle alerte
- l’ajout d’un nouvel agent impacté
- la résolution d’un impact agent
Résultat attendu
Section titled “Résultat attendu”Les alertes sont regroupées par problème métier, les sévérités sont correctement attribuées et le cycle de vie est suivi automatiquement.