Supervision avec déroutements SNMP

Retour à l'index de documentation du Pandora FMS

Les périphériques réseau qui prennent en charge le protocole SNMP, tels que les commutateurs, les routeurs, les serveurs, les imprimantes ou les points d'accès, peuvent envoyer des alarmes (ou des traps SNMP) lorsque certains événements se produisent, tels qu'un crash d'interface, un CPU ou une charge réseau trop élevée, un changement d'état de l'UPS ou une partition disque devenue pleine. Chaque appareil possède sa propre “collection” d'événements possibles, qui se reflète dans une collection, appelée MIB, dans ce cas, différente de la MIB utilisée pour interroger l'appareil.

Les traps ne sont envoyés que lorsque quelque chose se produit, de manière asynchrone (et non répétitive dans le temps) par l'appareil à un récepteur SNMP traps. Pandora FMS dispose d'une console de réception des traps qui permet de visualiser les traps envoyés par les objets surveillés et d'ajouter des alertes à ces traps. Les traps SNMP sont reçus par le démon du système d'exploitation que le serveur SNMP Pandora FMS démarre lorsque le serveur Pandora FMS démarre. Ce démon stocke les traps dans un journal situé par défaut dans

/var/log/pandora/pandora_snmptrap.log

Les traps sont généralement reçus en format “brut”, c'est-à-dire avec des OID numériques, sauf si un MIB installé dans le système d'exploitation est capable de les résoudre. La console SNMP de Pandora FMS Enterprise permet de créer des règles pour renommer les OID numériques en OID alphanumériques ou en simples chaînes de caractères descriptif (ex. : L'interface a planté) afin de rendre plus intuitive l'utilisation de TRAPS. Pandora FMS permet également de charger les MIB Traps de n'importe quel fabricant pour définir automatiquement ces règles.

Afin de travailler avec des traps SNMP, modifiez tout d’abord le paramètre suivant dans /etc/pandora/pandora_server.conf pour activer la Console SNMP :

snmpconsole 1

Si vous voulez que les traps soient traduits (soit les liens variables, soit la chaîne Enterprise), vous devez activer les paramètres suivants (uniquement dans la version Enterprise) :

translate_variable_bindings 1
translate_enterprise_strings 1

Il faut aussi configurer l’archive /etc/snmp/snmptrapd.conf avec les paramètres nécessaires. Par exemple :

 authCommunity log public
 disableAuthorization yes

Avec cette configuration, les traps seront créés pour la communauté public et ne nécessiteront pas d’autorisation.

Les traps SNMPv3 sont rejetés à moins que l'utilisateur qui les envoie ne soit ajouté à /etc/snmp/snmptrapd.conf en utilisant la directive createUser. Par exemple :

disableAuthorization yes
createUser -e 0x0102030405 snmpv3user SHA mypassword AES

Pour accéder à la console de réception des traps, allez sur Surveillance → SNMP → SNMP → SNMP Console où la liste des trappes reçus apparaît. L'icône de la loupe peut être utilisée pour afficher toutes les informations du trap, de la même façon que pour les événements. Ici nous pouvons voir les informations détaillées d'un piège SNMP.

Pour chaque trap, les colonnes suivantes apparaissent :

Status

Carré vert si le trap est validé, rouge dans le cas contraire.

SNMP Agent

Agent qui a envoyé le trap.

OID

OID du trap envoyé. Un trap ne peut envoyer qu’une seule donnée dans ce champs.

Value

Champ de valeur du trap envoyé. Un trap ne peut envoyer qu'une seule donnée dans ce champ.

Custom OID, Custom Value

Champs personnalisés envoyés dans le trap. Il peut s'agir de données très complexes, qui ont une logique spécifique selon l'appareil qui envoie le trap. Un trap peut envoyer plusieurs données dans ce champ.

Time Stamp

Temps écoulé depuis la réception du trap.

Alerte

Carré jaune si une alerte a été lancée avec ce trap ou un carré gris si aucune alerte n’a été lancée.

Action

Champs pour effacer ou valider le trap.

Couleur

De plus, les traps ont une couleur (visible comme couleur de fond de la ligne du trap) différente selon le type de trap.

• Bleu : les traps de type entretien.
• Violet : les traps de type information.
• Vert : les traps de type Normal.
• Jaune : les traps de type Warning.
• Rouge : les traps de type Critique.

L'option Toggle Filter apparaît en haut de la console de trap. Si vous cliquez sur cette option, les champs pour filtrer les traps apparaissent ou disparaissent.

Afin de gérer efficacement les traps, il est possible de les valider pour que l'administrateur puisse distinguer les traps qu'il a déjà vus de ceux qu'il n'a pas vus.

Pour valider un trap, cliquez sur le cercle vert à gauche du trap.

Il est également possible de valider plusieurs traps en les marquant et en cliquant sur le bouton Validate.

Il est possible d'effacer les traps une fois traitées, soit individuellement, soit par sélection multiple en appuyant sur Delete.

Pour éviter que les pièges ne s'accumulent, il existe une option de configuration qui supprime automatiquement les pièges de plus de 10 jours par défaut.

Pandora FMS dispose également d'un système d'alerte pour les pièges SNMP qu'il reçoit. Elles sont principalement basées sur des règles de filtrage, recherchant les coïncidences dans tous les champs possibles selon les règles que nous configurons pour déclencher l'alerte.

Les alertes de trap SNMP ont plusieurs champs qui seront utilisés pour rechercher des correspondances dans le trap SNMP reçu dans la console. Vous pouvez éventuellement utiliser les champs que vous souhaitez pour créer des règles plus générales ou plus spécifiques en fonction des besoins :

Enterprise String

OID principal du trap. La présence de la chaîne sera recherchée, pouvant être un morceau de l'OID, de sorte que si nous voulons rechercher, par exemple : 1.21.34.2.3 dans un OID plus long, nous pouvons l'utiliser de la même manière dans le champ, et effectuer la recherche comme si elle était : *1.21.34.2.3.* Donc vous ne devez PAS utiliser d'astérisque. Pour les coïncidences exactes, finissez la chaîne avec le cractère $.

Custom Value/OID

Il recherche dans les champs Value du trap, ainsi que dans les champs Custom OID et Custom Value, c'est-à-dire dans le reste des champs TRAP. C'est là que la recherche d'expressions régulières fonctionne. Par exemple, si nous avons un trap qui envoie la chaîne Testing TRAP 225, je peux rechercher n'importe quel trap avec la sous-chaîne Testing TRAP avec l'expression régulière Testing.*TRAP.*.

SNMP Agent

IP de l'agent qui envoie le piège. De la même manière, nous pouvons utiliser une expression régulière ou une chaîne de caractères.

Trap type

Filtre selon le type de trap, pouvant être : Cold start, Warm start, Link down, Link up, Authentication failure o Other. La plupart des traps générés sont généralement du type Other ; si vous ne spécifiez rien, il recherchera n'importe quel type de piège.

Single value

Filtre par la valeur du trap. Dans l'exemple égal à .666, il s'agit uniquement de la valeur simple de l'OID primaire et non d'un OID secondaire

Variable bindings/Data #1-20

Ce sont des expressions régulières qui tentent de faire correspondre les variables 1 à 20, si un résultat est trouvé, l'alerte se déclenche. La valeur de la variable est stockée dans la macro _snmp_fx_ correspondante (_snmp_f1_, _snmp_f2_, ….). Bien qu'une seule expression régulière puisse être spécifiée pour vingt variables, les macros _snmp_fx_ sont disponibles pour toutes (_snmp_f11_, _snmp_f12_,…).

Field 1

Champ pour définir le paramètre de la commande d'alarme Field 1. C'est le champ qui sera utilisé dans le cas où se génère un événement, ou le mail de destination (Destination address) dans le cas d'une action eMail (si nous voulons écraser le mail qui a par défaut dans l'action). Pour comprendre en détails le fonctionnement des champs personnalisés dans les modèles d'actions/alertes, lisez attentivement le chapitre de la documentation qui explique les alertes dans Pandora FMS.

