It’s a Trap !

En réalité, non ce n’est pas un piège. ServiceNav implémente bien la gestion des événements Trap dans sa version 3.19 !

Cette fonctionnalité très demandée vous permet de collecter les événements générés par vos équipements, de donner un statut en fonction de leur contenu puis d’intégrer ces résultats dans une météo des services, dashboard et rapport.

Comment ça marche ?

Un défi pour ServiceNav

La gestion des traps était en réflexion chez Coservit depuis quelques mois déjà. Nous savions que la majorité des d’équipements pouvaient générer des alertes, certains d’entre eux ne fonctionnent qu’avec ce type de supervision. Après une légère configuration de la ServiceNav Box et la montée de version 3.19, le produit ServiceNav dispose des capacités de traitement des traps.

Avant de commencer, qu’est-ce qu’un Trap ?

Pour faire simple le protocole SNMP fonctionne de 2 manières :

• Actif : c’est à la box de supervision d’envoyer une requête « GET » pour collecter une information. Le serveur va ensuite répondre. C’est le fonctionnement standard de la supervision.
• Passif : ici l’équipement n’attend pas qu’on l’interroge. Dès qu’une alerte se présente, il envoie un paquet SNMP (un trap), contenant des informations sur cette dernière.

Un fonctionnement qui pose problème

1 – Dans la plupart des outils de supervision, l’implémentation du mode passif est binaire :

• Pas d’alerte : le statut est OK.
• Arrivée d’une alerte : le statut devient critique.

Peu importe la criticité ou le contenu de l’événement, ce dernier provoque un statut critique.
Il faut être plus précis, dans la gestion des alertes.

2 – Une fois qu’un statut est passé en critique, il ne repasse pas automatiquement en OK.

Nous voulons éviter un point de contrôle rouge en permanence, ce serait contre-productif.
Il est également important que les utilisateurs n’aient aucune action manuelle à effectuer pour réinitialiser l’état du contrôle.

A chaque problème sa solution

Il est primordial que les informations récoltées soient pertinentes et utiles, aussi bien pour l’exploitation technique que pour la Direction.
Pour éviter d’avoir une alerte critique à chaque événement, le plugin donne la possibilité de filtrer le contenu du trap grâce à des patterns personnalisables.

Si une chaîne de caractères en particulier est trouvée dans le trap, le statut s’adapte en conséquence.

A la réception d’un trap, son contenu est comparé aux patterns entrés en paramètre. Chacun pourra définir ce qu’il considère comme une alerte critique ou pas.

Le filtrage peut se faire sur un OID, des mots ou une phrase.

Le problème de la pertinence des alertes est désormais réglé. Comment faire en sorte que le point de contrôle repasse en vert une fois l’alerte traitée ? D’ailleurs, comment savoir si une alerte est terminée ?

Certains équipements envoient des traps quand il y a un problème puis un trap « inverse » indiquant que l’équipement est revenu dans son état nominal.

Grâce au pattern OK, il sera possible de définir un OID ou une chaîne de caractères présent dans le trap qui indiquera un statut OK. Ainsi, pas d’action manuelle.

Pour les autres équipements qui notifient seulement en cas de problème, nous avons implémenté un système de timeout.

A la réception d’un trap, le point de contrôle passe en état Warning ou Critique. Si aucun autre trap n’est reçu avant le timeout défini en paramètre, le point de contrôle repassera automatiquement en statut OK.

Les points de contrôle Trap sont donc parfaitement autonomes.

On peut considérer qu’une alerte ne doit rester que 30 minutes maximum dans la supervision et que son suivi se fera grâce à la création d’un ticket.

Passé ce délai, le point de contrôle passera en OK pour permettre la réception éventuelle d’une autre alerte.

Si une notification email est associée au point de contrôle, même en cas de passage en OK, l’utilisateur est averti qu’un événement particulier s’est produit, et peut intervenir au mieux de ses disponibilités.

Une gestion intelligente et une sortie texte personnalisable

Un trap est composé de plusieurs variables (l’heure de réception, l’OID, le texte par exemple).

La sortie texte affichée dans l’interface ServiceNav peut être choisie par les utilisateurs.

Si l’OID du trap se trouve dans la variable 2 et le texte dans la variable 3, la sortie texte pourra être :

Un exemple pour illustrer le tout

Avec cette configuration :

Si le trap reçu est :

Le point de contrôle sera :

Si quelques minutes plus tard, l’équipement envoie un trap indiquant que le serveur est à nouveau en bonne santé :

Le point de contrôle passera en OK grâce au pattern :

Pour conclure

Vous l’aurez compris, une telle fonctionnalité ouvre la supervision à de nouveaux équipements et s’inscrit dans notre volonté d’une amélioration constante de ServiceNav.

Un webinaire aura lieu les 5 et 11 décembre prochains pour une présentation plus précise de cette feature. Inscrivez-vous !