Pandora: Documentation es: Monitorizacion traps SNMP

From Pandora FMS Wiki
Revision as of 16:00, 18 June 2012 by Slerena (talk | contribs) (Paso 4: Crear la alerta SNMP)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Volver a Indice de Documentacion Pandora FMS

1 Operación con traps SNMP

1.1 Introducción

Pandora FMS tiene una consola de recepción de traps que permite visualizar los traps que envían los objetos monitorizados y añadir alertas a dichos traps. Los traps SNMP se reciben a través del demonio del sistema operativo que el servidor SNMP de Pandora FMS arranca cuando el servidor de Pandora se inicia. Este servidor, generalmente almacena los traps en un log en /var/log/pandora/pandora_snmpconsole.log.

Los traps se reciben generalmente en formato "crudo", es decir, con OID's numéricos, a no ser que una MIB instalada en el Sistema Operativo sea capaz de resolverlos. La consola SNMP de Pandora FMS Enterprise, permite crear reglas para renombrar OID's numéricas a OID's alfanuméricas o simples cadenas de texto descriptivas (p.e: Se ha caído la interfaz) de forma que sea más intuitivo trabajar con TRAPS. Pandora FMS también permite cargar MIB's de Traps de cualquier fabricante para definir automáticamente esas reglas.

1.2 Acceso a la consola de recepción de traps

Para acceder a la consola de recepción de traps se va a Operación > Consola SNMP donde aparece la lista de traps que se han recibido. Existe un icono (el ojo) que permite desplegar toda la información del trap, igual que ocurre con los eventos. Aqui podemos ver la información detallada de un trap SNMP.

Snmp trap sample.png


Para cada trap aparecen las siguientes columnas:

Status

Cuadrado verde si el trap se ha validado y rojo si no se ha validado.

SNMP Agent

Agente que ha enviado el trap.

OID

OID del trap enviado. Un trap solo puede enviar un dato en este campo.

Value

Campo value del trap enviado. Un trap solo puede enviar un dato en este campo.

Custom OID, Custom Value

Campos personalizados enviados en el trap. Pueden ser datos muy complejos, que tengan una lógica específica en función del dispositivo que envía el trap. Un trap puede enviar varios datos en este campo.

Time Stamp

Tiempo que ha pasado desde que se ha recibido el trap.

Alerta

Cuadrado amarillo si se ha lanzado alguna alerta con este trap o cuadrado gris, si no se ha lanzado ninguna alerta.

Acción

Campo para borrar o validar el trap.

Además los traps tiene un color (visto como color de fondo de la línea del trap) diferente según el tipo de trap.

  • Azul: los traps de tipo mantenimiento.
  • Morado: los traps de tipo información.
  • Verde: los traps de tipo Normal.
  • Amarillo: los traps de tipo Warning.
  • Rojo: los traps de tipo Crítico.

1.2.1 Filtrar traps

En la parte superior de la consola de traps aparece la opción “Toogle Filter”. Pulsando sobre dicha opción aparecen o desaparecen los campos para filtrar traps.

Alert.png


Es posible filtrar en la consola de traps por los siguientes campos:

  • Agent: combo donde aparecen los agentes de Pandora.
  • OID: combo donde aparecen las OIDs recibidas.
  • Alert: combo donde se elige por alertas lanzadas o no lanzadas.
  • Search value: combo donde se puede buscar por valor del Trap.
  • Severity: combo donde aparecen los diferentes tipos de trap: Maintenance, Information, Severity, Warning, Normal y Critical.
  • Status: Selecciona entre alertas SNMP validadas, no validadas o todas.
  • Free search: busca por cualquier campo alfanumérico del trap.
  • Type: filtra las alertas SNMP por tipo. Pudiendo ser: Cold start, Warm start, Link down, Link up, Authentication failure o Other.

Además de estos campos de búsqueda, está la opción “Block size of pagination”, que permite definir el número de traps que habrá en cada página.

1.2.2 Validar traps