Field 2

Champ pour définir le paramètre de la commande d'alarme Field 2. En cas d'envoi d'un e-mail, par exemple, il fera l'objet du message (Subject). S'il est laissé vide, il utilisera ce qu'il a défini dans l'action.

Field 3

Champ pour définir le paramètre de la commande d'alarme Field 3. Dans le cas de l'envoi d'un courriel, il s'agirait du texte du message. Il a deux options pour l'email : Basic pour texte simple et Advanced pour HTML. S'il est laissé en blanc il utilisera celui qui est défini dans l'action.

Min. Number of Alerts

Champ dans lequel est défini le nombre minimum de traps qui doivent arriver pour déclencher l'alarme.

Max. Number of Alerts

Champ dans lequel est défini le nombre maximum de fois que l'action sera exécutée dans l'intervalle donné (ou time threshold).

Time Threshold

Champ pour définir le temps qui doit s'écouler avant la remise à zéro du compteur d'alarmes. Ce compteur est celui utilisé pour le champ Min. Number of alerts.

Priority

Combo où la priorité de l'alarme est définie.

Alert Action

Combo où l'action qui exécutera l'alerte est déterminée. Si un événement est choisi, l'événement normal de génération d'alerte ne sera pas généré.

Position

Les alertes ayant la position la plus basse sont évaluées en premier. S'il y a plusieurs alertes avec la même position qui coïncident avec le trap, toutes les alertes avec la même position seront lancées. Ceux qui ont la position la plus basse, même s'ils coïncident, ne seront pas lancés.

Les macros suivantes peuvent être utilisées dans n'importe quel champ “field”des alertes :

• _data_: Trap entier
• _agent_ : Nom de l’agent
• _address_ : Adresse IP
• _timestamp_ : Date trap
• _snmp_oid_ : OID du trap
• _snmp_value_ : Valeur de l’OID du trap

Supposons que nous recevions un trap comme le suivant :

Dans ce cas, nous avons un OID principal (.1.3.6.6.1.4.1.2789.2005) qui identifie un trap qui peut contenir des messages de surchauffe du CPU (nous ne savons pas s’il y a plus de choses) mais nous savons que dans deux variables, il laisse le CPU qui est chauffé et la température du CPU à ce moment, en variables 1 et deux respectivement. Comme nous ne voulons identifier que les traps de chauffage de l'UC, nous faisons coïncider la chaîne de “Heat alert” dans la première variable du piège (souvenez-vous que nous avons jusqu'à 20 pour faire des recherches).

Définir la première partie du piège est simple, nous n'utilisons que l'OID principal pour faire le premier et le plus important filtre précédent :

La deuxième partie de la définition du trap est celle qui contient la partie essentielle. Dans la première variable du trap, nous recherchions la chaîne Heat alert .

Et enfin,dans Field 1 utilisez les variables macro qui contiennent la valeur des variables 1 et 2 du trap SNMP reçue (_snmp_f1_ et _snmp_f2_) accompagné du text descriptif :

De cette façon, lorsque l’arlerte s’enclenchera, l’événement généré prendra cet aspect :

Il y a quelques paramètres sur le serveur qui sont utilisés pour protéger le système contre l'arrivée d'une avalanche de traps provenant de la même source. Pour ce faire, les paramètres de configuration suivants sont utilisés dans le fichier pandora_server.conf :

• snmp_storm_protection : Nombre maximal de traps traités dans l'intervalle de protection.
• snmp_storm_timeout : Intervalle en secondes de la protection contre les orages des traps. Pendant cet intervalle, seuls X traps provenant de la même source (même IP) peuvent être traités.
• snmp_storm_silence_period : S'il est supérieur à 0 chaque fois que la storm protection est déclenchée pour une source particulière, l'heure actuelle plus le temps de coupure sont ajoutés. Tant que ce délai n'est pas écoulé, aucun nouveau piège ne sera enregistré pour la source en question.

Lorsque cette protection est déclenchée, elle se traduit par un événement sur la console:

La protection contre les tempêtes de traps, combinée au filtrage des traps (voir ci-dessous), permet si nous recevons des centaines de milliers de traps par jour, de travailler avec seulement quelques milliers, afin d'éliminer ceux qui sont redondants ou ceux qui ne sont pas utiles.

Certains systèmes reçoivent un nombre élevé de traps, dont un faible pourcentage est utile pour la supervision. Avec Pandora FMS, il est possible de filtrer les traps que le serveur reçoit pour éviter de charger inutilement l'application.

Depuis Monitoring > SNMP > SNMP Filters vous pouvez définir plusieurs filtres :

Ajoutez une description et aussi de filtres dont vous en avez besion avec le bouton + :

Un déroutement qui coïncide avec n'importe quel d'entre eux sera automatiquement écarté par le serveur. Le filtre est appliqué comme une expression régulière sur l'entrée correspondant au piège dans le journal SNMP (par défaut /var/log/pandora/pandora/pandora_snmptrap.log), qui a le format fixe suivant :

%4y-%02.2m-%l[**]%02.2h:%02.2j:%02.2k[**]%a[**]%N[**]%w[**]%W[**]%q[**]%v\n

Soit :

• %y : année en cours
• %m : mois en cours (numérique)
• %l : jour du mois en cours.
• %h : heure actuelle.
• %j : Minute actuelle
• %k : seconde actuelle.
• %a : adresse d’origine (uniquements les traps version 1).
• %N : OID.
• %w : type de trap (numérique).
• %W : description du trap.
• %q : sous-genre du trap (numérique).
• %v : liste des variables séparées par tab (custom OID).

Par exemple, pour filtrer tous les pièges envoyés par l'hôte 192.168.50.20 nous pourrions définir le filtre suivant :

Comme il est possible de créer plus d'un filtre simultanément, la recherche prendra en compte les pièges qui répondent à toutes les conditions de filtrage.

Cette vue permet de voir les statistiques des traps, à la fois par origine (IP) et par OID, ce qui permet une gestion efficace dans les filtres, d'identifier les IP qui produisent le plus de traps et les OID qui se répètent le plus. Le système affiche les statistiques des traps des 30 derniers jours.

Afin de faciliter la compréhension des traps envoyés par les appareils surveillés, il est possible pour l'opérateur de télécharger les MIBs du fabricant sur Pandora FMS ou de modifier les traps de manière personnalisée.

Nous appelons “ éditer un trap ” le processus où il est possible de “ personnaliser ” l'apparence d'un trap dans la console. Pour éditer un trap, allez dans Monitoring > SNMP > SNMP trap editor.

Cliquez sur l'icône d'édition du trap que vous souhaitez personnaliser :

Une page semblable à celle-ci apparaîtra :

De cette façon, lorsque vous trouvez des pièges avec l'OID .1.3.6.1.4.1.4.1.2789.2005 vous les verrez comme “Blue box sample”. Et il sera plus facile de les différencier. Leur contenu (y compris l'OID original) ne variera pas.

Custom OID est une expression régulière compatible avec Perl qui sera comparée avec la partie de la chaîne de trappes qui contient les variables de liaison. Il n'est généralement pas nécessaire de traduire un piège.

Notez que tous les pièges précédents ne changeront pas d'apparence, ceci entrera en fonction avec les nouveaux pièges qui entreront dans le système à partir de maintenant.

Enfin, voici à quoi ressemblerait un piège redéfini par l'utilisateur :

Cette option est utilisée pour télécharger les MIBS des traps (exclusivement) et étendre la base de données de traduction interne de Pandora FMS, afin que lorsqu'un trap arrive, il soit automatiquement traduit par sa description. Allez vers Monitoring > SNMP > MIB.

Afin de télécharger les MIB du fabricant, cliquez sur Upload file(s), choisissez le fichier et cliquez sur Go.

Une fois téléchargé, le système l'incorpore à sa bibliothèque de traps.

Les alertes décrites ci-dessus concernent les cas où le trap est bien défini, qu’il est est toujours le même et ne contient aucune information pertinente à sauver.

En d'autres occasions, nous pouvons trouver un piège qui a la physionomie suivante :

OID: .1.3.6.1.4.1.2789.2005
Value: 666
Custom data: 1.3.6.1.4.1.2789.2005.1 = STRING: "ID-00342"
.1.3.6.1.4.1.2789.2005.2 = STRING: "Automated check" .1.3.6.1.4.1.2789.2005.3 = STRING: "NIC Offline"
.1.3.6.1.4.1.2789.2005.4 = STRING: "4897584AH/345"

Ce trap, outre un OID et une valeur, contient une information complexe, basée sur plusieurs OID et plusieurs valeurs. Un trap peut avoir, dans sa partie complexe, une structure complètement libre, basée sur des paires d'OID et des valeurs (compteurs, numériques, alphanumériques, dates…).

Ce trap serait affiché dans la console de trap comme suit :

Si nous examinons en détail les informations étendues (Variable bindings), il y a plusieurs éléments d'information utiles. Plus précisément, le premier champ, avec l'OID se terminant en 2005.1 ressemble à un identificateur, le troisième champ avec l'OID se terminant en 2005.3 ressemble à un message d'erreur. Les champs 2 et 4 ne semblent pas très utiles, puisque le 4ème par exemple, est un code que l'on ne connaît pas.

Supposons que nous puissions créer un événement à partir d'un trap, en plaçant des parties spécifiques du trap dans le texte, par exemple, supposons que nous voulons construire un événement qui contient les informations suivantes :

Chassis Alert: <message d’erreur> dans dispositif <identificateur>

Le défi consiste à créer une alerte qui recherche des correspondances dans ces rubriques, obtient l'information et l'utilise ensuite pour composer un message d'alerte.

Nous pouvons le faire avec Pandora FMS, en utilisant des expressions régulières avancées, en utilisant des sélecteurs. Vous pouvez trouver plus d'informations sur les expressions régulières dans ce lien.

Les sélecteurs, qui utilisent les caractères ( et ) permettent de “ copier ” de l'information, en utilisant une expression de recherche.

L'expression régulière pour obtenir l'identificateur serait la suivante :

.*.1.3.6.1.4.1.2789.2005.1 \= STRING\: \"([0-9\-\_A-Za-z]+)\"

L'expression régulière pour obtenir le message d’erreur serait la suivante :

.*.1.3.6.1.4.1.2789.2005.3 \= STRING\: \"([\sA-Za-z]+)\".*

Une fois que nous avons les champs d'information, nous devons les utiliser dans l'alerte. Pour cela, nous utilisons les macros spéciales _snmp_f1_, _snmp_f2_, _snmp_f2_, _snmp_fn_ qui n'ont de sens que dans les alertes traps SNMP.

Pour construire le message, nous utiliserions la chaîne suivante :

Chassis Alert: _snmp_f2_ en dispositivo _snmp_f1_

En bref, cela créerait l'alerte complète :

Pour effectuer ce type d'alertes, il est nécessaire d'avoir une bonne connaissance des Expressions Régulières, car un simple espace, un guillemet ou un caractère au mauvais endroit et l’action à exécuter ne fonctionne pas.

La façon la plus simple de définir une alerte, en utilisant des expressions régulières, serait la suivante :

Cet autre exemple utilise une alerte eMail pour envoyer des informations sur le nom de l'interface chaque fois qu'un trap spécifique est reçu, signalant des problèmes sur cette interface. De cette façon, l'information sur l'appareil et l'interface arrive à l'email, prenant cette information de l'intérieur du piège.

C'est le trap reçu du switch :

Voici comment le message de l'email doit être :

Voici comment le trap doit être défini :

