Gestion des traps SNMP sous Centreon

1 Présentation

Dans cet article, les versions logicielles utilisées sont les suivantes : 

- Centreon 2.4.x ;

- snmptt 1.3 ;

- Centreon Engine 1.3.0 ;

- Centreon Broker 2.4.0.

L'installation de la suite logicielle Centreon sera réalisée au moyen de CES Standard (Centreon Enterprise Server) disponible en libre téléchargement à l'adresse : http://www.centreon.fr/Article-Telechargements/telecharger-ces.

1.1 Description, contexte et utilisation

Le protocole SNMP (RFC 1157, 1215) définit le concept de trap1. Un trap ou une interruption SNMP est un message contenant un ensemble d'informations prédéfini, via des fichiers MIBs2, permettant de décrire une situation à un moment donné. Les fichiers MIBs, définis par le constructeur/équipementier ou par l'éditeur du logiciel, définissent l'ensemble des différents arguments pouvant être contenus dans une interruption.

Exemple de définition d'une interruption SNMP : 

La définition de l'interruption linkDown, qui est générée lorsque l'état d'un port réseau passe du statut de Up à Down, décrit que trois arguments : ifIndex, ifAdminStatus et ifOperStatus seront liés à cette interruption.

Un agent installé sur les équipements réseau ou sur les systèmes d'exploitation permettra, suivant son paramétrage, de transmettre l'interruption SNMP vers un ou plusieurs collecteurs. Une fois défini, si un certain événement se produit, comme le dépassement d'un seuil, l'agent envoie un paquet UDP à un collecteur. Ce processus d'alerte est utilisé dans les cas où il est possible de définir simplement un seuil d'alerte (exemple de la température CPU qui dépasse un seuil prédéfini).

La collecte et le traitement des interruptions SNMP font partie intégrante de la supervision d'un système d'information puisque celles-ci sont envoyées sans délai lorsque l'agent détecte un problème. Cependant, le protocole de transport UDP ne garantit pas la réception de l'événement par le collecteur. En cas de mauvais paramétrage de l'agent ou de congestion réseau, ces traps SNMP peuvent ne pas parvenir à destination.

1.2 Protocole et version

Les interruptions SNMP sont envoyées en utilisant le protocole de transport UDP3 à destination du port 162. Elles sont émises sans sollicitation du collecteur.

1.2.1 Version 1

La version 1 du protocole SNMP est décrite dans la RFC 1157 et utilise les champs suivants : 

- SNMP-VERSION : version SNMP, obligatoirement 1.

- SNMP-COMMUNITY : communauté SNMP. Permet d'autoriser/filtrer la réception des interruptions sur le collecteur.

- IP-DESTINATION : adresse IP ou nom DNS du collecteur d'interruptions.

- ENTREPRISE-OID : OID4 « racine » du constructeur. Nœud à partir duquel le constructeur a défini les interruptions SNMP.

- IP-SOURCE : adresse IP ou nom DNS de l’émetteur de l'interruption.

- TRAP-TYPE : type d'interruption tel que linkUp, linkDown, coldstart, warmstart, authenticationfailure pour la partie commune de la MIB SNMPv2 ou '6' pour une interruption spécifique constructeur.

- TRAP-OID : OID qui sera concaténé à l'objet ENTERPRISE-OID pour former l'OID complet de l'interruption.

- UPTIME : temps d'activité en secondes depuis le démarrage de l'équipement.

Dans le cas d'ajout de paramètre, 3 variables sont à ajouter pour chaque paramètre : 

- OID-PARAMETRE : OID qui sera concaténé à l'objet ENTERPRISE-OID pour former l'OID complet du paramètre.

- TYPE-PARAMETRE : type de la valeur du paramètre : i pour integer, s pour string, ...

- VALEUR-PARAMETRE : valeur du paramètre.

Voici un exemple de génération de trap SNMP avec l'utilitaire snmptrap (Net-SNMP) : 

Le résultat obtenu est le suivant une fois réceptionné par le processus snmptrapd (/var/log/snmptrapd.log) : 

1.2.2 Version 2c

La version 2c du protocole ajoute quelques modifications par rapport à la version 1. Cette version a été conçue pour ajouter plus facilement de nombreux paramètres aux interruptions. Elle permet également la possibilité de valider la réception de l'interruption via un système d’acquittement (ACK), on parle alors de trap SNMPv2 INFORM.

Les champs utilisés sont les suivants : 

- SNMP-VERSION : version SNMP, par défaut '2c'.

- SNMP-COMMUNITY : communauté SNMP. Permet d'autoriser/filtrer la réception des interruptions sur le collecteur.

