Comment éviter les faux positifs Zabbix : régler ses seuils

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.

D'où viennent les faux positifs

Quatre causes expliquent la quasi-totalité des fausses alertes :

1. Les seuils par défaut sont volontairement sensibles. Un éditeur ne peut pas connaître votre parc : il calibre large pour ne rien manquer, à charge pour vous d'ajuster.
2. La valeur instantanée est prise pour la valeur réelle. Un pic de deux secondes déclenche une alerte, puis disparaît.
3. Le même seuil est appliqué à des contextes différents. Un volume de sauvegarde rempli à 90 % est normal ; un disque système à 90 % ne l'est pas.
4. Un incident unique génère des dizaines d'alertes. Un serveur qui tombe déclenche l'alerte système injoignable, puis chacun de ses services, puis chacune de ses métriques.

Chacune a une parade.

Technique 1 : exiger une durée de dépassement

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.

Technique 2 : l'hystérésis, contre les alertes clignotantes

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.

Technique 3 : des seuils adaptés au contexte

Appliquer 85 % à tous les systèmes de fichiers garantit du bruit. Certains volumes sont censés être pleins :

• les volumes de sauvegarde tournent normalement à 90 %
• les points de montage en lecture seule et les images système sont à 100 % en permanence
• les volumes temporaires fluctuent fortement par nature

Zabbix permet de définir des seuils par système 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.

Technique 4 : les dépendances entre déclencheurs

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 « système 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.

Technique 5 : calibrer sur des données réelles

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 systèmes. 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.

Technique 6 : distinguer alerte et information

Toute anomalie ne mérite pas une notification. Un tri simple en trois niveaux :

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.

Le cas particulier du démarrage

Un système qui vient d'être ajouté à 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 un système 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 : un système enrôlé à 14h20 n'aura sa première agrégation qu'à 15h00. Un graphique de tendance vide pendant cette fenêtre est normal, pas un dysfonctionnement.

Avec Logiserv

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.

Déclencheurs préréglés

139

Seuils calibrés sur des données de parc réelles, pas sur les valeurs par défaut.

Détection d'anomalies

Ratios, pas comptages

Les signaux de sécurité sont rapportés à une base de comparaison pour éviter le bruit permanent.

Comportement au démarrage

Dégradation contrôlée

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.

Pour aller plus loin

• Fatigue d'alertes Zabbix — réduire le bruit sans perdre les incidents critiques
• Quelles métriques surveiller sur un serveur — ce qui mérite une alerte et ce qui n'en mérite pas
• Surveiller l'espace disque d'un serveur — seuils combinés et prévision de saturation
• Supervision serveur Windows et Linux : le guide — la démarche complète
• Définition d'un trigger Zabbix et d'un seuil d'alerte