Je vais vous présenter le fonctionnement d'une interruption (Trap) SNMP à travers d'un exemple pratique. Nous n'utiliserons pas le mode distribué (centcore) dans cet exemple.
Je vous propose la lecture suivantes de mes articles :
   - Ci-dessous, un résumé sur la configuration SNMP sur Debian en SNMP V2 et V3 ainsi que les premiers paramétrages de centreon
   - L'importation de mibs dans Centreon
   - Les traps SNMP, leurs configurations pour Debian et une explication du fonctionnement des traps SNMP avec SNMPTT et Centreon postérieur à 2.5x
   - Traps avec Centreon 2.4, configuration des traps avec la version Centreon 2.4x
   - Traps avec Centreon 2.5, configuration des traps avec la version Centreon 2.5x
   - Les traps avec CES et Centreon 2.5, configuration d'une architecture distribuée avec CES 3.x
   - Le module Centreon-DSM v2 avec Centreon-Web 2.7x
1 Configuration des Traps SNMP
Pour recevoir les traps il faut lancer le service SNMPTRAPD sur le serveur de supervision.
Debian 6 et 7
Modifiez le fichier /etc/default/snmpd
………
TRAPDRUN=yes
# snmptrapd options (use syslog).
TRAPDOPTS='-On -Lsd -p /var/run/snmptrapd.pid'
Debian 8
Modifiez le fichier /etc/default/snmptrapd
# snmptrapd control (yes means start daemon). As of net-snmp version
# 5.0, master agentx support must be enabled in snmpd before snmptrapd
# can be run. See snmpd.conf(5) for how to do this.
TRAPDRUN=yes
# snmptrapd options (use syslog).
TRAPDOPTS='-On -Lsd -p /var/run/snmptrapd.pid'
Si vous essayer le fonctionnement des Traps avant l'installation de Centreon, saisissez le paramètre suivant dans le fichier /etc/snmp/snmpdtrap.conf
disableAuthorization yes
2 Envoi des Traps SNMP au serveur de supervision
Pour envoyer les traps SNMP d'un serveur vers le serveur de supervision, il faut indiquer au service SNMPD l'adresse IP du serveur de supervision acceptant les Traps SNMP. Modifiez le fichier /etc/snmp/snmpd.conf et saisissez l'adresse IP du serveur de supervision et éventuellement le nom de la communauté SNMP.
trapsink 172.16.209.141 public
3 Les traps par la pratique
Vous avez suivi mes conseils pour la configuration du SNMP, c’est bien ! Maintenant, nous allons étudier avec un cas pratique le fonctionnement des traps SNMP. Nous n'utiliserons pas le mode distribué (centcore) dans cet exemple et nous utiliserons le mécanisme des traps de Centreon 2.4x avec SNMPTT.
On peut déjà vérifier le bon fonctionnement du protocole TCP 161
netstat -an | grep 161
Vous devriez obtenir ce résultat
udp 0 0 0.0.0.0:161 0.0.0.0:*
Pour vérifier le bon fonctionnement du service, ouvrez un deuxième terminal et saisissez la commande
tail -f /var/log/syslog
Lors du lancement du service SNMP, voici un exemple de ce que pouvez obtenir :
May 8 10:35:50 weblamp snmpd[26656]: iquerySecName has not been configured - internal queries will fail
May 8 10:35:50 weblamp snmpd[26656]: NET-SNMP version 5.4.3
La première ligne indique un paramètre non configuré, pour notre exercice, nous n'en tiendrons pas compte. Maintenant, vérifions que notre service SNMP fonctionne bien, lancez la commande à partir du serveur de supervision.
snmpwalk -c public -v 2c 172.16.209.142
Côté serveur supervision, vous devez normalement parcourir la MIB du serveur WebLamp
SNMPv2-MIB::sysDescr.0 = STRING: Linux weblamp 2.6.32-5-686 #1 SMP Thu Nov 3 04:23:54 UTC 2011 i686
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-TC::linux
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (59793) 0:09:57.93
SNMPv2-MIB::sysContact.0 = STRING: root
SNMPv2-MIB::sysName.0 = STRING: weblamp
SNMPv2-MIB::sysLocation.0 = STRING: Unknown
SNMPv2-MIB::sysORLastChange.0 = Timeticks: (0) 0:00:00.00
SNMPv2-MIB::sysORID.1 = OID: SNMP-FRAMEWORK-MIB::snmpFrameworkMIBCompliance
SNMPv2-MIB::sysORID.2 = OID: SNMP-MPD-MIB::snmpMPDCompliance
......
Côté terminal Syslog de Weblamp, vous visualisez les succès de connexions à conditions d’avoir le niveau d’information requis (exemple S7).
.....
May 8 10:45:49 weblamp snmpd[26656]: Connection from UDP: [172.16.209.141]:60066->[172.16.209.142]
May 8 10:45:49 weblamp snmpd[26656]: Connection from UDP: [172.16.209.141]:60066->[172.16.209.142]
May 8 10:45:49 weblamp snmpd[26656]: Connection from UDP: [172.16.209.141]:60066->[172.16.209.142]
May 8 10:45:49 weblamp snmpd[26656]: Connection from UDP: [172.16.209.141]:60066->[172.16.209.142]
.......
Notre serveur Weblamp est opérationnel, continuons par la configuration des traps SNMP. Modifions le fichier /etc/snmp/snmpd.conf pour autoriser l'envoi de trap vers le serveur de supervision.
trapsink 172.16.209.141 public
Relançons le service snmp.
service snmpd restart
Pour vérifier le fonctionnement des traps à partir du serveur Weblamp, nous pouvons installer le paquet tcpdump, il nous permettra de sniffer l'interface réseau et d'intercepter les trames SNMP. Tout d'abord, installons le paquet tcpdump.
apt-get install tcpdump
Ensuite, dans un terminal, lançons l'écoute du port 162 sur l'interface réseau eth0
tcpdump -i eth0 port 162
Relancer le service SNMP et vous devrez visualiser deux trames SNMP correspondantes aux traps.
s16:13:56.162552 IP weblamp.localmac.34657 > supervision.localmac.snmp-trap:
Trap(29) E:8072.4 172.16.209.142 enterpriseSpecific s=2 1473677
16:13:58.222752 IP weblamp.localmac.59625 > supervision.localmac.snmp-trap:
Trap(29) E:8072.3.2.10 172.16.209.142 coldStart 0
Les messages indiquent la source (weblamp.localmac) et la destination (supervision.localmac). Ce trap SNMP indique le redémarrage du service.
3.1 L'utilité de la MIB
Avec la commande snmptrap, nous pouvons déclencher un trap SNMP à la demande. Pour l'exemple, nous prendrons l'évènement détectant l'a connectivité de l'interface réseau. Saisissez la commande :
snmptrap -v2c -c public 172.16.209.141 '' .1.3.6.1.6.3.1.1.5.3 ifIndex i 1 ifadminStatus i 2 ifOperStatus i 2
Malheureusement, vous avez droit à un beau message d'erreur.
MIB search path: /root/.snmp/mibs:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:
/usr/share/mibs/ietf:/usr/share/mibs/netsnmp
.....
ifIndex: Unknown Object Identifier (Sub-id not found: (top) -> ifIndex)
En effet, la commande que vous venez de saisir n'est pas comprise par le service SNMP. Le protocole SNMP ne comprend que les objets appelés OID en numérotation pointée, donc la solution serait de saisir la ligne de commande comme ceci.
snmptrap -v2c -c public 172.16.209.141 '' .1.3.6.1.6.3.1.1.5.3 .1.3.6.1.2.1.2.2.1.1 i 1 .1.3.6.1.2.1.2.2.1.7 i 2 .1.3.6.1.2.1.2.2.1.8 i 2
Nous avons remplacé les paramètres ifIndex, ifadminStatus, ifOperStatus par leur OID respectif. Malgré des messages d'avertissement vous indiquant qu'il n'existe aucune MIB, vous pouvez visualiser le trap avec tcpdump décrit précédemment.
07:43:15.764810 IP weblamp.localmac.44710 > supervision.localmac.snmp-trap: V2Trap(105)
system.sysUpTime.0=16656516 S:1.1.4.1.0=S:1.1.5.3 interfaces.ifTable.ifEntry.ifIndex=1
interfaces.ifTable.ifEntry.ifAdminStatus=2 interfaces.ifTable.ifEntry.ifOperStatus=2
Pour améliorer la compréhension des OID, nous avons besoin d'un dictionnaire traduisant les OID en texte accessible aux humains. Ce dictionnaire est en fait une multitude de fichier ASCII décrivant l'arborescence SNMP constituée d'OID.Ajoutons les mibs
Suite à un problème de licence, ce paquet n'est pas libre au sens Debian, il faut rajouter le dépôt non-free pour l'accès à la mise à jour. Modifiez le fichier /etc/apt/sources.list. Rajoutez non-free sur les dépôts. Pour la version Debian 6
Suite à un problème de licence, ce paquet n'est pas libre au sens Debian, il faut rajouter le dépôt non-free pour l'accès à la mise à jour. Modifiez le fichier /etc/apt/sources.list. Rajoutez non-free sur les dépôts. Pour la version Debian 6
deb http://ftp.fr.debian.org/debian/ squeeze main non-free
deb-src http://ftp.fr.debian.org/debian/ squeeze main non-free
pour la version Debian 7
deb http://ftp.fr.debian.org/debian/ wheezy main non-free
deb-src http://ftp.fr.debian.org/debian/ wheezy main non-free
et pour la version Debian 8
deb http://ftp.fr.debian.org/debian/ jessie main non-free
deb-src http://ftp.fr.debian.org/debian/ jessie main non-free
Faites une mise à jour de la base apt et installer le paquet des MIBS.
apt-get update
apt-get install snmp-mibs-downloader
Créons un lien symbolique pour associer les mibs se situant dans /usr/share/mibs aux autres dossiers se trouvant dans /usr/share/snmp/mibs
ln -s /usr/share/mibs/ /usr/share/snmp/mibs
Modifiez le fichier /etc/default/snmpd pour indiquez le chemin de lecture des mibs et autorisons la lecture des sous-dossiers.
export MIBDIRS=/usr/share/snmp/mibs
export MIBS=ALL
Commentez la ligne du fichier /etc/snmp/snmp.conf s'il existe.
#mibs ALL
Redémarrez le service SNMP
service snmpd restart
pour Debian 8, ne pas oubliez le service snmptrapd.
service snmptrapd restart
Retentez la commande snmptrap précédente avec les OID en texte, vous ne deviez plus avoir de message d'erreur.
3.2 Fonctionnement avec SNMPTT
Notre serveur de supervision doit pouvoir accepter les traps SNMP. Pour cela, il faut configurer et activer le service SNMPTRAPD. Pour cela, modifiez le fichier /etc/default/snmpd du serveurde supervision si ce n'est pas déjà réalisé.
Le paramètre -Lsd correspond au niveau 7 du syslog, de cette manière, nous devrions voir le trap du serveur Weblamp avec la commande tail -f /var/log/syslog dans un terminal. Vérifions si notre service SNMPTRAPD écoute le port 162 avec cette commande
Le résultat est le suivant
Lançons un test de trap, à partir du serveur Weblamp,
Dans un terminal connecté sur le serveur de supervision avec la commande tail -f /var/log/syslog nous découvrons le message suivant, preuve que notre trap est bien arrivé sur le serveur de supervision.
Passons un cran plus haut dans la gestion des traps, le programme SMPTT s'appuie sur la configuration de Centreon. Préalablement, vous aurez généré les traps comme indiqué dans la rubrique SNMP et la supervision. Pour chaque trap SNMP, le service SNMPTRAPD va l'envoyer au programme SMPTT par l'intermédiaire de la commande traphandle générée par l'installation de Centreon.
Ensuite SNMPTT vérifie le trap si celui-ci correspond à un trap connu de la configuration de Centreon. Les configurations générées par Centreon se trouvent dans le dossier /etc/snmp/centreon_traps et ont pour extension conf.
Les traps inconnus seront écartés du système. Il serait intéressant de garder une trace de cette activité en configurant SNMPTT avec son fichier ini se trouvant dans le dossier /etc/snmp/centreon_traps. Modifier les lignes suivantes.
Les traps non répertoriés dans Centreon seront loggés dans le fichier snmpttunknown.log. SMPTT passe la main au script CentTrapHandler-2.x de Centreon. Celui-ci va vérifier la concordance de la provenance de l'hôte avec la base de données Centreon et s'il existe un service associé au trap. En cas de succès, ce script créé une commande externe au format nagios et la copie dans le fichier nagios.cmd.
# snmptrapd control (yes means start daemon). As of net-snmp version
# 5.0, master agentx support must be enabled in snmpd before snmptrapd
# can be run. See snmpd.conf(5) for how to do this.
TRAPDRUN=yes
# snmptrapd options (use syslog).
TRAPDOPTS='-On -Lsd -p /var/run/snmptrapd.pid'
Le paramètre -Lsd correspond au niveau 7 du syslog, de cette manière, nous devrions voir le trap du serveur Weblamp avec la commande tail -f /var/log/syslog dans un terminal. Vérifions si notre service SNMPTRAPD écoute le port 162 avec cette commande
netstat -an | grep 162
Le résultat est le suivant
udp 0 0 0.0.0.0:162 0.0.0.0:*
Lançons un test de trap, à partir du serveur Weblamp,
snmptrap -v2c -c public 172.16.209.141 '' .1.3.6.1.6.3.1.1.5.3 ifIndex i 2 ifadminStatus i 1 ifOperStatus i 1
Dans un terminal connecté sur le serveur de supervision avec la commande tail -f /var/log/syslog nous découvrons le message suivant, preuve que notre trap est bien arrivé sur le serveur de supervision.
May 10 07:30:49 supervision snmptrapd[2475]: 2012-05-10 07:30:49 weblamp.localmac [UDP: [
172.16.209.142]:49266->[172.16.209.141]]:#012.1.3.6.1.2.1.1.3.0 = Timeticks: (18567519)
2 days, 3:34:35.19#011.1.3.6.1.6.3.1.1.4.1.0 = OID: .1.3.6.1.6.3.1.1.5.3#011.1.3.6.1.2.1.2.2.1.1 =
INTEGER: 2#011.1.3.6.1.2.1.2.2.1.7 = INTEGER: 1#011.1.3.6.1.2.1.2.2.1.8 = INTEGER: 1
Passons un cran plus haut dans la gestion des traps, le programme SMPTT s'appuie sur la configuration de Centreon. Préalablement, vous aurez généré les traps comme indiqué dans la rubrique SNMP et la supervision. Pour chaque trap SNMP, le service SNMPTRAPD va l'envoyer au programme SMPTT par l'intermédiaire de la commande traphandle générée par l'installation de Centreon.
traphandle default /usr/local/centreon/bin/snmptt --ini=/etc/snmp/centreon_traps/snmptt.ini
Ensuite SNMPTT vérifie le trap si celui-ci correspond à un trap connu de la configuration de Centreon. Les configurations générées par Centreon se trouvent dans le dossier /etc/snmp/centreon_traps et ont pour extension conf.
ls *.conf
snmptt-3com.conf snmptt-HP-Compaq.conf snmptt-Linksys.conf
snmptt-Cisco.conf snmptt-HP.conf snmptt-Zebra.conf
snmptt-Dell.conf snmptt-Generic.conf
Les traps inconnus seront écartés du système. Il serait intéressant de garder une trace de cette activité en configurant SNMPTT avec son fichier ini se trouvant dans le dossier /etc/snmp/centreon_traps. Modifier les lignes suivantes.
log_enable = 1
log_file = /var/log/snmptt.log
unknown_trap_log_enable = 0
unknown_trap_log_file = /var/log/snmpttunknown.log
Les traps non répertoriés dans Centreon seront loggés dans le fichier snmpttunknown.log. SMPTT passe la main au script CentTrapHandler-2.x de Centreon. Celui-ci va vérifier la concordance de la provenance de l'hôte avec la base de données Centreon et s'il existe un service associé au trap. En cas de succès, ce script créé une commande externe au format nagios et la copie dans le fichier nagios.cmd.
Le script de centreon peut avoir deux modes de fonctionnement en fonction de l'architecture. Il arrive que celui-ci soit mal initialisé lors de son installation. Si vous avez des dysfonctionnements à ce stade, vérifiez la ligne ci dessous dans le script pour une installation standard :
$cmdfile="/usr/local/nagios/var/rw/nagios.cmd"
et pour un serveur central dans une installation distribuée, la ligne doit être modifiée comme ceci
$cmdfile="/var/lib/centreon/centcore.cmd"
Pour visualiser le bon fonctionnement de cette commande, il faudra scruter le fichier de log de Nagios avec la commande tail -f /usr/local/nagios/var/nagios.log
Par exemple, le redémarrage d'un service SNMP sur le serveur macdns donnera ceci.
Mais reprenons l'exemple avec notre serveur Weblamp, l'envoi de notre trap n'influe pas sur le fonctionnement de nagios et pour cause, l'hôte n'a pas été configuré dans Centreon.
Avec l'aide des rubriques sur la configuration de Centreon, créons notre hôte sans le service trap.
Voici la configuration avec l'application des modèles generic-host, OS-Linux-Debian6, Web-Linux, MySQL et notification-24x7.
La configuration créée, désactivez le service Traps_Debian. Appliquez la configuration à Nagios. Ensuite, relançons notre trap du serveur Weblamp en visualisant le fichier de log de Nagios. Nous aurons l'information ci-dessous.
Allons plus loin, supprimons les relations de Trap SNMP pour le modèle Traps_Debian.
Appliquons cette nouvelle configuration à Nagios et relançons le trap sur le serveur weblamp. Aucune commande externe ne s'affichera dans le fichier de log de Nagios, preuve que le script CentTrapHandler-2.x de Centreon vérifie l'existence de l'hôte et d'une relation existence de trap SNMP avec un service. Il est évident que celui-ci doit être actif pour que Nagios le prenne en compte.
Finalisons notre exemple. Rajoutez les traps dans notre modèle de service Traps_Debian. Activez le service pour l'hôte weblamp et appliquez la configuration à Nagios. Lancez le trap à partir du serveur weblamp.
Et voilà, notre exemple fonctionne. j'espère avoir été assez clair dans mes explications. Prochainement vous verrons le fonctionnement dans une architecture distribuée.
Par exemple, le redémarrage d'un service SNMP sur le serveur macdns donnera ceci.
[1336715130] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;macdns;Traps_Debian;1;SNMP is restarting
Mais reprenons l'exemple avec notre serveur Weblamp, l'envoi de notre trap n'influe pas sur le fonctionnement de nagios et pour cause, l'hôte n'a pas été configuré dans Centreon.
Avec l'aide des rubriques sur la configuration de Centreon, créons notre hôte sans le service trap.
Voici la configuration avec l'application des modèles generic-host, OS-Linux-Debian6, Web-Linux, MySQL et notification-24x7.
La configuration créée, désactivez le service Traps_Debian. Appliquez la configuration à Nagios. Ensuite, relançons notre trap du serveur Weblamp en visualisant le fichier de log de Nagios. Nous aurons l'information ci-dessous.
[1336728871] EXTERNAL COMMAND: PROCESS_SERVICE_CHECK_RESULT;weblamp;Traps_Debian;2;Link down on interface 1. State: .
[1336728871] Warning: Passive check result was received for service 'Traps_Debian' on host 'weblamp', but the service could not be found!
Allons plus loin, supprimons les relations de Trap SNMP pour le modèle Traps_Debian.
Appliquons cette nouvelle configuration à Nagios et relançons le trap sur le serveur weblamp. Aucune commande externe ne s'affichera dans le fichier de log de Nagios, preuve que le script CentTrapHandler-2.x de Centreon vérifie l'existence de l'hôte et d'une relation existence de trap SNMP avec un service. Il est évident que celui-ci doit être actif pour que Nagios le prenne en compte.
Finalisons notre exemple. Rajoutez les traps dans notre modèle de service Traps_Debian. Activez le service pour l'hôte weblamp et appliquez la configuration à Nagios. Lancez le trap à partir du serveur weblamp.
Et voilà, notre exemple fonctionne. j'espère avoir été assez clair dans mes explications. Prochainement vous verrons le fonctionnement dans une architecture distribuée.