- IP-DESTINATION : adresse IP ou nom DNS du collecteur d'interruptions.

- OID-TRAP : OID complet de l’interruption.

- UPTIME : temps d'activité en secondes depuis le démarrage de l'équipement.

Dans le cas d'ajout de paramètre, 3 variables sont à ajouter pour chaque paramètre : 

- OID-PARAMETRE : OID complet du paramètre.

- TYPE-PARAMETRE : type de la valeur du paramètre : i pour integer, s pour string, ...

- VALEUR-PARAMETRE : valeur du paramètre.

Voici un exemple de génération de trap SNMP, sans acquittement, avec l'utilitaire snmptrap (Net-SNMP) : 

Pour générer manuellement une interruption avec acquittement, il suffit d'utiliser la même commande avec le programme snmpinform en lieu et place du programme snmptrap.

Le résultat obtenu est le suivant une fois réceptionné par le processus snmptrapd (/var/log/snmptrapd.log) : 

1.2.3 Version 3

La version 3 du protocole ajoute le chiffrement des données. Nous ne nous attarderons pas sur cette version du protocole car sa mise en place est assez difficile et demande de nombreux efforts et du temps.

1.3 Fonctionnement global

Avant de commencer la configuration et la mise en place de la réception des interruptions SNMP sur notre plate-forme Centreon, commençons par étudier le fonctionnement global.

Dans un premier temps, l'équipement ou l'application génère une interruption SNMP à destination de notre collecteur. Ce dernier reçoit l'événement par l'intermédiaire du démon snmptrapd. Ce démon a pour but de filtrer les événements suivant leur communauté (v1 et 2c du protocole) et de transférer l'événement à une autre application. Dans le cas où la communauté SNMP n'est pas valide, le traitement est stoppé.

Puis le démon snmptrapd va transmettre l'interruption au binaire snmptt. Ce programme permet de traduire l'événement en un format préalablement défini dans les fichiers de configuration. Dans le cas où la traduction est impossible, le traitement est arrêté, sinon ce dernier est transmis à Centreon pour traitement.

L'interruption traduite ainsi que ces arguments sont transmis au binaire centTrapHandler-2.x qui aura pour but de sélectionner à partir de la base de configuration de Centreon (base de données centreon), le nom de l'hôte et du service auquel est lié l'OID principal du trap SNMP.

Une fois la correspondance effectuée, charge au processus CentCore d'envoyer une commande externe à l'ordonnanceur. Cette commande permet de modifier le statut ainsi que le message de sortie (output) du service. Cela à partir de l'interruption traduite par snmptt et de la sévérité associée à la définition du trap SNMP dans l'interface Centreon.

2 Configuration des logiciels tiers

Dans ce chapitre, nous allons aborder la configuration des différentes entités permettant la réception et le traitement des interruptions SNMP. Nous aborderons la configuration d'un serveur central (serveur Centreon) puis celle d'un collecteur distant. Nous configurons les éléments tels que définis dans le schéma représenté en figure 1.

2.1 Serveur Central (à partir de CES)

L'installation des éléments sera réalisée lors de l'installation de la distribution CES ou lorsque l'utilisateur aura ajouté les dépôts yum nécessaires et installé le paquet centreon-<version>, dans notre cas centreon-2.4. Une documentation d'installation est disponible ici : http://documentation.centreon.com.

2.1.1 Paramétrage du pare-feu

Par défaut sur CES, le pare-feu est désactivé. Si iptable est activé, il faut obligatoirement ajouter une règle autorisant, en réception, le flux UDP sur le port 162. Pour cela, utilisez la commande suivante : 

Pour lister les règles en cours d'usage par le pare-feu, utilisez la commande suivante : 

Votre règle sera alors présente : 

Il est également important de vérifier si des pare-feu réseau sont présents entre les équipements qui émettront des interruptions SNMP et le serveur Centreon. Le protocole utilisant le transport UDP, l'émetteur ne pourra en aucun cas déterminer si le flux est autorisé ou non et l'événement pourra ne pas être acheminé.

2.1.2 Collecteur de traps snmptrapd

Lors de l'installation de ce composant par Centreon, une configuration minimale mais fonctionnelle a été mise en place. Celle-ci est définie dans le fichier /etc/snmp/snmptrapd.conf telle que : 

La directive disableAuthorization permet de désactiver tous les contrôles et accepte toutes les interruptions SNMP entrantes.

La directive traphandle permet de transférer les interruptions SNMP reçues au binaire snmptthandler en lui précisant son fichier de configuration (snmptt.ini).

L'activation de la journalisation des traps SNMP reçus n'est par défaut pas activée. L'activation de la journalisation sera vue au chapitre « 5.1.3 FAQ - snmptrapd ».

