Capture de trap SNMP sous Shinken

Dans le monde du monitoring on différencie deux types de méthodes: le monitoring actif et le passif. L’actif consiste à ce que le serveur de supervision aille chercher l’information sur le client, et le passif c’est le client qui envoi une information au serveur sans avoir été au préalable sollicité par ce dernier. Ce mécanisme est connu sous le nom d’envoi de trap SNMP.

Ce procédé est souvent utilisé dans les routeurs pour par exemple pour avertir qu’un lien vient de tomber sur l’une des interfaces. Là est l’intérêt des traps SNMP : envoyer des « alertes » dès qu’une panne apparaît sans attendre que le serveur de supervision le détecte de lui même pendant une vérification dans le cadre d’un monitoring actif.

Petite précision avant: il s’agit ici d’une bidouille pour faire marcher un service de capture de trap sur Shinken. Je recommande cependant de s’orienter vers une solution propre qui l’intégre nativement comme OpenNMS.

Pour cet article je vais partir du postula suivant:

  • Vous avez un serveur Shinken fonctionnel
  • Vous savez ce qu’est le protocole SNMP

Coté Shinken

Shinken utilise un module nommé named-pipe. Ce dernier va mettre en place un fichier de type FIFO dans lequel on poussera nos commandes externes. Ces commandes sont ensuite envoyées au processus arbiter afin d’être traitées comme le résultat d’un check actif. Ce fichier FIFO est créé au lancement de Shinken et supprimé à l’arrêt.

Une fois installé, on l’active dans la configuration de l’arbiter dans le fichier /etc/shinken/arbiters/arbiter-master.cfg.

On relance le service pour prendre en compte la modification. Le fichier FIFO doit alors apparaitre dans le dossier d’installation de Shinken.

On va à présent créer un service générique. Le principe est d’utiliser, pour recevoir les interruptions SNMP, des services passifs mais aussi volatils, car si nous recevons une deuxième interruption pour le même hôte avant que la première ait été remise à OK, nous voulons être notifié à nouveau.

On créé un fichier /etc/shinken/services/snmptrap-service.cfg dans lequel on place les ligne suivantes.

On joint à présent le service à un hôte. Dans mon exemple je le joins au serveur local donc dans le fichier /etc/shinken/hosts/localhost.cfg.

Toujours penser à vérifier la configuration avant de relancer Shinken avec la commande suivante

Et si c’est ok on relance alors le service

Le service apparaît sur l’interface comme un ping du fait de la check_command saisie dans la configuration. C’est elle qui va s’occuper de refaire passer le service en « Ok » après une réception de trap qui l’aurait fait passer en « Critical ».

shinken_snmp_trap

Maintenant il faut un script (plugin) qui va se charger d’interpréter les futures trap snmp reçu pour les envoyer au fichier FIFO de shinken.

Ajouter le script suivant que l’on appellera submit_check_result dans le dossier des plugins nagios (/usr/lib/nagios/plugins/ sur Debian). Ce script est une modification de la version disponible pour Nagios.

On le rend exécutable et on le donne à l’utilisateur shinken.

On test le script avec la commande suivante qui va faire passer le service en état critique

Les arguments sont:

  • $1 = Le nom de la machine concerné par la trap
  • $2 = Le nom du service (doit correspondre au nom donnée dans la définition du service Shinken. dans mon exemple: TRAP)
  • $3 = Le code de retour (0=OK, 1=WARNING, 2=CRITICAL, 3=UNKNOWN)
  • $4 = Un message texte correspondant à la sortie de la commande.

Sur l’interface on peut constater que le service est passé en état critique. Au bout de une minute il repasse en état « OK ».

shinken_snmp_trap_critical

 Serveur SNMP

Il faut assurément un serveur SNMP capable de capturer les traps.

On se rend dans le fichier de configuration pour ajouter les lignes suivantes en début de partie « ACCESS CONTROL »

On va également installer quelques MIBs.

Editez le fichier /etc/snmp/snmp.conf et commentez la ligne mibs

Relancer le service