Les alertes définies sur les traps sont totalement indépendantes du moteur d'alerte Pandora FMS, il n'est donc pas possible d'établir des corrélations du type “ une alarme se déclenche si la température monte jusqu'à 29 degrés et que le trap de l'alimentation secondaire se coupe ”. Ce type d'alertes ne peut pas non plus être représenté (puisqu'elles ne sont en principe associées à aucun module FMS Pandora), de sorte que la surveillance de la console trap ne peut pas être liée à des éléments tels que des rapports ou des cartes.

Module spécial SNMPTrap, contenant le trap renvoyé depuis la console SNMP :

Pour ce faire, il existe une méthode appelée Agent SNMP Trap Forwarding. Cette option (générale au serveur) transmet le trap à un module spécial de l'agent appelé SNMPTrap sous forme de chaîne de texte, si et seulement si, l'adresse IP source du trap est définie comme IP d'un agent. Dans ce cas, le trap arrive sous la forme d'une ligne de texte à l'agent à l'intérieur de ce module, qui est un module qui n'est défini que lorsque le premier trap arrive.

Les alertes textuelles peuvent être spécifiées sur ce module, étant complètement standard, comme celles de n'importe quel module. Cela permet de personnaliser la surveillance SNMP pour que certains traps, de certaines origines, puissent être traités comme un module supplémentaire, et ainsi l'intégrer dans le reste de la surveillance, y compris la corrélation des alertes.

Aspect que prend le module SNMPTrap :

Il s'agit d'une fonction Entreprise et elle est configurée dans la section Setup > Setup > Enterprise, avec l'option suivante :

Option de configuration pour permettre le renvoi des traps à l’agent

Si vous modifiez cette option, vous devez redémarrer le serveur Pandora FMS pour commencer à agir.

Une autre solution consiste à monter une alerte sur le trap qui active un module d'agent. Par exemple, le trap c’est d’écrire dans un fichier de logs, et vous avez un agent qui lit ce fichier et saute quand il y a un “1” d’écrit. De cette façon, le module sautera lorsque le trap désiré sera reçu et la corrélation pourra être établie en fonction du trap reçu.

La console SNMP est limitée à la réception de traps, car elle ne traite TRAP que comme une entité individuelle, mais un trap peut contenir beaucoup d'informations. Parfois, il arrive que la seule surveillance que nous puissions faire soit basée sur des traps. Pour ce faire, nous pouvons choisir de “post-traiter” les informations collectées dans un trap par un script externe, qui agit comme un plugin.

Pour traiter les données d'un trap en détail, vous pouvez envoyer toutes les informations d'un trap à un script, à la suite d'une alerte. Ce trap utilisé pour l'exemple, c'est la vue de ce dernier telle qu'elle serait vue dans le journal de la console SNMP de Pandora FMS :

2010-08-26 12:01:46 pandora 10.201.246.2 .1.3.6.1.4.1.1722 .1.3.6.1.4.1.1722.2.10.1.1.1 233 .1.3.6.1.4.1.1722.2.10.1.1.3 = STRING:
AIX_Software_Failure .1.3.6.1.4.1.1722.2.10.1.1.2 = STRING: 08 25 2010 08:23:43:697685 .1.3.6.1.4.1.1722.2.10.1.1.8 = STRING: 1: A
software error PERM with label CORE_DUMP, identifier C69F5C9B occurred at Wed Aug 2 5 10:22:28 DFT 2010 on dvs02 for resource
SYSPROC. Cause is SOFTWARE PROGRAM ABNORMALLY TERMINATED. .1.3.6.1.4.1.1722.2.10.1.1.6 = STRING: 8
.1.3.6.1.4.1.1722.2.10.1.1.11 = STRING: An application may not work properly .1.3.6.1.4.1.1722.2.10.1.1.10 = STRING: An application
may not work properly .1.3.6.1.4.1.1722.2.10.1.1.12 = INTEGER: 4 .1.3.6.1.6.3.1.1.4.3.0 = OID: .1.3.6.1.4.1.1722

Dans les captures d'écran, vous pouvez voir comment une alerte spéciale serait créée, qui exécute un script avec le contenu complet du trap (_data_) et comment l'alerte de type SNMP est créée. Dans ce cas, il a été cartographié pour l'OID spécifique (.1.3.6.1.1.4.1.1722.2.10.1.1.1.1.1) mais il aurait pu être plus générique, par exemple (.1.3.6.1.4.1.1722) pour appeler le script avant tout type de traps de cette typologie (.1.3.6.1.4.1.1722) je suppose que celles-ci feront partie du MIB spécifique d'AIX).

Un script est exécuté qui traite ces données et “analyse” le trap pour écrire les données directement dans Pandora FMS, en générant un XML et en le laissant dans /var/spool/pandora/data_in comme s'il venait d'un agent. Un script de base pour ce cas pourrait, par exemple, générer des informations complexes puisque nous avons suffisamment d'informations dans ce trap, à savoir :

• IP d’origine.
• Événement principal (Cold start)
• Événement secondaires (descriptifs) : AIX_Software_Failure, 1: A software error PERM with label CORE_DUMP, identifier C69F5C9B occurred at Wed Aug 2 5 10:22:28 DFT 2010 on dvs02 for resource SYSPROC. Cause is SOFTWARE PROGRAM ABNORMALLY TERMINATED, An application may not work properly, An application may not work properly.

Lors de la conception d'un script qui analyse chacune de ces données, par exemple “miscript.pl” il se sauvegarde dans /var/spool/pandora/data_in the XML avec un nom générique et un nombre aléatoire, par exemple snmp_gateway.31415.data.

Le XML généré devrait ressembler à ceci.

<?xml version='1.0' encoding='ISO-8859-1'?>
<agent_data description='' group='' os_name='aix' os_version='' interval='300' version='3.1(Build 100608)' timestamp='2010/08/26 12:20:26' agent_name='10.201.246.2'>
  <module>
    <name><![CDATA[Critical_Event]]></name>
    <description><![CDATA[]]></description>
    <type>async_proc</type>
    <data><![CDATA[1]]></data>
  </module>