2.1.3 Traducteur snmptt

Les interruptions provenant du démon snmptrapd sont déplacées dans un répertoire de traitement /var/spool/snmptt/ afin d'être ensuite analysées par le démon snmptt. La configuration de ce dernier réside dans son fichier principal, à savoir snmptt.ini ainsi que dans les fichiers de définition des interruptions SNMP présents dans le répertoire /etc/snmp/centreon_traps et générés depuis l'interface web Centreon.

Le fichier /etc/snmp/centreon_traps/snmptt.ini fourni lors de l'installation de Centreon décrit les paramètres nécessaires à la traduction des traps SNMP sans activer le débogage. L'activation de la journalisation sera vue au chapitre « 5.1.4 FAQ - snmptt ».

Les fichiers de traduction des interruptions SNMP sont générés à partir des définitions enregistrées en base de données centreon. Il est possible d’accéder aux définitions en utilisant l'interface web Centreon via le menu « Configuration > SNMP Traps ».

Une fois les définitions modifiées, il est nécessaire de régénérer les fichiers de configuration du binaire snmptt au travers de l'interface. Pour cela, rendez-vous dans le menu « Configuration > SNMP Traps > Generate », sélectionnez le serveur (ici le central), cochez les cases « Generate configuration files for SNMP Traps (snmptt) » et « Apply configurations », puis cliquez sur le bouton « Generate ».

Lors de la génération de la configuration, seules les définitions des traps SNMP qui sont liées à des services dans la configuration Centreon seront générées. En effet, contrairement aux précédentes versions de Centreon, seules les interruptions utiles sont générées, permettant d’utiliser SMNPTT pour filtrer les événements transférés au processus suivant. Les fichiers générés seront liés au fichier de configuration snmptt.ini au travers du bloc suivant : 

2.1.4 Binaire centTrapHandler-2.x

Comme vu au chapitre « 1.3 Fonctionnement global », le binaire centTrapHandler-2.x a pour but de sélectionner dans Centreon le nom du service et de l'hôte dont le processus snmptt a traduit l'interruption. Cela, grâce aux informations provenant de l'événement : adresse IP ou DNS de l'équipement émetteur et à l'OID du trap SNMP.

Aucune configuration spéciale n'est à réaliser, sauf dans le cas d'une base de données déportée sur un serveur distant. Dans ce cas, il faudra vérifier les paramètres du fichier /etc/centreon/conf.pm, notamment l'adresse IP du serveur distant ainsi que les paramètres du compte utilisateur MySQL : 

2.1.5 Processus CentCore

Le processus CentCore doit être démarré sur le serveur Central. C'est lui qui recevra la commande externe générée par le binaire centTrapHandler-2.x pour la transférer au fichier de commandes externes de l'ordonnanceur qui supervise l'hôte.

Afin que le processus CentCore puisse transmettre correctement la commande externe, il est important de vérifier la localisation de ce fichier défini via le menu « Configuration > Monitoring > Engines > main.cfg > <collecteur> » pour le champ « External Command File ».

2.1.6 Validation de la configuration

Lorsque l'on modifie la définition des traps SNMP ou que l'on associe des interruptions à un service passif, il est nécessaire de régénérer la configuration des fichiers du binaire snmptt ainsi que de redémarrer ce dernier afin de prendre en compte les nouvelles définitions. Ce redémarrage est nécessaire lorsque l'on utilise snmptt en mode démon (par défaut avec Centreon 2.4). Ce redémarrage est possible via l'interface Centreon si la configuration de l'accès au script de démarrage est correctement paramétrée.

Connectez-vous à l'interface web Centreon avec un compte possédant les droits nécessaires et rendez-vous dans le menu « Configuration > Centreon > Pollers » et éditez la définition du serveur central. Vérifiez que le champ « SNMPTT init script path » contient la valeur /etc/init.d/snmptt.

Il sera alors possible de redémarrer le démon snmptt via l'interface en cochant la case « Restart SNMPTT » depuis le menu « Configuration > SNMP Traps > Generate ».

2.2 Collecteur

La configuration des collecteurs est légèrement différente. En effet, la base de données n'étant pas localisée sur le serveur lui-même, le binaire centTrapHandler-2.x devra posséder un compte d'accès distant. Cela sera vu au chapitre « 2.2.4 Accès distant à la base de données centreon ».

Lors de l'installation d'un collecteur, CES installe les paquets suivants : 

- centreon-poller-centreon-engine ;

- centreon-snmptt ;

- centreon-trap.