Tester avec la commande suivante que le serveur est bien opérationnel. Celle ci interroge les mibs « système ».

Ce qui devrait sortir un truc dans ce genre

 Interpréteur de trap SNMP

Maintenant que l’on est capable de recevoir des trap, il faut les interpréter pour dialoguer ensuite avec le fichier fifo de Shinken. Ceci s’effectue avec le paquet snmptt.

On active le debug dans le fichier /etc/snmp/snmptt.ini, histoire de voir les traps que l’on a reçues mais pas interprétées. Si vous avez mal configuré quelque chose elle arriveront dans le fichier  /var/log/snmptt/snmpttunknown.log.

On ajoute ensuite les ligne suivantes dans la configuration sous /etc/snmp/snmptrapd.conf

Ce qui veut dire :

  • on accepte toutes les interruptions
  • on ne journalise pas les interruptions reçues (c’est SNMPTT qui s’en chargera)
  • on traite de la même façon toutes les interruptions : avec SNMPTT

Le service snmptrapd doit être modifié pour ne pas traduire les OID, mais les laisser sous forme numérique. C’est SNMPTT qui se chargera de cette traduction. Sous Debian il faut éditer le fichier /etc/default/snmpd et ajouter l’option -On comme ceci:

Il faut activer également le processus de capture de trap nommé snmptrapd. Ceci se fait dans le meme ficiher.

On relance les deux services pour prendre en compte les modificatioins

 Compilation de MIB

SNMPTT a besoin de compiler les MIBs du format TXT vers un fichier de configuration. Les MIBs de Debian se trouvent dans le dossier /var/lib/mibs/. Si vous voulez travailler avec une MIB particulière (routeur CISCO ou autre équipement) il vous faudra l’importer sur le système afin de la compiler. Cette compilation effectue l’association OID/ action à effectuer.

Pour chaque MIB, il faut compiler à l’aide de la syntaxe suivante :

Pour voir les dossier de mibs actif sur le sysème:

Il faut donc que notre mib se trouve dans l’un de ses dossiers.

Test avec une MIB perso

On va créer une MIB de test pour pouvoir tester toute la chaîne depuis la capture de la trap jusqu’au traitement de celle ci par Shinken.

On créé notre mib dans un fichier sous /usr/share/snmp/mibs/TRAP-TEST-MIB avec le contenu suivant:

On export cette MIB

On l’a compile en précisant notre plugin submit_check_result, c’est donc ici que ce fait la jonction  avec Shinken.

Ce qui doit générer un fichier de cette forme

On fait prendre en compte ce fichier à la configuration globale de SNMPTT dans /etc/snmp/snmptt.ini

On relance les services

Et enfin, on lance une trap de test à la main

Les logs de snmptt doivent remonter la trap:

Même chose pour les log messages du système:

Le service passe alors en critique sur Shinken et vous recevez une notification.

trap_snmptt_shinken

Au bout de une minute, comme défini dans le fichier de configuration sur Shinken, le service passe de nouveau au vert en statut OK.

Vous avez plus qu’a importer vos MIBs et faire la liaison avec shinken de la même façon que dans cet exemple.

Pour résumer, nous avons la chaîne suivante:

SNMPD –> SNMPTT –> script –> FIFO shinken

5 thoughts on “Capture de trap SNMP sous Shinken”

  1. floppy84 dit :

    Merci pour ce petit tuto très bien fait et exhaustif, j’ai résolu mon problème très rapidement grâce à toi.

    1. N.i.c.O dit :

      Super! Merci !

  2. tod dit :

    Bonjour,

    Le « 2 » dans cette commande « –exec=’/usr/lib/nagios/plugins/submit_check_result $r TRAP 2′  » indique qu’on ne trape que les critical.

    Pour traper tous les messages (warnings, critical et unknown) quelle serait la bonne syntaxe de la commande ?

    Cdlt.
    Tod

    1. N.i.c.O dit :

      Je pense qu’il faut recompiler une nouvelle MIB. Peut être qu’un autre $r ferait l’affaire. Jamais testé pour être honnête.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *