Pandora: Documentation fr: Supervision avec deroutements SNMP

From Pandora FMS Wiki
Jump to: navigation, search

Revenir à l’index de Documentation Pandora FMS


Contents

1 Opération avec des traps SNMP

1.1 Introduction

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.

Trap-example.png

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é publique et ne nécessiteront pas d’autorisation.

1.1.1 SNMPv3

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

Template warning.png

Il faut préciser l’engineID avec l’option -e. Sinon, seuls INFORMs SNMPv3 seront reçus.

 


1.2 Accès á la console de reception des déroutements

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.


Traps.JPG


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.


Alert.png


1.2.1 Valider les traps

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 "valider". La procédure est similaire au fonctionnement des événements dans Pandora FMS.



Traps2.JPG


1.2.2 Effacer des traps

Il est possible d'effacer les traps une fois traitées, soit individuellement, soit par sélection multiple en appuyant sur "Effacer". 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.


Traps3.JPG


1.3 Alertes des Traps SNMP

1.3.1 Introduction

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.


1.3.2 Ajouter une 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 :


AlertSNMP1.png


  • Description: combo pour écrire une description de l'alerte.
  • 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.


  • Custom Value/OID: Recherche dans les champs "Valeur" du trap, ainsi que dans les champs "OID personnalisé" et "Valeur personnalisée", 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 "Autre" ; 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: *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_,...).


AlertSNMP2.png


  • Field 1 : Champ pour définir le paramètre de la commande d'alarme Champ 1. C'est le champ qui sera utilisé dans le cas où se génère un événement, ou le mail de destination 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 Champ 2. En cas d'envoi d'un e-mail, par exemple, il fera l'objet du message. 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 Champ 3. Dans le cas de l'envoi d'un courriel, il s'agirait du texte du message. S'il est laissé vide, il utilisera ce qu'il a 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 seuil de temps).
  • 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 Nombre minimum d'alertes.
  • Priority : Combo où la priorité de l'alarme est définie. Les priorités des alertes sont différentes et n'ont rien à voir avec la priorité des pièges, ni avec celle des événements de Pandora FMS.
  • 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.

1.3.3 Macros de fields sur les alertes

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


1.3.4 Exemple d’alerte des traps

Supposons que nous recevions un trap comme le suivant :

Trap sample for alert.jpg

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 :

Trap alert definition 1.jpg

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" si les traps arrivaient avec l'OID principal mais la première variable ne contenait pas cette chaîne de texte. Alors, l’alerte ne se déclenchait pas.

Trap alert definition 2.jpg

Et enfin, lors du choix d'une alerte de type "pandora event", nous conformons le message en utilisant les variables qui contiennent la valeur des variables 1 et 2 du trap reçu :

Trap alert definition 3.jpg

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

Event result of alert.jpg

1.4 Travailler dans des environnements avec beaucoup de traps

1.4.1 Protection face à une avalanche de traps

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.

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.

1.4.2 Filtrage de traps dans le serveur

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

Dans Administration>Gérer la console SNMP>Filtres SNMP>Filtres SNMP, vous pouvez définir différents filtres. Un trap qui correspond à l'un d'entre eux sera automatiquement rejeté par le serveur :

Snmp filter editor new.png

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 :

Snmp filter example.png

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.

1.4.3 Statistiques de traps SNMP

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.


Captura de pantalla 2014-09-23 a la(s) 17.59.56.png



Captura de pantalla 2014-09-23 a la(s) 19.11.40.png


1.5 Personnaliser Traps SNMP

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.

Info.png

Les caractéristiques suivantes ne sont que pour la version Enterprise.

 


1.5.1 Renommage et personnalisation des traps

Nous appelons "éditer un trap" le processus où il est possible de "personnaliser" l'apparence d'un trap dans la console. Si vous regardez la capture d'écran suivante, tous ses traps peuvent être difficiles à distinguer en raison des informations cryptiques qu'ils contiennent.

Pour éditer un trap, allez dans Operation > SNMP Console. Cliquez sur l'icône d'édition du trap que vous souhaitez personnaliser :


Traps5.JPG


Une page semblable à celle-ci apparaîtra :


Traps7.JPG


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 "échantillon de la boîte bleue". 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.

Template warning.png

"Custom OID" n'est pas destiné à contenir toute la chaîne de variables bindings, qui peut être plus longue que la longueur maximale qu'elle supporte, mais une expression régulière qui correspond à une ou plusieurs variables.

 


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 :


Traps8.JPG


1.5.2 Télécharger les MIBs du fabricant

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.