Le paquet centreon-snmptt permet d'installer les composants nécessaires à la traduction des interruptions SNMP tandis que le paquet centreon-trap permet de paramétrer le démon snmptrapd. Le dernier paquet centreon-poller-centreon-engine permet de créer le répertoire /etc/centreon et d'appliquer les droits utilisateur centreon.

2.2.1 Paramétrage du pare-feu

Si le pare-feu est activé sur le collecteur, créez une règle pour accepter le flux des interruptions SNMP à partir du chapitre « 2.1.1 Paramétrage du pare-feu ». Pensez également à activer l'autorisation du flux sur les pare-feu se trouvant entre vos équipements et le collecteur.

2.2.2 Collecteur de traps snmptrapd

Le collecteur d'interruptions SNMP, à savoir snmptrapd, est installé par défaut sur CentOS et sur la plupart des systèmes d'exploitation. La configuration est identique au chapitre « 2.1.2 Collecteur de traps snmptrapd ». Nous ne reviendrons pas sur cette configuration.

2.2.3 Traducteur snmptt

Tout comme sur un serveur central Centreon, le binaire snmptt a pour but de générer le message (output) qui sera envoyé à l’ordonnanceur à partir de la définition du trap SNMP et des arguments qui lui sont liés. La configuration est identique au chapitre « 2.1.3 Traducteur snmptt ».

2.2.4 Accès distant à la base de données « centreon »

Sur un collecteur distant, le binaire centTrapHandler-2.x a également besoin d'un accès à la base de données Centreon afin de sélectionner l'hôte émetteur de l'interruption et le service auquel est lié la définition du trap. Un accès distant depuis le collecteur doit donc être mis en place. Pour cela, connectez-vous à la base de données MySQL du serveur Centreon avec un compte possédant les droits nécessaires à la création d'un utilisateur, de préférence l'utilisateur 'root' et exécutez la commande suivante : 

Remplacez <IP_POLLER> par l'adresse IP du collecteur distant et mémorisez le mot de passe que vous avez défini pour l'utilisateur centreon pour le champ <PASSWORD>.

2.2.5 Binaire centTrapHandler-2.x

Afin de se connecter à la base de données centreon, le binaire doit récupérer des paramètres valides de connexion à partir du fichier de configuration /etc/centreon/conf.pm du collecteur. Éditez ce fichier et modifiez les champs <IP_SERVER_MYSQL> et <PASSWORD> en rouge ci-dessous : 

Vérifiez également que le chemin vers le fichier de commande de l'ordonnanceur défini par la variable $cmdFile est correct.

Pour tester la validité des paramètres, vous pouvez exécuter la commande suivante à partir d'un terminal Shell, vous devez obtenir le message suivant : 

2.2.6 Validation de la configuration

Se reporter au chapitre « 2.1.6 - Validation de la configuration » et vérifier le paramètre pour votre collecteur.

3 Configuration Centreon

Une fois le socle logiciel mis en place, reste la configuration des interruptions SNMP et des services passifs à réaliser dans l'interface Centreon. Ce chapitre aborde chaque étape : de l'importation des définitions SNMP via les fichiers MIBs jusqu'à la réception et validation du fonctionnement au travers de services de tests servant d'exemple.

3.1 Import des MIBs

Afin que le binaire snmptt puisse traduire les interruptions SNMP, les fichiers MIBs fournis par les constructeurs doivent être importés dans l'interface Centreon et liés à un constructeur.

Connectez-vous à l'interface Centreon avec un compte administrateur ou possédant des droits nécessaires pour accéder au menu « Configuration > SNMP Traps > Manufacturer » et vérifiez si votre constructeur est déjà présent.

Si ce dernier n'est pas visible, créez-le via le bouton « Add » et saisissez les champs « Vendor Name » et « Alias » puis sauvegardez vos modifications : 

Une fois la définition de votre constructeur validée, les fichiers MIBs peuvent être importés dans l'interface Centreon. Si ces derniers nécessitent des dépendances pour être importés, celles-ci doivent au préalable avoir été copiées sur le serveur Centreon dans le répertoire /usr/share/snmp/mibs.

Rendez-vous dans le menu « Configuration > SNMP Traps > Manufacturer », sélectionnez votre constructeur et votre fichier MIB : 

Si l'importation s'est correctement déroulée, le message suivant doit apparaître sur l'interface Centreon : 

3.2 Configuration des traps SNMP

Lors de l'importation des interruptions SNMP, il est fort probable que toutes les définitions aient pour statut le statut OK. En effet, peu de constructeurs définissent la sévérité des traps dans les fichiers MIBs et l’appréciation des statuts peut différencier d'un utilisateur à un autre. De plus, le niveau de sévérité défini dans les RFC propose plusieurs niveaux (normal, warning, minor, major, critical, indeterminate) contre les habituels statuts de votre ordonnanceur favori (ok, warning, critical, unknown).