Con el fin de realizar una gestión efectiva de los traps, es posible validar los mismos para que el administrador pueda discriminar entre los traps que ha visto ya y los que no ha visto.

Para validar un trap se pulsa sobre el círculo verde que hay a la izquierda del trap.

Trap1.png


También es posible validar múltiples traps marcándolos y pinchando en el botón de “validate”.

Trap2.png


1.2.3 Borrar traps

Es posible borrar traps una vez que los mismos se han tratado.

Para borrar un trap se pulsa sobre la cruz roja que hay a la izquierda del trap.

Borrar1.png


1.3 Alertas de Traps SNMP

Es posible asociar una alerta a un trap para que Pandora FMS nos avise si llega un trap especifico. Para gestionar las alertas asociadas a traps se va va a Administration>Manage SNMP Console. Los traps de SNMP no tienen nada que ver con el resto de alertas del sistema, aunque reutilizarán el sistema de acciones.

1.3.1 Añadir una alerta

Para añadir una alerta asociada a un traps se va va a Administration>Manage SNMP Console y se pincha en “Create”.

Las alertas de traps SNMP tienen varios campos que pueden ser utilizados para "buscar" datos en el trap SNMP. Los campos que se pueden usar, tanto por separado como por combinación son:

  • Description: Combo para escribir una descripción de la alerta.
  • OID: OID principal del Trap. Es una expresión regular. Si no se usa una expresion regular se buscará la cadena exacta, si se quiere buscar un trozo del OID, se debe usar una expresion regular, de forma que si queremos buscar, por ejemplo: 1.21.34.2.3 en un OID más largo, podemos usar la expresión regular .*1.21.34.2.3.*
  • Custom Value/OID: Esto busca en los campos "Value" del trap, así como en los campos "Custom OID" y "Custom Value", es decir, en el resto de campos del TRAP. Aqui funciona, igualmente, la búsqueda por expresión regular. Por ejemplo si tengo un trap que envia la cadena "Testing TRAP 225" yo puedo buscar cualquier trap con la subcadena "Testing TRAP" con la expresion regular "Testing.*TRAP.*"
  • SNMP Agent: IP del agente que envía el trap. De igual forma, podemos usar una expresión regular o una subcadena.
  • Trap type: Filtra por tipo de trap pudiendo ser: Cold start, Warm start, Link down, Link up, Authentication failure o Other.
  • Single value: Filtra por el valor del trap. En el ejemplo igual a .666
  • Custom OID/Data #1: Es una expresión regular. Se deben usar selectores para seleccionar la parte de la expresión regular que se cargará en la macro _snmp_f1_ que luego se podrá utilizar en los campos Field #1 (Alias, name), Field #2 (Single Line) y Field #3 (Full Text).
  • Custom OID/Data #2: Es una expresión regular. Se deben usar selectores para seleccionar la parte de la expresión regular que se cargará en la macro _snmp_f2_ que luego se podrá utilizar en los campos Field #1 (Alias, name), Field #2 (Single Line) y Field #3 (Full Text).
  • Custom OID/Data #3: Es una expresión regular. Se deben usar selectores para seleccionar la parte de la expresión regular que se cargará en la macro _snmp_f3_ que luego se podrá utilizar en los campos Field #1 (Alias, name), Field #2 (Single Line) y Field #3 (Full Text).
  • Custom OID/Data #4: Es una expresión regular. Se deben usar selectores para seleccionar la parte de la expresión regular que se cargará en la macro _snmp_f4_ que luego se podrá utilizar en los campos Field #1 (Alias, name), Field #2 (Single Line) y Field #3 (Full Text).
  • Custom OID/Data #5: Es una expresión regular. Se deben usar selectores para seleccionar la parte de la expresión regular que se cargará en la macro _snmp_f5_ que luego se podrá utilizar en los campos Field #1 (Alias, name), Field #2 (Single Line) y Field #3 (Full Text).
  • Custom OID/Data #6: Es una expresión regular. Se deben usar selectores para seleccionar la parte de la expresión regular que se cargará en la macro _snmp_f6_ que luego se podrá utilizar en los campos Field #1 (Alias, name), Field #2 (Single Line) y Field #3 (Full Text).
  • Field 1: Campo para poner el parámetro del comando de la alarma Field 1. Este es el campo que se utilizará en el caso de elegir generar un evento.
  • Field 2: Campo para poner el parámetro del comando de la alarma Field 2. En el caso de enviar un email, p.e. será el subject del mensaje.
  • Field 3: Campo para poner el parámetro del comando de la alarma Field 3. El el caso de enviar un email, sería el texto del mensaje.
  • Min. Number of Alerts: Campo donde se define el mínimo número de traps que tienen que llegar para que salte la alarma.
  • Max. Number of Alerts: Campo donde se define el número máximo de veces que se ejecutará la acción.
  • Time Threshold: Campo donde se define el tiempo que debe pasar antes de resetear el contador de alarmas. Este contador es el que se usa para el campo Min. Number of alerts.
  • Priority: Combo donde se establece la prioridad de la alarma.
  • Alert Action: Combo donde se elije la acción que va a ejecutar la alerta. Si se elije un evento, el evento normal de generación de alerta no se generará.


Snmp trap alert.png


En este caso concreto, al definir la alerta usando un evento, y usando el campo uno para generar la información, resultaría un evento como el siguiente:



Snmp trap alert event.png


Una vez se han rellenado los campos se pincha en “Create”

1.3.2 Editar una alerta

Para editar una alerta asociada a un traps se va va a Administration>Manage SNMP Console, se elige la alerta que se quiere editar y se pincha en el icono de la herramienta.



Aparecerá una pantalla con la configuración de la alerta que se hizo al crearla. Se cambian los datos que se quiere cambiar y se pulsa en Update.

1.3.3 Borrar una alerta

Para borra una alerta asociada a un traps se va va a Administration>Manage SNMP Console, se elige la alerta que se quiere borra y se pincha en la x roja.


1.4 Personalizar Traps SNMP

Con el fin de facilitar la comprensión de los traps, que envían los dispositivos monitorizados, por parte del operador es posible subir las MIBs del fabricante a Pandora FMS o bien editar los traps de forma personalizada.

Info.png

Las siguientes, son características de la version Enterprise únicamente

 


1.4.1 Renombrar / Personalizar traps

Llamamos "editar un trap" al proceso donde se permite "personalizar" el aspecto que tiene un trap en la consola. Si se fija en la captura siguiente, puede que todos sus traps sean difíciles de distinguir debido a la información críptica que contienen. ¿Podríamos renombrarlos para que pusiera "Caja azul" en vez de un churro indescifrable?.

Para editar un trap, vaya a Operacion > Consola SNMP. Haga click en el campo OID del trap que se quiere editar.



Cima2.png



Aparecerá una página similar a la siguiente:



Cima3.png


De esta forma, al encontrar traps con el OID ".1.3.6.1.4.1.2789.2005" los visualizará como "Blue box sample". Y será mas fácil para el ojo normal, diferenciarlos. Su contenido (incluida la OID original) no variará.

Tenga en cuenta que todos los traps anteriores no cambiarán su aspecto, esto entrará en funcionamiento con los nuevos traps que entren en el sistema a partir de este momento.

Desde el mismo sitio puede crear nuevos traps desde 0, con la opcion "crear trap". Para ello sólo hay que ir al editor de traps, como se puede ver en esta captura. En esa sección podemos alterar la definición de un trap, o borrarla.



Snmp trap editor.png


Finalmente, así es como se vería un trap redefinido por el usuario:



Snmp custom view.png


1.4.2 Subir las MIBs del fabricante

Esta opción sirve para subir MIBS de traps (exclusivamente) y ampliar la base de datos interna de traducción de Pandora, de forma que cuando llegue un trap, sea automáticamente traducido por su descripción.

