Déclencheurs, corrélation et escalades

01Une grille de gravité qui veut dire quelque chose

Zabbix propose six niveaux de gravité. Sans convention écrite, chacun les utilise à sa façon et plus aucun ne veut rien dire. Nous associons chaque niveau à une réaction attendue, et c'est cette grille qui pilote ensuite les escalades.

02Des expressions qui prévoient

Le déclencheur le plus courant constate un dépassement. Les plus utiles anticipent, évitent le clignotement ou détectent un silence.

# moyenne sur 10 minutes plutot que derniere valeur : ignore les pointes
avg(/Linux serveur/system.cpu.util,10m)>90

# hysteresis : se declenche a 90 %, ne se retablit que sous 80 %
#   expression           : last(/Linux serveur/vfs.fs.dependent.size[/srv,pused])>90
#   expression de retour : last(/Linux serveur/vfs.fs.dependent.size[/srv,pused])<80

# prevoir : le volume sera plein dans moins de 24 heures
timeleft(/Linux serveur/vfs.fs.dependent.size[/srv,pused],6h,100)<24h

# le silence : plus aucune donnee de l'agent depuis 5 minutes
nodata(/Linux serveur/agent.ping,5m)=1

# la tendance longue : le mois ecoule depasse de 30 % le mois d'avant
trendavg(/Routeur/net.if.in[wan],1M:now/M)>1.3*trendavg(/Routeur/net.if.in[wan],1M:now/M-1M)

03Dépendances et maintenances

Les dépendances éteignent les cascades

Quand le routeur d'un site tombe, tout ce qui est derrière devient injoignable. Sans dépendance, vous recevez une alerte par hôte et cherchez la cause au milieu de cinquante messages. Avec une dépendance de l'agent de chaque hôte vers la disponibilité du routeur, vous n'en recevez qu'une : la bonne.

Pour un site derrière un proxy, la dépendance naturelle est la disponibilité du proxy lui-même. Pour les invités d'un cluster, c'est l'hôte « cluster » du chapitre 03.

Les maintenances font taire ce qui est prévu

Une période de maintenance suspend les notifications d'un groupe d'hôtes ou d'étiquettes pendant une plage donnée, en continuant ou non la collecte. Nous la posons pour chaque intervention planifiée, et automatiquement par l'API depuis nos scripts d'exploitation (chapitre 05) : une mise à jour de noeud Proxmox commence par la maintenance du noeud et finit par sa levée.

04La corrélation d'événements

La corrélation ferme ou regroupe automatiquement des problèmes liés. Deux usages couvrent l'essentiel :

• La corrélation par déclencheur, réglée dans le déclencheur lui-même : un problème par valeur d'étiquette, et la fermeture ne concerne que l'événement qui porte la même valeur. C'est ce qui permet à un unique déclencheur sur un journal de suivre séparément plusieurs services.
• La corrélation globale, réglée dans les paramètres de données : un nouvel événement portant une étiquette donnée ferme les anciens problèmes portant la même. Par exemple, l'événement « service rétabli » envoyé par un système externe ferme le problème « service en panne » ouvert par le même système.

05Actions et escalades

Une action réunit des conditions (gravité, étiquettes, groupe d'hôtes, période) et des opérations échelonnées. Voici le schéma que nous appliquons pour les alertes de production d'un client sous contrat d'astreinte.

La condition « problème non acquitté » sur chaque étape est ce qui rend l'escalade supportable : dès qu'un humain a pris l'incident en charge, les étapes suivantes ne partent pas. Les opérations de mise à jour notifient l'équipe quand quelqu'un acquitte ou commente, ce qui évite que deux personnes traitent le même incident sans le savoir.

06Les canaux de notification

Zabbix fournit de nombreux types de médias sous forme de webhooks : Telegram, Mattermost, Microsoft Teams, Slack, ntfy, et la plupart des outils de ticket. Trois principes :

• Deux canaux indépendants pour l'astreinte, dont au moins un qui ne passe pas par votre propre infrastructure.
• Des messages qui se lisent sur un écran de verrouillage : hôte, problème, gravité, durée en une ligne. Le détail suit dans le corps, avec le lien vers l'événement.
• Un test après chaque modification, avec le bouton prévu dans le type de média. Un webhook cassé ne prévient personne qu'il est cassé.

[{EVENT.SEVERITY}] {HOST.NAME} : {EVENT.NAME}

Depuis {EVENT.DATE} {EVENT.TIME} ({EVENT.AGE})
Valeur : {EVENT.OPDATA}
Etiquettes : {EVENT.TAGS}
https://zabbix.exemple.fr/zabbix.php?action=problem.view&filter_eventid={EVENT.ID}

07L'hygiène des alertes

Une plateforme d'alertes se dégrade si personne ne l'entretient. Une demi-heure par mois suffit :

• consulter le rapport des cent déclencheurs les plus actifs, et traiter les cinq premiers : seuil à relever, hystérésis à ajouter, ou vrai problème à corriger ;
• supprimer les déclencheurs qui n'ont jamais provoqué la moindre action ;
• vérifier qu'aucun hôte n'est resté en maintenance depuis l'intervention du mois dernier ;
• relire les problèmes ouverts depuis plus de trente jours : ils sont soit à résoudre, soit à supprimer, jamais à garder pour décorer.