Pour télécharger les MIBs du fabricant, cliquez sur "Browse", choisissez le fichier qui doit porter l'extension txt et cliquez sur "Upload MIB".



Cima6.png



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

1.6 Alertes avec des traps SNMP complexes

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 :


Traps9.JPG


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 ici :[1].

Les sélecteurs, qui utilisent les caractères () permettent de "copier" 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_f3_ (etc) 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 :



Compex trap def1.png



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.Rappelez-vous toujours que les alertes SNMP impliquent l'utilisation d'expressions régulières. La façon la plus simple de définir une alerte, en utilisant des expressions régulières, serait la suivante :



Compex trap def4.png



1.6.1 Autres exemples

Cet autre exemple utilise une alerte e-mail 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 :



Another trap alert sample.png



Voici comment je souhaite que le mail soit :



Trap email.png



Voici comment je définis le trap :



Another snmp trap sample.png





Another snmp trap sample2.png



1.7 Associer un trap au reste des alertes Pandora FMS / SNMP Agent trap forwarding

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 :

Snmptrap agent.png


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":



Snmptrapforward2.png


Il s'agit d'une fonction " Entreprise " et elle est configurée dans la section principale de configuration de Pandora FMS, avec une option comme celle de l'image :



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


Snmptrap agent forwardsetup.png


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.

1.8 Gestionnaire TRAPS externe

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

SNMP2.JPG



SNMP3.JPG


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.

1.8.1 Exemple pratique : surveillance ESX en utilisants des traps

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).

Voyons la première étape : créer le script du manipulateur de traps :


1.8.1.1 Étape 1 : Trap handler: esx_trap_manager.pl

#!/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);


1.8.1.2 Étape 2 : créer la commande d´alerte

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) :



SNMP3.JPG


1.8.1.3 Étape 3 : créer l’action de l’alerte

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.



SNMP4.JPG


1.8.1.4 Etape 4 : créer l’alerte SNMP

Configurez les traps d'alerte à l'aide de l'action que vous venez de créer.



SNMP5.JPG


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. Nous pouvons également filtrer par source IP pour chaque Centre Virtuel, en filtrant par adresse IP source (envoyée dans le trap).

1.8.1.5 Visualisation des données

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



SNMP6.JPG



SNMP7.JPG


1.9 SNMP trap forwarding ( > v5.0 )

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.


1.9.1 Exemple de configuration pour le renvoi de traps en utilisant SNMP v1

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

1.9.2 Exemple de configuration pour le renvoi de traps en utilisant SNMP v2c

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

1.9.3 Exemple de configuration pour le renvoi de traps en utilisant SNMP v3

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

1.10 Gestion indépendante du démon snmptrapd

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.

1.10.1 Gestion du fichier log des traps

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.

1.11 Buffering des traps SNMP

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.

1.11.1 Architecture

Remote snmp trap schema.jpg

  • Un agent SNMP envoie des traps à un snmptrapd local.
  • Un agent local de Pandora FMS lit les traps dans le fichier journal snmptrapd's 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.

Template warning.png

Il est plus efficace pour la console SNMP de traiter les traps directement à partir du fichier journal snmptrapd's. Cette configuration n'est recommandée que si la fiabilité ou la connectivité directe est un problème.

 


1.11.2 Pré requis

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

1.11.3 Configuration

1.11.3.1 snmptrapd

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

1.11.3.2 Agente de Pandora FMS

Nous utiliserons le plug-in grep_snmptrapd 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

1.11.3.3 Serveur de Pandora FMS

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

Template warning.png

snmp_extlog peut être n'importe quel fichier dans lequel le serveur Pandora FMS peut écrire, mais il doit être différent de snmp_logfile' (également défini dans /etc/pandora/pandora/pandora_agent.conf).

 


1.12 Générateur de Traps

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

Generador de traps.png


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ù nous allons 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 nous voulons donner au piège et qui, ensuite, apparaîtra comme Data.
  • SNMP Agent: Nous devons introduire l'agent où nous allons simuler le trap, en mettant obligatoirement l'IP de ce dernier.
  • SNMP Type : Nous devrons choisir un type SNMP parmi les options suivantes :
    • Cold Start : Indique que l'agent a été lancé ou redémarré.
    • Warm Start: Indique que la configuration de l’agent a été modifiée.
    • Link down: Indique que l'interface de communication est hors service (inactive).
    • Link up : Indique qu’une interface de communication a été activée.
    • Authentication failure : Indique que l'agent a reçu une demande d'un SGEN non autorisé (contrôlé par la collectivité).
    • EGP neighbor loss: 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.


Revenir à l’Index de Documentation Pandora FMS