Il est donc important de vérifier le statut associé à l'interruption avant de lier cette dernière à un service passif.

En plus du statut, l'option « Submit result » doit être cochée. Dans le cas contraire, aucune commande externe ne sera envoyée à l'ordonnanceur et par conséquent aucune alerte générée, ni de visualisation du résultat dans Centreon.

3.3 Configuration avancée des interruptions

Auparavant, les constructeurs définissaient un OID par type d'interruption. Aujourd'hui, il n'est pas rare qu'un même OID soit utilisé pour plusieurs types d'événements ou pour un événement ayant plusieurs statuts. C'est pourquoi Centreon répond à cette problématique grâce à l'utilisation de règles utilisant des regexp et pouvant être appliquées sur le message traduit de l'interruption ou sur un à plusieurs attributs de l'événement.

L'ordre de création des règles est important. En effet, le binaire centTrapHandler-2.x appliquera les règles une à une suivant leur ordre défini. La première corrélation avec le pattern de recherche déterminera le statut du service dans Centreon.

Pour appliquer la règle au message traduit par le binaire snmptt, il suffit d'utiliser la variable @OUTPUT@ dans le champ « String », comme ci-dessous : 

Pour appliquer la règle sur un ou plusieurs arguments de l'interruption SNMP, il suffit de définir la variable '$n' où n est le numéro du paramètre pour le champ « String » comme suit : 

3.4 Création d'un modèle de service passif

Un modèle de service est un objet qui possède toutes les caractéristiques d'un service et qui peut être utilisé comme base pour la configuration d'autres services. C'est concrètement un service pré-configuré. Un modèle de service passif est donc un modèle qui sera utilisé comme base pour l’ensemble des services passifs.

Connectez-vous à l'interface Centreon avec un compte administrateur ou possédant des droits nécessaires pour accéder au menu « Configuration > Services > Templates », puis cliquez sur le lien « add » :  

Les principales options de configuration sont : 

- Alias : nom du service qui sera créé lors d'un héritage, ici « service-generic-pasif ».

- Service Template Name : nom du modèle de service, ici « service-generic-pasif ».

- Is volatile : cocher la case « Yes ». Cette option sera abordée dans le chapitre suivant.

- Check Period : sélectionnez « 24x7 » car on ne sait jamais quand une interruption SNMP sera reçue !

- Check Command : sélectionnez de préférence « check_centreon_dummy » avec les arguments '0' et « No traps recived ».

- Max Check Attempts : positionnez la valeur '1'.

- Normal Check Interval : positionnez la valeur '1'.

- Retry Check Interval : positionnez la valeur '1'.

- Active Checks Enabled : sélectionnez la valeur « No ».

- Passive Checks Enabled : sélectionnez la valeur « Yes ».

- Notification Enabled : sélectionnez la valeur « Yes ».

- Notification Interval : positionnez la valeur '0'.

- Notification Period : sélectionnez « 24x7 » car il vaut mieux être notifié dès réception de l'événement.

- Notification Type : sélectionnez « Warning », « Unknown », « Critical », « Recovery ».

- First notification delay : positionnez la valeur '0'.

Puis sauvegardez votre modèle.

3.5 Service passif et notification

La principale différence entre un service actif récupérant de manière régulière une valeur et un service passif dont le statut et le message (output) proviennent de la réception d'interruptions SNMP est l'option « Is volatil ». Cette option permet de supprimer la validation de l'état non-OK du service. Dans le cas d'un service actif classique, il faut attendre que le service soit validé (état HARD) lorsque le nombre d'essais atteint le seuil pour que le processus de notification s'enclenche. Dans le cas d'un service volatil, le processus de notification est activé pour chaque statut non-OK du service, i.e. à chaque réception de trap SNMP dont le statut est problématique.

L'option « Is volatil » permet également d’enclencher le gestionnaire d'événements pour tout état non-OK.

Pour créer un service passif, il suffit de créer un simple service, de faire hériter celui-ci du modèle de service generic-service-passif, de lier ce dernier à un hôte et surtout de lui rattacher les définitions de traps SNMP. Pour cela, connectez-vous à l'interface Centreon avec un compte administrateur ou possédant des droits nécessaires pour accéder au menu « Configuration > Services > Services by host », puis cliquez sur le lien « add » et saisissez les informations suivantes : 

- Description : nom du service, ici « Traps-SNMP » ;

- Service Template : sélectionnez dans la liste déroulante le modèle précédemment créé service-generic-passif.

