Faux positifs dans la supervision : Et si on paramétrait correctement ?

Retour à l’actualité

Nous l’avons vu dans notre article précédent, la non-gestion des faux positifs peut avoir un impact non négligeable sur les coûts d’exploitation d’un parc informatique.

Cause n°1 des faux positifs : une mauvaise configuration qui subit les soubresauts habituels d’un SI.

Quelques exemples :

  • Quelques paquets d’un ping qui se « perdent » et qui font passer un équipement en erreur.
  • Un RTA un peu trop long sur un ping d’équipement à cause d’une surcharge réseau, qui fait passer un équipement en erreur.
  • Un partage réseau qui ne répond pas quelques minutes et qui fait passer un service en inconnu.
  • Un espace disque rempli pendant quelques minutes avec une sauvegarde avant une copie sur bande. Le service de vérification d’espace libre sur disque passe en Alerte ou Critique.

Le paramétrage à ajuster pour limiter les faux positifs

Les seuils, les seuils et les seuils

Première étape dans la limitation des faux positifs : le réglage des seuils.

On ne paramètre pas le seuil d’un disque dur de la même façon si un disque fait 200 Go ou 2 To.

Si un équipement est en DMZ ou accessible via VPN, il faut augmenter les seuils d’alerte sur le RTA. 10 ms, valeur par défaut dans ServiceNav, n’est peut-être pas adaptée.

Les contrôles complémentaires

Seconde étape dans la réduction des faux positifs : les contrôles complémentaires.

Quoi de plus frustrant que de recevoir une notification d’un serveur DOWN, se précipiter sur le serveur et dans le temps de connexion au serveur recevoir une notification du serveur UP ? Tout cela car 2 paquets de ping se sont « perdus » sur le réseau.

L’intérêt des contrôles complémentaires est donc de demander à ServiceNav de vérifier X fois à Y minutes d’intervalle si l’état Alerte/Critique/Inconnu est toujours d’actualité avant de faire passer l’élément (équipement ou service) dans un état non OK, et donc de lancer la chaîne de traitement complète d’une alerte.

Exemple :

Ici nous supervisons le RTA d’un ping et alertons s’il dépasse le seuil critique (en rouge).

Comme on peut le voir, le RTA dépasse régulièrement le seuil pour quelques instants, mais revient ensuite rapidement à la normale. Il est surement nécessaire de travailler sur la connexion entre la ServiceNavBox et l’équipement distant, mais il n’est pas nécessaire d’ouvrir un ticket à chaque passage en Critique.

Nous avons donc décidé de mettre 3 contrôles complémentaires à 1 minute d’intervalle pour cet équipement. C’est-à-dire que pour commencer à alerter et afficher sur les tableaux de bord d’exploitation, il est nécessaire que le RTA de l’équipement soit au dessus du seuil pendant 3 min d’affilées.

Résultat : 1 seul passage en critique (le « trou » vers 16h) au lieu de plusieurs dizaines.

En conclusion

Dans ServiceNav, il existe donc des moyens simples et efficace de réduire les faux positifs en ajustant les seuils et en mettant des contrôles complémentaires. Quand on connait le coût de traitement d’un faux positif, on comprend vite l’intérêt de passer quelques minutes à ajuster sa configuration.

Et du coup, ServiceNav m’aide-t-il à identifier les éléments à traiter en priorité ? Bien sûr ! Et nous verrons cela dans notre prochain article à paraître prochainement sur notre blog.

 

 

Team Leader de l’équipe BU sur le produit ServiceNav, ma priorité est la satisfaction de nos clients. Passionné depuis de longues années par les objets connectés et les nouvelles technologies, je mets en œuvre leur supervision au quotidien.

Articles les plus récents

23/4/19

Supervision : piloter la crise, ne plus la subir

  Que faire lorsque le centre de données hébergeant la supervision qui le supervise, subit une panne incomplète ou totale ? De multiples logiques peuvent être… Lire la suite

18/4/19

ServiceNav, son application mobile et les astreintes

De plus en plus de systèmes d’informations fonctionnent 24h sur 24, et les plages horaires d’usages des applications n’arrêtent pas d’augmenter. En cause ? Une… Lire la suite

16/4/19

NoSQL, moteur de la supervision

NoSQL : pourquoi ? NoSQL, ou Not Only SQL, désigne une famille de systèmes de gestion de bases de données (SGBD) fondamentalement différents des SGBD relationnelles… Lire la suite