Para subir las MIBs del Fabricante se pincha en “Examinar”, se elige el archivo que debe de estar con extensión txt y se pincha en “Upload MIB”.



Cima6.png



Una vez que se ha subido el sistema lo incorpora a su librería de traps.

1.5 Alertas con traps SNMP complejos

Las alertas descritas anteriormente son para ocasiones donde el trap está bien definido, es siempre el mismo, y no tiene una información relevante que debamos rescatar.

En otras ocasiones nos podemos encontrar con un trap que tiene la siguiente fisionomía:

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"

Este es un trap "complejo", que ademas de un OID y un valor, contiene una información compleja, basada en varios OID y varios valores. Un trap puede tener, en su parte compleja, una estructura completamente libre, basada en pares de OID y valores (contadores, numericos, alfanumericos, fechas....).

Este trap se visualizaría en la consola de traps de la siguiente manera:


Compex trap def3.png



Si nos fijamos en detalle en la información extendida (Custom data) existen varios trozos de información util. Concretamente, el primer campo, con el OID que termina en 2005.1 parece un identificador, el tercer campo con OID acabado en 2005.3 parece un mensaje de error. Los campos 2 y 4 no parecen de mucha utilidad, ya que el 4º por ejemplo, es un código que desconocemos.

Pensemos que podríamos crear un evento a partir de un trap, colocando partes específicas del trap en el texto, por ejemplo, supongamos que queremos construir un evento que contenga la siguiente información:

Chassis Alert: <mensaje de error> en dispositivo <identificador>

El reto consiste en crear una alerta que haga "match" en esos campos, obtenga el trozo de información y lo use posteriormente para componer una mensaje en una alerta. Podemos hacer esto con Pandora FMS, usando expresiones regulares avanzadas, usando selectores. Puede encontrar más información sobre expresiones regulares aquí: [1].

Los selectores, que usan los caracteres () permite "copiar" información, usando una expresión de búsqueda.

La expresión regular para obtener el campo1 y el campo3 sería la siguiente:

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

Una vez que ya tenemos los campos de información, debemos usarlos en la alerta. Para eso se usan las macros especiales _snmp_f1_, _snmp_f2_ y _snmp_f3_ que sólo tienen sentido en las alertas de traps SNMP.

Para construir el mensaje, utilizaríamos la siguiente cadena:

Chassis Alert: _snmp_f2_ en dispositivo _snmp_f1_

En resumen, así se crearía la alerta completa:



Compex trap def1.png



Y así se visualizaría en el visor de eventos.



Compex trap def2.png



Para hacer este tipo de alertas, es necesario tener buenos conocimientos de Expresiones Regulares, ya que un simple espacio, una comilla o un carácter en el sitio equivocado puede hacer que no funcione. Recuerde siempre que las alertas SNMP llevan implícito el uso de expresiones regulares. La forma de establecer una alerta más sencilla, usando expresiones regulares, sería la siguiente:



Compex trap def4.png



Esta alerta seria "Compatible" con la anterior, de forma que para el mismo trap, podrían saltar dos eventos diferentes:



Compex trap def5.png



1.6 Asociar un trap al resto de alertas de Pandora / SNMP Agent trap forwarding