Sélectionnez ensuite les contacts et/ou groupes de contacts devant recevoir les notifications en cas de réception d'interruptions SNMP par votre plate-forme.

Dans l'onglet « Relation », sélectionnez l'hôte désiré. Dans ce même onglet, sélectionnez pour le champ « Service Trap Relation » votre constructeur. La liste des définitions des interruptions SNMP du constructeur est présente en dessous. Sélectionnez les définitions désirées pour les lier au service, puis sauvegardez le service.

Lorsque des traps SNMP sont liés à un service, il est important de générer les fichiers de traduction de snmptt. En effet, depuis la version 2.4 de Centreon, seules les définitions liées à des services seront générées. Rendez-vous dans le menu « Configuration > SNMP Traps > Generate », sélectionnez le collecteur supervisant l'hôte auquel le service passif a été créé et cliquez sur le bouton « Generate ».

L'option « Restart SNMPTT » n'est utile que si le fonctionnement de snmptt utilise le mode démon, ce qui est paramétré par défaut sous CES 2.2, et si ce dernier est correctement paramétré dans la définition du collecteur sur Centreon. Voir le chapitre « 2.1.6 Validation de la configuration ».

4 Test et validation de fonctionnement

Afin de valider le fonctionnement de la réception des Traps SNMP sur la plate-forme de supervision, il peut être intéressant de paramétrer un hôte et service de test puis de générer à la main une interruption et vérifier que celle-ci est visible dans l'interface Centreon.

4.1 Ajout de définitions de traps pour les tests

Connectez-vous à l'interface Centreon, rendez vous dans le menu « Configuration > SNMP Traps > Manufacturer > Add » et créez le constructeur suivant : 

Les paramètres sont les suivants : 

- Vendor Name : test-constructeur ;

- Alias : Constructeur test ;

- Description : Constructeur virtuel pour les tests.

Une fois le constructeur créé, rendez-vous dans le menu « Configuration > SNMP Traps > SNMP Traps > Add » et créez les définitions suivantes : 

Les paramètres sont pour le premier trap SNMP : 

- Trap name : saisissez trap-snmp-ok.

- OID : saisissez .1.3.6.1.4.1.999. Le point devant le chiffre 1 est impératif, auquel cas la correspondance ne pourra être faite.

- Vendor Name : sélectionnez « Constructeur test ».

- Output Message : saisissez « Tout est OK ».

- Default Status : sélectionnez « OK ».

- Advanced matching mode : case non cochée.

- Submit result : case cochée.

- Reschedule associated services : case non cochée.

- Execute special command : case non cochée.

- Comments : saisissez ici votre commentaire, dans notre exemple « Interruption de test pour un état OK ».

Les paramètres sont pour le deuxième trap SNMP : 

- Trap name : saisissez trap-snmp-critical.

- OID : saisissez .1.3.6.1.4.1.998. Le point devant le chiffre 1 est impératif, auquel cas la correspondance ne pourra être faite.

- Vendor Name : sélectionnez « Constructeur test ».

- Output Message : saisissez « Probleme critique ».

- Default Status : sélectionnez « Critical ».

- Advanced matching mode : case non cochée.

- Submit result : case cochée.

- Reschedule associated services : case non cochée.

- Execute special command : case non cochée.

- Comments : saisissez ici votre commentaire, dans notre exemple « Interruption de test pour un état critique ».

4.2 Création d'un service passif de test

À partir du chapitre « 3.5 Service passif et notification », créez un service passif en utilisant le modèle « generic-service-passif », en liant le service à l'hôte « Centreon-Server » et en attachant les deux définitions d'interruption précédemment créées.

Pensez à générer la nouvelle configuration de l'ordonnanceur ainsi que celle des traps SNMP pour que notre plate-forme de test soit opérationnelle. Le service ci-dessous devrait apparaître dans l'interface Centreon dans le menu « Monitoring > Services > All services » : 

4.3 Validation du fonctionnement

Afin de tester le bon fonctionnement de la configuration, nous allons générer des interruptions SNMP en ligne de commandes. Vérifiez que le service créé au chapitre « 4.2 – Création d'un service passif de test » est en statut « OK ». Si tel n'est pas le cas, acquittez le service et pensez à cocher la case « Force active checks ».

Lancez un terminal shell et exécutez la commande suivante en modifiant <SNMP_COMMUNITY> par votre communauté : 

Une fois la commande lancée, vous devriez avoir un statut CRITICAL pour votre service : 

Pour changer le statut en OK, exécutez la commande suivante en modifiant <SNMP_COMMUNITY> par votre communauté : 

Une fois la commande lancée, vous devriez avoir un statut OK pour votre service : 

