View Source

Contexte

Simple Network Management Protocol (abrégé SNMP), est un protocole de communication qui permet aux administrateurs réseau de gérer les équipements du réseau, de superviser et de diagnostiquer des problèmes réseaux et matériels à distance.

Une requête SNMP est un datagramme UDP envoyée par le manager à destination du port 161 de l'agent. L'agent répond alors au manager avec la valeur demandée.

Les traps SNMP, elles, sont émises depuis les agents SNMP vers une destination (un serveur de supervision par exemple), qui entendra ces requêtes. Pour les comprendre, ce serveur devra disposer de bases de données avec l'ensemble des informations (OID et Descripteurs) des constructeurs, ces bases sont appelées MIB. Les valeurs pourront alors être interprétées par le serveur de supervision. Ce procédé est souvent utilisé dans les routeurs pour par exemple, avertir qu’un lien vient de tomber sur l’une de ses interfaces. L’intérêt des traps SNMP est donc d'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.

Il se peut donc que vous souhaitiez paramétrer Shinken pour récupérer et interpréter ces traps, nous vous proposons deux moyens, via le module WS Arbiter de Shinken, ou via le module Named Pipe (aussi utilisé de manière historique dans Nagios avec le fichier nagios.cmd).

WS Arbiter

En cours de Documentation...

Module Named Pipe

Le module Named Pipe, via le fichier "passe plat" FIFO nagios.cmd, va permettre à Shinken de récupérer les entrées ou commandes externes.

Mise en place du module

S'il n'existe pas, copier le répertoire named-pipe (dans le zip ici) dans le répertoire /var/lib/shinken/modules
Il faut ensuite rajouter la définition du module :

Dans le répertoire /etc/shinken/modules/
Copier le fichier name-pipe.cfg

Ensuite on va accrocher le module au receiver

Ouvrir le fichier /etc/shinken/receivers/receiver-master.cfg
Ajouter named-pipe à la ligne modules

modules named-pipe

Redémarrer Shinken via la commande service shinken restart

Création de l'élément de supervision en configuration

Dans l’interface de configuration, il faut à présent créer le modèle de check, en passif et volatile, 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.
- Voici un exemple avec la syntaxe via un fichier cfg :

define service{
        name                    snmptrap-service
        service_description     TRAP
        check_command           check_host_alive
        is_volatile             1
        max_check_attempts      1
        check_interval          1
        retry_interval          1
        passive_checks_enabled  1
        check_period            24x7
        notification_period     24x7
        notification_interval   86400
        notification_options    w,c,r
        contact_groups          admins
        register                0
}

- Il faut ensuite rattacher le service à un hôte, voici un exemple via fichier cfg :

define service{
        use                     snmptrap-service
        host_name               localhost
        service_description     TRAP
}

Une fois les éléments passés en production, le check doit donc apparaître dans l'interface de visualisation 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 ».

Script interpréteur des traps

Maintenant il faut un script (plugin) qui va se charger d’interpréter les futures traps SNMP reçues pour les envoyer à Shinken (à travers le module named-pipe et le fichier nagios.cmd).
Ajouter le script suivant que l’on appellera submit_check_result dans le dossier des plugins nagios (/usr/lib64/nagios/plugins/):

#!/bin/bash

# Arguments:
# $1 = host_name (Short name of host that the service is associated with)
# $2 = svc_description (Description of the service)
# $3 = return_code (An integer that determines the state of the service check, 0=OK, 1=WARNING, 2=CRITICAL,3=UNKNOWN).
# $4 = plugin_output (A text string that should be used as the plugin output for the service check)

echocmd="/bin/echo"

CommandFile="/var/lib/shinken/nagios.cmd"

# get the current date/time in seconds since UNIX epoch
datetime=`date +%s`

# create the command line to add to the command file
cmdline="[$datetime] PROCESS_SERVICE_CHECK_RESULT;$1;$2;$3;$4"

# append the command to the end of the command file
`$echocmd $cmdline >> $CommandFile`

On le rend exécutable et on le donne à l’utilisateur Shinken :

chown shinken:shinken /usr/lib64/nagios/plugins/submit_check_result
chmod +x /usr/lib64/nagios/plugins/submit_check_result

Pour tester le script, il suffit d’exécuter la commande suivante qui va faire passer le service en état critique :

/usr/lib64/nagios/plugins/submit_check_result localhost TRAP 2 "test envoi trap - 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.

Installation des paquets SNMPD, SNMPTRAPD et SNMTT

Bien entendu, il faut un serveur SNMP capable de capturer les traps, ainsi que le paquet qui va les translater vers Shinken. Voici les étapes à suivre:

Installation des paquets et dépendances :

yum install net-snmp net-snmpd-utils net-snmp-perl snmptt

Note : le paquet net-snmp est pour la partie serveur, et net-snmpd-utils est pour la partie cliente afin de diagnostiquer plus rapidement des problèmes SNMP sur vos serveurs. Mais ce n'est pas obligatoire. Les paquets net-snmp-perl et snmptt permettront de translater les traps.
Pour activer le démarrage des services SNMP au démarrage du serveur avec la commande suivante :

chkconfig --level 3 snmpd on;chkconfig --level 3 snmptrapd on

Démarrer les services snmpd et snmptrapd :

service snmpd start;service snmptrapd start;service snmptt start

Vous pouvez alors tester de passer une requête via les outils clients SNMP, sur son propre serveur pour vérifier la bonne communication :

snmpwalk -v 1 -c public -O e 127.0.0.1

La commande doit retourner une réponse comme par exemple :

SNMPv2-MIB::sysDescr.0 = STRING: Linux Shinken 2.6.32-504.16.2.el6.x86_64 #1 SMP Wed Apr 22 06:48:29 UTC 2015 x86_64
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (31359) 0:05:13.59
SNMPv2-MIB::sysContact.0 = STRING: Root <root@localhost> (configure /etc/snmp/snmp.local.conf)
SNMPv2-MIB::sysName.0 = STRING: shinken
SNMPv2-MIB::sysLocation.0 = STRING: Unknown (edit /etc/snmp/snmpd.conf)
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (64) 0:00:00.64
SNMPv2-MIB::sysORID.1 = OID: SNMP-MPD-MIB::snmpMPDMIBObjects.3.1.1
SNMPv2-MIB::sysORID.2 = OID: SNMP-USER-BASED-SM-MIB::usmMIBCompliance
SNMPv2-MIB::sysORID.3 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.4 = OID: SNMPv2-MIB::snmpMIB
SNMPv2-MIB::sysORID.5 = OID: TCP-MIB::tcpMIB
SNMPv2-MIB::sysORID.6 = OID: IP-MIB::ip
SNMPv2-MIB::sysORID.7 = OID: UDP-MIB::udpMIB
SNMPv2-MIB::sysORID.8 = OID: SNMP-VIEW-BASED-ACM-MIB::vacmBasicGroup
(...)

Interpréteur de trap SNMP

Maintenant que l’on est capable de recevoir des trap, il faut les interpréter pour dialoguer ensuite avec 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.

unknown_trap_log_enable = 1

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

disableAuthorization yes
donotlogtraps  no
traphandle default /usr/sbin/snmptt