<module>
    <name><![CDATA[events]]></name>
    <description><![CDATA[]]></description>
    <type>async_string</type>
    <datalist>
      <data><value><![CDATA[AIX_Software_Failure]]></value></data>
      <data><value><![CDATA[A software error PERM with label CORE_DUMP, identifier C69F5C9B occurred at Wed Aug 2 5 10:22:28 DFT 2010 on dvs02 for resource SYSPROC.]]></value></data>
      <data><value><![CDATA[Cause is SOFTWARE PROGRAM ABNORMALLY TERMINATED, An application may not work properly, An application may not work properly.]]></value></data>
    </datalist>
  </module>
</agent_data>

L'application de cette technologie est infinie, mais que si chaque script est particularisé puisqu'il peut avoir une structure très dynamique. Dans de nombreux systèmes, l'information qui est reçue n'est pas seulement du texte, mais aussi numérique, avec laquelle il peut alimenter des modules d'information numérique et donc représenter des graphiques etc. Cependant, nous devons tenir compte du fait que les données générées en XML doivent toujours être asynchrones.

L'une des choses les plus problématiques en matière de surveillance est l'infrastructure “distribuée”, d'autant plus si chaque version modifie son implémentation pour collecter des informations, comme par exemple VmWare ESX. Dans ce court chapitre, nous allons essayer d'expliquer comment surveiller les systèmes ESX en utilisant un gestionnaire de traps SNMP externe.

Les traps ESX sont comme cela :

.1.3.6.1.4.1.6876.4.3.301 = STRING: "host"  .1.3.6.1.4.1.6876.4.3.302 = STRING: "c7000-06-01.tsm.inet"      .1.3.6.1.4.1.6876.4.3.303 = ""
.1.3.6.1.4.1.6876.4.3.304 = STRING: "Green" .1.3.6.1.4.1.6876.4.3.305 = STRING: "Yellow"    .1.3.6.1.4.1.6876.4.3.306 = STRING: "Host
cpu usage - Metric Usage = 1%"

.1.3.6.1.4.1.6876.4.3.301 = STRING: "host"  .1.3.6.1.4.1.6876.4.3.302 = STRING: "dl360-00.tsm.inet" .1.3.6.1.4.1.6876.4.3.303 = ""
.1.3.6.1.4.1.6876.4.3.304 = STRING: "Yellow".1.3.6.1.4.1.6876.4.3.305 = STRING: "Green"     .1.3.6.1.4.1.6876.4.3.306 = STRING: "Host
memory usage - Metric Usage = 84%"

.1.3.6.1.4.1.6876.4.3.301 = STRING: "host"  .1.3.6.1.4.1.6876.4.3.302 = ""  .1.3.6.1.4.1.6876.4.3.303 = ""  .1.3.6.1.4.1.6876.4.3.304 =
STRING: "Red"       .1.3.6.1.4.1.6876.4.3.305 = STRING: "Green" .1.3.6.1.4.1.6876.4.3.306 = STRING: "Datastore usage on disk - Metric
Storage space actually used = 55%"

Comme vous pouvez le voir, les traps sont utilisés pour collecter des informations depuis le CPU, le disque ou la mémoire. L'idée générale derrière le gestionnaire de trap est d'écrire un petit script capable de “comprendre” le trap et de créer un XML simulant un agent logiciel. Ainsi, pour chaque technologie, vous devriez écrire un gestionnaire de traps, mais tout le processus est commun. Le processus pour comprendre cela est expliqué en quatre étapes :

1. Créez le script du gestionnaire. Vous pouvez baser votre travail sur le script fourni ci-dessous.
2. Créez une commande d'alerte
3. Créer une action d'alerte à l'aide des commandes précédentes. Parfois, avec des options personnalisées pour chaque agent “destinataire” que vous voulez (si vous avez plusieurs groupes ESX, vous aimerez sûrement avoir des données dans différents agents).
4. Créez une alerte SNMP Trap qui mappe l'OID Enterprise (informations sur les traps pour tous les types de cette technologie spécifique et/ou l'adresse IP de la trap source).

#!/usr/bin/perl
# (c) Sancho Lerena 2010 <[email protected]>
# Specific Pandora FMS trap collector for ESX

use POSIX qw(setsid strftime);

sub show_help {
    print "\nSpecific Pandora FMS trap collector for ESX\n";
    print "(c) Sancho Lerena 2010 <[email protected]>\n";
    print "Usage:\n\n";
    print "   esx_trap_manager.pl <destination_agent_name> <TRAP DATA>\n\n";
    exit;
}

sub writexml {
    my ($hostname, $xmlmessage ) = @_;
    my $file = "/var/spool/pandora/data_in/$hostname.".rand(1000).".data";

    open (FILE, ">> $file") or die "[FATAL] Cannot write to XML '$file'";
    print FILE $xmlmessage;
    close (FILE);
}

if ($#ARGV == -1){
    show_help();
}

$chunk = "";

# First parameter is always destination host for virtual server
$target_host = $ARGV[0];

foreach $argnum (1 .. $#ARGV) {
    if ($chunk ne ""){
        $chunk .= " ";
    }
    $chunk .= $ARGV[$argnum];
}