Dans le cas où votre service ne change pas de statut pour les deux commandes ci-dessous, reportez vous au chapitre « 5.1 – Les traps SNMP ne sont pas visibles dans Centreon ». Si par contre le service a changé de statut pour la première interruption (service en état critique) et non pour la deuxième, cela peut signifier que : 

- Vous avez fait une faute de frappe dans la seconde commande.

- Vous avez fait une faute de frappe dans la définition du trap trap-snmp-ok.

- Vous avez oublié de lier la définition trap-snmp-ok au service.

- Vous avez oublié de générer les fichiers de traduction de snmptt après création de la définition trap-snmp-ok.

5 FAQ

Le chapitre des questions fréquentes abordera dans un premier temps la méthodologie complète à mettre en œuvre afin d'identifier la cause du problème et la résolution à apporter. La seconde partie permettra d'optimiser le temps de traitement des traps SNMP en activant la fonction démon du binaire snmptt. Cela permet sur des environnements à forte réception d'interruptions SNMP de diminuer les I/O, la consommation CPU et mémoire.

5.1 Les traps SNMP ne sont pas visibles dans Centreon

La mise en place de la supervision d'interruptions SNMP demande de configurer de nombreux programmes et objets dans Centreon. Cette complexité de la configuration augmente la possibilité d'oublis de configuration d'un élément ainsi que le nombre d'erreurs de configuration. Ce chapitre explique point par point tous les éléments à vérifier en cas de non mise à jour d'un service passif dans Centreon.

5.1.1 Configuration de l'émetteur

Le premier point à contrôler est la configuration de l'équipement ou application qui a émis l'interruption que vous auriez dû recevoir. Vérifiez l'adresse IP ou le nom DNS de destination, la communauté SNMP ainsi que la version du protocole.

5.1.2 Pare-feu réseau et logiciels, routage

Le second point à contrôler est la mise en place d'un routage spécifique ou les autorisations des pare-feu réseau et logiciels. Si un ou plusieurs pare-feu réseau sont présents ou si une translation de port et/ou d'adresse IP est en place, vérifiez que le flux est possible entre l'émetteur et le collecteur.

L'utilisation de sondes réseau, de débogage des équipements réseau (pare-feu et routeurs) ou des logiciels tcpdump/wireshark sur le collecteur peut vous permettre de valider la réception du flux de données sur le port UDP 162.

5.1.3 snmptrapd

Une fois la réception du flux validée, vérifiez l'état de fonctionnement du processus snmptrapd, qui doit être en cours d'exécution, ainsi que ses options de configuration. Pour vérifier la configuration du processus, reportez-vous aux chapitres « 2.1.2 ou 2.2.2 - Collecteur de traps snmptrapd ».

Il est possible d'activer la journalisation du processus. Pour cela, modifiez le fichier /etc/sysconfig/snmptrapd.options et remplacez la ligne OPTIONS pour avoir : 

Redémarrez le processus pour prendre en compte les modifications. Ainsi, pour toute réception de traps SNMP, ces événements seront inscrits dans le journal /var/log/snmptrapd.log. Si les événements sont inscrits dans le journal, supprimez la journalisation et passez à l'étape suivante.

Dans le cas où vous filtrez par communauté SNMP, vérifiez les communautés autorisées dans le fichier de configuration /etc/snmp/snmptrapd.conf. Si après toutes ces vérifications les traps SNMP ne sont pas inscrits dans le journal, vérifiez que le processus écoute sur le port UDP 162 pour les équipements distants en utilisant la commande : 

Si tel n'est pas le cas, modifiez le port d'écoute du processus.

5.1.4 snmptt

Une fois la validation du processus snmptrapd réalisée, contrôlez le processus snmptt. La première étape consiste à vérifier l'appel de ce processus par snmptrapd dans le fichier /etc/snmp/snmptrapd.conf grâce à la commande ls. Si l'accès au fichier est incorrect, modifiez-le et redémarrez le processus snmptrapd.

Il est possible d'activer le débogage du processus snmptt pour journaliser les interruptions traduites et non traduites. Pour cela, éditez le fichier /etc/snmp/centreon_traps/snmptt.ini et modifiez les instructions suivantes : 

Ainsi, les interruptions SNMP traduites seront inscrites dans le fichier snmptt.log et les autres dans le fichier snmpttunknown.log. Si vos traps SNMP ne sont pas traduits, vérifiez les points suivants : 

- Les droits d'accès sur le fichier /etc/snmp/centreon_traps/snmptt.ini doivent être ceux de l’utilisateur et du groupe centreon.

