Réduire les fausses alertes Zabbix : hystérésis, durée de dépassement, seuils par volume, dépendances entre déclencheurs et calibrage sur données réelles plutôt que sur les valeurs par défaut.
Les autres services
Les métriques indispensables à surveiller sur un serveur Windows ou Linux : disque, mémoire, processeur, services, réseau. Seuils recommandés, pièges de lecture et ordre de priorité.
Comment surveiller l'espace disque d'un serveur Windows ou Linux : quels seuils choisir, pourquoi la tendance compte plus que le pourcentage, et comment éviter la saturation avant l'incident.
Comprenez pourquoi les alertes Zabbix deviennent difficiles à traiter et comment prioriser, contextualiser et livrer les notifications utiles à votre équipe IT.
Le principal échec d'un projet de supervision n'est pas de manquer un incident : c'est d'en signaler tellement que plus personne ne lit les notifications. Au bout de quinze jours, les alertes partent dans un dossier que personne n'ouvre — et l'alerte qui comptait vraiment y arrive avec les autres.
Cet article rassemble les techniques concrètes pour réduire le bruit sans perdre en couverture.
Quatre causes expliquent la quasi-totalité des fausses alertes :
Chacune a une parade.
C'est la correction la plus rentable. Plutôt que d'alerter dès qu'une valeur dépasse le seuil, exigez qu'elle le dépasse pendant une durée donnée.
Au lieu de :
last(/host/system.cpu.util)>90
Utilisez la moyenne sur une fenêtre :
avg(/host/system.cpu.util,5m)>90
La première expression alerte sur un pic d'antivirus. La seconde n'alerte que si la charge est réellement soutenue. Sur les métriques volatiles — processeur, réseau, entrées-sorties — cette seule modification supprime l'essentiel du bruit.
Ordres de grandeur qui fonctionnent bien : 5 minutes pour le processeur, 10 minutes pour la mémoire, immédiat pour l'arrêt d'un service.
Une métrique qui oscille autour du seuil génère une succession d'alertes et de résolutions. À 85 % d'occupation disque, un volume qui passe de 84,9 % à 85,1 % toutes les dix minutes produit une dizaine de notifications par heure.
L'hystérésis consiste à déclencher et résoudre à des seuils différents : alerter à 85 %, mais ne considérer le problème résolu qu'en dessous de 80 %.
Dans Zabbix, cela s'exprime avec une expression de récupération distincte :
Expression de problème : last(/host/vfs.fs.size[/,pused])>85
Expression de récupération: last(/host/vfs.fs.size[/,pused])<80
À appliquer systématiquement à toute métrique continue.
Appliquer 85 % à tous les systèmes de fichiers garantit du bruit. Certains volumes sont censés être pleins :
Zabbix permet de définir des seuils par machine ou par volume via les macros. Une macro {$VFS.FS.PUSED.MAX} définie globalement à 85 peut être surchargée à 95 sur un hôte de sauvegarde, sans dupliquer le déclencheur.
Le même raisonnement vaut pour les grands volumes : combinez pourcentage et espace absolu, comme expliqué dans surveiller l'espace disque.
Quand un serveur devient injoignable, tout ce qui en dépend remonte en erreur : les services, les métriques système, les applications hébergées. Un incident unique produit vingt notifications.
Les dépendances de Zabbix résolvent ce problème : un déclencheur dépendant d'un autre ne se déclenche pas si son parent est déjà actif. Déclarez que « service arrêté » dépend de « machine injoignable », et vous ne recevrez qu'une alerte au lieu de vingt.
Cette configuration est fastidieuse à mettre en place manuellement, mais c'est ce qui distingue une supervision exploitable d'une supervision qui inonde.
C'est l'étape que l'on saute presque toujours, et c'est la plus déterminante.
Avant de fixer un seuil définitif, regardez à quoi ressemble la normale sur vos machines. Une charge processeur moyenne de 70 % peut être le fonctionnement nominal d'un serveur de calcul, et une anomalie sur un serveur de fichiers.
La méthode : activez la collecte sans notification pendant une à deux semaines, observez les valeurs réellement atteintes, puis positionnez les seuils au-dessus de la variation normale constatée.
Cet écart entre valeurs par défaut et réalité est parfois considérable. Sur la détection d'anomalies de sécurité par exemple, certains identifiants d'événement Windows se produisent des centaines de fois par heure sur un serveur parfaitement sain — l'identifiant 4672, attribution de privilèges spéciaux, en fait partie. Un déclencheur qui les compte brut génère un flot d'alertes permanent. Ces signaux n'ont de sens que rapportés à une base de comparaison, jamais en valeur absolue.
Méfiez-vous des seuils recommandés trouvés en ligne, y compris ceux des éditeurs. Ils décrivent un serveur générique qui n'existe pas. Vos propres données des deux dernières semaines sont une source bien plus fiable.
Toute anomalie ne mérite pas une notification. Un tri simple en trois niveaux :
| Niveau | Canal | Exemple |
|---|---|---|
| Urgence | Notification immédiate, y compris la nuit | Machine injoignable, disque à 98 % |
| Important | Notification en journée | Disque à 85 %, service redémarré |
| Information | Tableau de bord uniquement | Pic de charge, variation de trafic |
Si tout est urgent, plus rien ne l'est. Le niveau « information » n'est pas une catégorie de second rang : c'est ce qui permet aux deux premiers de rester crédibles.
Une machine qui vient d'être ajoutée à la supervision génère souvent des alertes les premières heures : l'historique est vide, les tendances ne sont pas calculables, et certains déclencheurs fondés sur des ratios se comportent mal en l'absence de données.
Deux précautions : ne pas activer les notifications sur une machine pendant ses premières heures de collecte, et privilégier les expressions robustes à l'absence de données. Une astuce courante consiste à ajouter +1 au dénominateur d'un ratio pour éviter une division par zéro pendant la fenêtre initiale.
Les agrégations horaires de Zabbix ne sont écrites qu'une fois l'heure calendaire complète : une machine enrôlée à 14h20 n'aura sa première agrégation qu'à 15h00. Un graphique de tendance vide pendant cette fenêtre est normal, pas un dysfonctionnement.
Les seuils livrés sont calibrés sur des données réelles de parc plutôt que sur les valeurs par défaut de Zabbix, et les déclencheurs de détection d'anomalies utilisent des ratios rapportés à une base de comparaison plutôt que des comptages bruts.
Seuils calibrés sur des données de parc réelles, pas sur les valeurs par défaut.
Les signaux de sécurité sont rapportés à une base de comparaison pour éviter le bruit permanent.
Les déclencheurs par ratio restent stables tant que l'historique est insuffisant.
Le principe de fond est développé dans fatigue d'alertes Zabbix.
Logiserv supervise votre parc à partir de cet article : essai gratuit sans carte bancaire.