my $hostname = "";
my $now = strftime ("%Y-%m-%d %H:%M:%S", localtime());
my $xmldata = "<agent_data agent_name='$target_host' timestamp='$now' version='1.0' os='Other' os_version='ESX_Collectordime ' interval='9999999999'>";

if ($chunk =~ m/.1.3.6.1.4.1.6876.4.3.302 \= STRING\: ([A-Za-z0-9\-\.]*)\s\.1/){
    $hostname = "_".$1;
}

if ($chunk =~ m/Host cpu usage \- Metric Usage \= ([0-9]*)\z/){
    $value = $1;
    $module_name = "CPU_OCUPADA$hostname";
}

if ($chunk =~ m/Host memory usage \- Metric Usage = ([0-9\.]*)\z/){
    $value = $1;
    $module_name = "MEMORIA_OCUPADA$hostname";
}

if ($chunk =~ m/Datastore usage on disk \- Metric Storage space actually used \= ([0-9\.]*)\z/){
    $value = $1;
    $module_name = "DISCO_OCUPADO$hostname";
}

$xmldata .= "<module><name>$module_name</name><type>async_data</type><data>$value</data></module>\n";

$xmldata .= "</agent_data>\n";
writexml ($target_host, $xmldata);

Dans cet exemple, j'ai mis le script de commande dans /tmp, je l'ai mis dans un endroit plus sûr, et je m'assure qu'il peut être exécuté (chmod 755) :

Créez une action spécifique pour envoyer toutes les informations à des traps d'agents spécifiques. Dans ce cas, l'information sera envoyée à un agent appelé WINN1247VSR. La commande ci-dessus accepte comme paramètres le nom de l'agent qui portera toutes les informations (ESX Virtual Center), et les “bits” de données TRAP, qui peuvent être illimités et comprennent toutes les informations que vous envoyez au trap.

Configurez les traps d'alerte à l'aide de l'action que vous venez de créer. Pour traiter tous les traps de la technologie ESX, qu’il trouvera, à l'aide de l'OID spécifique .1.3.6.1.4.4.1.6876.4.3.301, pour mapper les traps ESX.

Vous pouvez également filtrer par source IP pour chaque Centre Virtuel, en filtrant par adresse IP source (envoyée dans le trap).

Ceci est un exemple de ce à quoi ressemblera l'information. Avec ces données, vous pourrez les gérer comme des modules standard.

Avec Pandora FMS, il est possible d'activer le transfert des traps SNMP vers un hôte externe en activant le jeton snmp_forward_trap dans le fichier de configuration Pandora.

 snmp_forward_trap 1
 snmp_forward_ip 192.168.1.145
 snmp_forward_version 1
 snmp_forward_secName
 snmp_forward_engineid
 snmp_forward_authProtocol
 snmp_forward_authPassword
 snmp_forward_privProtocol
 snmp_forward_privPassword
 snmp_forward_secLevel

 snmp_forward_trap 1
 snmp_forward_ip 192.168.1.145
 snmp_forward_version 2c
 snmp_forward_secName
 snmp_forward_engineid
 snmp_forward_authProtocol
 snmp_forward_authPassword
 snmp_forward_privProtocol
 snmp_forward_privPassword
 snmp_forward_secLevel

Cet exemple est particulièrement compliqué en raison des connaissances requises dans SNMP v3. Supposons que l'agent SNMP distant défini danssnmp_forward_ip possède l'entrée suivante dans son fichier de configuration /etc/snmp/snmp/snmptrapd.conf :

createUser -e 0x0102030405 myuser MD5 mypassword DES myotherpassword

La configuration dans le fichier de configuration de Pandora FMS serait alors :

 snmp_forward_trap 1
 snmp_forward_ip 192.168.1.145
 snmp_forward_version 3
 snmp_forward_secName myuser
 snmp_forward_engineid 0x0102030405
 snmp_forward_authProtocol MD5
 snmp_forward_authPassword mypassword
 snmp_forward_privProtocol DES
 snmp_forward_privPassword myotherpassword
 snmp_forward_secLevel authNoPriv

Plus d’informations sur NET-SNMP v3 Traps

Il est possible que pour une raison quelconque vous préfériez gérer le démon snmptrapd indépendamment de Pandora FMS (pour l'arrêter ou l'élever indépendamment du Démon principal de Pandora FMS). Pour ce faire, vous devez tenir compte de plusieurs facteurs.

1.Vous devez également activer le paramètre snmpconsole dans le serveur Pandora FMS.

2. Les logs configurés dans le serveur Pandora FMS doivent être les mêmes que ceux générés dans l'appel indépendant à snmptrapd.

3. L'appel à snmptrapd doit avoir un format spécifique l'appel au démon système standard n'est pas valide. L'appel doit être ainsi (le paramètre -A est particulièrement important !):

/usr/sbin/snmptrapd -A -t -On -n -a -Lf /var/log/pandora/pandora_snmptrap.log -p /var/run/pandora_snmptrapd.pid --format1=SNMPv1[**]%4y-%02.2m-%l[**]%02.2h:%02.2j:%02.2k[**]%a[**]%N[**]%w[**]%W[**]%q[**]%v\n --format2=SNMPv2[**]%4y-%02.2m-%l[**]%02.2h:%02.2j:%02.2k[**]%b[**]%v\n