- Vous devez générer les fichiers de traduction de snmptt après chaque ajout/modification de définition de traps SNMP.

- Le fichier de définition de traps SNMP du constructeur doit être présent dans le répertoire /etc/snmp/centreon_traps/.

- Le fichier de définition de traps SNMP du constructeur doit être chargé dans le fichier snmptt.ini dans le bloc [TrapFiles].

- Si le processus snmptt est en mode démon, ce dernier doit être redémarré après chaque génération des fichiers de traduction pour prendre en compte les changements.

- Si le fichier constructeur est présent et correctement chargé par snmptt, vérifiez la définition du trap SNMP au travers de l'interface Centreon.

Si votre configuration est correcte, les événements doivent être inscrits dans le fichier /var/log/snmptt.log.

5.1.5 centTrapHandler-2.x

Le prochain binaire est celui de Centreon qui permet de sélectionner l'hôte possédant l'adresse IP ou le nom DNS de l'émetteur ainsi que le service lié à cet hôte et auquel est reliée la définition de l'interruption SNMP. Pour vérifier son fonctionnement, il suffit d'exécuter en ligne de commandes ce script avec les arguments du trap et vérifier qu'une commande externe est envoyée : 

- à Centcore pour un serveur central ;

- à l'ordonnanceur pour un collecteur ;

- via le fichier de commande/pipe en vérifiant les journaux.

La commande est la suivante : 

Si tout s'est bien déroulé, aucun message d'erreur ne doit être présent lors de l'exécution de la commande. Dans le cas contraire, corrigez les erreurs et/ou installez les modules Perl manquants. Il est possible d'activer le débogage du binaire centTrapHandler-2.x en ajoutant/modifiant la variable $debug = 1; ligne 78.

5.1.6 CentCore

Dans le cas d'un serveur central, le processus Centcore doit être démarré pour transférer la commande externe à l'ordonnanceur supervisant l'émetteur, vérifiez son état de fonctionnement. Activez le débogage du processus en ajoutant le variable $debug = 1 ; au fichier /usr/share/centreon/bin/centcore ligne 60 et redémarrez le processus.

En cas de non-réception de la commande externe, vérifiez le chemin d'accès au fichier de commande du process défini dans la variable $cmdFile du fichier de configuration /etc/centreon.conf.pm. Le chemin doit être /var/lib/centreon/centcore.cmd dans le cas d'un serveur central ou le chemin vers le fichier de commande de l'ordonnanceur.

5.1.7 Ordonnanceur

Que vous ayez configuré un serveur central ou un collecteur distant pour la réception de traps SNMP, l'ordonnanceur doit recevoir la commande externe de changement de statut et/ou de message de sortie (output). Vérifiez le journal de l'ordonnanceur. Dans le cas de Centreon Engine, le fichier est /var/log/centreon-engine/centengine.log. Les lignes suivantes doivent apparaître : 

Si seule la commande externe apparaît mais pas la prise en compte de celle-ci par l'ordonnanceur (« PASSIVE SERVICE CHECK »), il se peut qu'un problème de synchronisation de l'horloge système soit en cause. Le serveur est soit en retard et la commande sera traitée ultérieurement, soit en avance et la commande ne sera pas prise en compte.

5.1.8 Centreon

Afin d'être visible dans Centreon, l'ordonnanceur doit transmettre les informations, via son module NEB, à la partie serveur du broker pour que ce dernier l'insère en base de données. Centreon affichera ensuite le résultat à partir de la base de données centreon_status.

S'il vous est possible de visualiser les informations des derniers contrôles de votre collecteur dans l'interface web, alors vous devriez voir le statut et le message de sortie (output) modifiés. Si tel n'est pas le cas, alors votre ordonnanceur n'est pas connecté à la partie serveur de votre broker. Les problèmes peuvent être les suivants : 

- L'ordonnanceur n'a pas chargé le module NEB à son démarrage car celui-ci est introuvable ou non défini dans les options de l'ordonnanceur.

- Le module NEB n'a pu se connecter à la partie serveur à cause d'un problème de paramétrage.

- Un pare-feu bloque la connexion entre le collecteur et le serveur Centreon qui héberge la base de données.

- La partie serveur du broker n'est pas fonctionnelle ou n'est pas en cours d'exécution.

5.1.9 Schéma détaillé

Vous trouverez ci-dessous un schéma détaillé de tous les processus utilisés et/ou présents lors de la réception d'une interruption SNMP : 

Références

- Documentation Centreon : http://documentation.centreon.com/

- Documentation Nagios : http://nagios.sourceforge.net/docs/3_0/passivechecks.html

- Net-SNMP : http://net-snmp.sourceforge.net/wiki/index.php/