Cycle de vie des alertes

Introduction

Cette page décrit le cycle de vie complet d’une alerte Gward, de sa création à sa clôture, ainsi que les concepts de problem_key, multi-agents, multi-impacts et états des checks.

États d’un check

Chaque exécution de check produit un des trois statuts suivants :

Statut	Description
`ok`	Le check a passé la condition de succès (`success_if`)
`failing`	Le check n’a pas passé la condition de succès — peut déclencher une alerte
`error`	Erreur technique d’exécution (timeout, script introuvable, etc.) — aucune logique d’alerte déclenchée

États d’une alerte

État	Description
`open`	Le problème est actif. Au moins un impact est en cours.
`resolved`	Tous les impacts sont résolus. Chaque agent concerné a repassé son check en succès (`ok`).
`closed`	L’alerte est archivée manuellement via le bouton “Fermer l’alerte”.

États d’un impact

Chaque agent contribue un impact indépendant à l’alerte :

État	Description
`open`	L’agent est en échec sur ce problème
`resolved`	L’agent a repassé son check en succès (`condition_cleared`)
`closed`	L’impact a été fermé lors de la clôture manuelle de l’alerte

Transitions

[check failing + failure_threshold atteint] → alerte open
[check ok sur tous les agents]              → alerte resolved
[fermeture manuelle]                        → alerte closed

Réouverture automatique : si le problème réapparaît après résolution (alerte en état resolved), l’alerte existante est réouverte (open) sans en créer une nouvelle.

Mise à jour du lastSeenAt : à chaque résultat failing, le lastSeenAt de l’alerte et de l’impact est mis à jour, même si l’impact était déjà ouvert.

La `problem_key`

La problem_key est l’identifiant du problème métier. Elle permet de regrouper plusieurs impacts (provenant de différents agents ou checks) sous une même alerte.

Règle : une seule alerte open ou resolved peut exister par problem_key + criticité + message. Si les paramètres d’alerte changent sur le check, une nouvelle alerte sera créée lors de la prochaine détection.

Exemple : si 5 agents remontent un échec sur le check nginx-down, une seule alerte est créée avec 5 impacts.

Le `failure_threshold`

Le failure_threshold est le nombre d’échecs consécutifs requis avant que l’alerte ne soit ouverte. Il est configuré dans l’onglet Alerte du check.

failure_threshold: 1 — alerte ouverte dès le premier résultat failing
failure_threshold: 3 — alerte ouverte après 3 résultats failing consécutifs sans succès intermédiaire

Niveaux de sévérité

Niveau	Priorité
`info`	1 — Information
`low`	2 — Faible
`medium`	3 — Modéré
`high`	4 — Élevé
`critical`	5 — Critique

La sévérité est définie au niveau du check et s’applique à toute l’alerte.

Multi-agents

Une alerte peut regrouper des impacts provenant de plusieurs agents différents. Chaque agent contribue un impact indépendant à l’alerte. L’alerte n’est résolue que lorsque tous les impacts ouverts sont résolus.

Notifications Teams

Des notifications Microsoft Teams sont envoyées automatiquement (si un webhook est configuré sur le check) lors des événements suivants :

Événement	Description
`alert_created`	Première détection — nouvelle alerte ouverte ou alerte résolue réouverte
`agent_added`	Un nouvel agent contribue un impact à une alerte déjà ouverte
`agent_resolved`	Un agent repasse en succès — son impact est résolu

Historisation

Chaque transition d’état de check est enregistrée dans un CheckStateTransition horodaté. Cela permet :

l’audit des incidents
le replay de la timeline
l’analyse des patterns de défaillance