Las alertas definidas sobre traps son completamente independientes del motor de alertas de Pandora, por lo que no se pueden establecer correlaciones del tipo “salta una alarma si la temperatura sube a 29 grados y salta el trap de caída de fuente secundaria de alimentación”. Tampoco se pueden representar alertas de este tipo (ya que no están -en principio- asociadas a ningun modulo de Pandora FMS, con lo que no se puede relacionar la monitorización de la consola de traps con elementos tales como informes o mapas.

Modulo especial SNMPTrap, conteniendo el trap reenviado desde la consola SNMP:

Snmptrap agent.png


Para poder hace esto, existe un método llamado "Agent SNMP Trap Forwarding". Esta opción (general al servidor) reenvia el trap a un modulo especial del agente llamado "SNMPTrap" como cadena de texto, si y solo si, la direccion IP origen del trap está definida como IP de un agente. Cuando esto ocurre, el trap llega como una linea de texto al agente dentro de ese modulo, que es un modulo que se define solo cuando llega el primer trap.

Sobre ese módulo se pueden especificar alertas de texto, siendo estas completamente estandard, como las de cualquier modulo. Esto permite personalizar la monitorización SNMP para que ciertos traps, de ciertos orígenes puedan ser tratados como un módulo más, y así integrarlo en el resto de la monitorización, incluyendo la correlación de alertas.

Aspecto que tiene el modulo "SNMPTrap":



Snmptrapforward2.png


Esta es una característica Enterprise y se configura en la sección principal de configuración de Pandora FMS, con una opción como la de la imagen:



Opción de configuración para habilitar el reenvío de traps a los agentes:

Snmptrap agent forwardsetup.png


Si se cambia esta opción, hay que reiniciar el servidor de Pandora FMS para que empieze a actuar.

Otra solución es montar una alerta sobre el trap que active un módulo de un agente. Por ejemplo, el trap es escribir en un fichero de logs, y se tiene un agente que lea ese fichero y salte cuando hay un "1" escrito. De esta forma, el módulo saltará cuando se reciba el trap deseado y se podrá establecer la correlación en base al trap recibido.

1.7 Filtrado de traps en el servidor

Algunos sistemas reciben un número elevado de traps de los cuales sólo interesa monitorizar un pequeño porcentaje. Desde la versión 3.2 de Pandora FMS es posible filtrar los traps que recibe el servidor para evitar cargar la aplicación de manera innecesaria.

Desde Administration>Manage SNMP Console>SNMP Filters se pueden definir distintos filtros. Un trap que case con cualquiera de ellos será automáticamente descartado por el servidor.

Snmp filter editor.png


El filtro se aplica como una expresión regular sobre la entrada correspondiente al trap en el log de SNMP (por defecto /var/log/pandora/pandora_snmptrap.log), que tiene el siguiente formato:

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

Siendo:

  •  %y: Año actual.
  •  %m: Mes actual (numérico).
  •  %l: Día del mes actual.
  •  %h: Hora actual.
  •  %j: Minuto actual.
  •  %k: Segundo actual.
  •  %a: Dirección de orígen (sólo traps versión 1).
  •  %N: OID.
  •  %w: Tipo de trap (numérico).
  •  %W: Descripción del trap.
  •  %q: Sub-tipo del trap (numérico).
  •  %v: Lista de variables separadas por tab (custom OID).

Por ejemplo, para filtrar todos los traps enviados por el host 192.168.1.1 podríamos definir el siguiente filtro:

Snmp filter example.png

1.8 Gestor de TRAPS externo

La consola de SNMP está limitada a recibir traps, ya que solo procesa TRAP como ente individual, pero un trap puede contener muchisima informacion. A veces ocurre que la unica monitorizacion que podamos hacer está basada en traps. Para ello podemos optar por "postprocesar" la informacion recogida en un trap a traves de un script externo, que actua a modo de plugin.

Para procesar los datos de un trap con detalle, se puede enviar toda la informacion de un trap a un script, como resultado de una alerta. He usado este trap para el ejemplo, es la vista del trap tal cual estaria en el log de la consola de snmp de Pandora:


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


Snmp plugin1.png



Snmp plugin2.png


En las capturas se puede ver como se crearia una alerta especial, que ejecuta un script con los contenidos completos del trap (_data_) y como se crea la alerta de tipo SNMP. En este caso se ha mapeado para la OID Especifica (.1.3.6.1.4.1.1722.2.10.1.1.1) pero podría haber sido mas genérica, por ejemplo (.1.3.6.1.4.1.1722) para invocar al script ante cualquier tipo de traps de esta tipologia (.1.3.6.1.4.1.1722 imagino que serán parte de la MIB especifica de AIX).

Se ejecuta un script que procesa esos datos y "analiza" el trap para escribir datos en Pandora FMS directamente, generando un XML y dejandolo en /var/spool/pandora/data_in a modo de datos como si vinieran de un agente. Un script basico para este caso podría por ejemplo, generar inforamacion compleja ya que tenemos bastante informacion en este trap, a saber:

  • IP Origen.
  • Evento principal (Cold start)
  • Eventos secundarios (descriptivos): 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.

Al diseñar un script que "parsee" cada uno de esos datos, por ejemplo "miscript.pl" y que guarde en /var/spool/pandora/data_in el XML con un nombre generico mas un numero aleatorio p.e snmp_gateway.31415.data

El XML generado deberia tener el siguiente aspecto.

<?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>generic_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>

La aplicacion es infinita, pero eso si, cada script debe ser particularizado ya que puede tener una estructura muy dinámica, en muchos sistemas la informacion que se recibe es no solo de texto sino tambien numérica, con lo que puede alimentar a módulos de información numerica para poder representar graficas etc, eso si, los datos siempre son asincronos.

1.8.1 Ejemplo práctico: Monitorización ESX utilizando traps

Una de las cosas más problemáticas de monitorizar es la infraestructura "distribuida", más si cada versión cambia su implementación para reunir información, como VmWare ESX. En este pequeño capítulo intentaremos explicar cómo monitorizar los sistemas ESX utilizando un gestor externo de Traps SNMP.

Los traps ESX son como estos:

.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%"

Tal como puedes vr, los traps pueden ser utilizados para recolectar información del CPU, el Disco, o la Memoria. La idea general detras del gestor de traps es escribir un pequeño script que sea capaz de "entender" el trap y crear un XML simulando un agente de software. De este modo, para cada tecnología deberías escribir un gestor de trap, pero todo el proceso es común. El proceso para entender esto está explicado en cuatro pasos:


  1. Crear el handler script. Puedes basar tu trabajo en el script que te proporcionamos más abajo.
  2. Crear un comando de alerta
  3. Crear una acción de alerta utilizando comandos anteriores. Algunas veces, con opciones personalizadas para cada agente "destinatario" que desees (si tienes varios grupos de ESX, te gustará seguramente tener datos en diferentes agentes).
  4. Crear una alerta de Trap SNMP que mapee el OID enterprise (la información del trap para todos los tipos de esta tecnología específica y/o la dirección IP del trap fuente.

Veamos el primer paso: crear el script de manipulador de traps:

1.8.1.1 Paso 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 Paso 2: Crear el comando de alerta

En este ejemplo, he puesto el script del comando en /tmp, ponlo en un lugar más seguro, y asegúrate de que se pueda ejecutar (chmod 755):



Trap handler step2.png


1.8.1.3 Paso 3: Crear la acción de la alerta

Crea una acción específica para enviar toda la información a traps de agentes específicos. En este caso, la información será enviada a un agente llamado WINN1247VSR. El comando de arriba acepta como parámetros el nombre del agente que llevará toda la información (ESX Virtual Center), y "trozos" de datos del TRAP, que puede ser ilimitado e incluye toda la información que envias al trap.



Trap handler step3.png


1.8.1.4 Paso 4: Crear la alerta SNMP

Configura los traps de alerta utilizando la acción que acabas de crear.



Trap handler step4.png


Para procesar todos los traps de Tecnología ESX, que este encontrará, utilizando el OID específico .1.3.6.1.4.1.6876.4.3.301 para mapear los traps ESX. También podemos filtrar por fuente de IP para cada Centro Virtual, mediante el filtrado por dirección IP de origen (enviado en el Trap)

1.8.1.5 Visualización de Datos

Esto es un ejemplo de cómo se verá la información. Con estos datos, podrás gestionarla como módulos estandar.

Trap handler step5.png


Volver a Indice de Documentacion Pandora FMS