4. Vous devez configurer le jeton dans le fichier de configuration du serveur :

snmp_trapd manuel

5. Lorsque vous définissez cette fonction. Vous devez effectuer l'opération suivante :

• Changez la configuration dans /etc/pandora/pandora/pandora_server.conf
• Arrêter le serveur FMS de Pandora.
• Vérifiez que le processus snmptrapd n'est plus exécuté (et si c'est le cas, attendez qu'il meure ou le tue).
• Lancez snmptrapd manuellement (dans le format indiqué ci-dessus).
• Démarrez le serveur Pandora FMS.

Le processus snmptrapd peut être arrêté et démarré sans avoir à arrêter et démarrer le processus du serveur Pandora FMS, tant que les fichiers pandora_snmptrap.log.index et pandora_snmptrap.log ne sont pas modifiés. Si ces fichiers sont modifiés, il est nécessaire de redémarrer le serveur Pandora FMS. Si vous avez besoin de faire pivoter le journal des traps en externe, vous devez redémarrer le serveur Pandora FMS après avoir supprimé les fichiers mentionnés précédemment.

Si des traps SNMP sont envoyés à un gestionnaire externe via une connexion non fiable, une partie de l'information sera perdue. Pandora FMS vous permet, à la place, de transférer les traps d'un snmptrapd local vers votre serveur Pandora FMS d'une manière fiable.

• Un agent SNMP envoie des traps à un snmptrapd local.
• Un agent local de Pandora FMS lit les traps dans le fichier journal snmptrapd et les envoie au serveur Pandora FMS désigné dans un fichier de données XML, les sauvegarde dans le tampon XML et les réintroduit ultérieurement si nécessaire.
• Le serveur de données lit les traps des fichiers de données XML et les décharge dans un fichier texte clair.
• La console SNMP traite les traps à partir du fichier texte brut.

• Un snmptrapd local qui a des traps.
• Un agent local de Pandora FMS.
• Une installation Pandora FMS.

Editez le fichier /etc/snmp/snmptrapd.conf et assurez-vous que vous vous connectez à un fichier dans un format compatible avec Pandora FMS (vous pouvez modifier le nom du fichier journal si nécessaire) :

[snmp] logOption f /var/log/snmptrapd.log
format1 SNMPv1[**]%4y-%02.2m-%l[**]%02.2h:%02.2j:%02.2k[**]%a[**]%N[**]%w[**]%W[**]%q[**]%v\n
format2 SNMPv2[**]%4y-%02.2m-%l[**]%02.2h:%02.2j:%02.2k[**]%b[**]%v\n

Le plug-in grep_snmptrapd sera utilisé, qui vient avec l'agent Pandora FMS pour lire les données du fichier journal de snmptrapd.

Editez le fichier de configuration de l'agent local, /etc/pandora/pandora/pandora_agent.conf, et ajoutez la ligne suivante, en ajustant le chemin du fichier log de snmptrad si nécessaire :

module_plugin grep_snmptrapd /var/log/snmptrapd.log

Nous devons dire à la console SNMP de traiter les trappes à partir d'un fichier journal externe écrit par le serveur de données.

Editez le fichier de configuration de serveur, /etc/pandora/pandora/pandora_server.conf, et :

• Assurez-vous que la console SNMP est activée :

snmpconsole 1

• Assurez-vous que le serveur de données est activé :

serveur de données 1

• Configurez un fichier journal SNMP externe. S'il n'existe pas, la console SNMP le créera :

snmp_extlog /var/log/pandora/pandora_snmptrap.ext.log

Avec cet outil, vous pouvez générer des traps personnalisés que nous pourrons voir plus tard dans la console SNMP.

Afin de pouvoir configurer correctement le générateur de traps, nous devrons remplir les champs suivants :

Host Address

C'est l'IP de destination vers laquelle nous allons envoyer le trap.

Community

Où vous allez définir le mot de passe de la communauté SNMP à laquelle nous essayons d'accéder avec le générateur de trap.

Enterprise String

L'OID (Object Identifier) du piège doit ici être configuré. Par exemple : 1.3.6.1.1.2.2.1.2.2.2.1.8

Value

La valeur que vous voulez donner au piège et qui, ensuite, apparaîtra comme Data.

SNMP Agent

Vous devez introduire l'agent où vous allez simuler le trap, en mettant obligatoirement l'IP de ce dernier.

SNMP Type

Choisissez un type SNMP parmi les options suivantes :

• Cold Start : Il indique que l'agent a été lancé ou redémarré.
• Warm Start: Il indique que la configuration de l’agent a été modifiée.
• Link down: Il indique que l'interface de communication est hors service (inactive).
• Link up : Il indique qu’une interface de communication a été activée.
• Authentication failure : Il indique que l'agent a reçu une demande d'un SGEN non autorisé (contrôlé par la collectivité).
• EGP neighbor loss: Il indique que sur les systèmes où les routeurs qui utilisent le protocole EGP, un hôte proche est hors service.
• Enterprise : Dans cette catégorie vous trouverez tous les nouveaux traps. Y compris les traps des fournisseurs.

Retour à l'index de documentation du Pandora FMS