Pandora: Documentation es: Monitorizacion traps SNMP

From Pandora FMS Wiki
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.

Para trabajar con SNMP, primero modifique el siguiente parámetro en /etc/pandora/pandora_server.conf para activar la Consola SNMP:

snmpconsole 1

Si quiere que las traps le aparezcan traducidas (ya sean los enlaces variables o la cadena Enterprise) deberá activar los siguientes parámetros (sólo en la versión Enterprise):

translate_variable_bindings 1
translate_enterprise_strings 1

También debe configurar el archivo /etc/snmp/snmptrapd.conf con los parámetros necesarios, por ejemplo:

authCommunity log public
disableAuthorization yes

Con esta configuración, los traps se crearán para la comunidad public y no requerirán autorización.

1.2 Acceso a la consola de recepción de traps

Para acceder a la consola de recepción de traps se va a Monitoring > SNMP > SNMP Console 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 “Toggle 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:

  • Alert: combo donde se elige por alertas lanzadas o no lanzadas.
  • 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.
  • Group by OID/IP: permite agrupar por OID/IP.

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. Esto está en el menu de Alertas -> Alertas SNMP. Los traps de SNMP no tienen nada que ver con el resto de alertas del sistema, aunque reutilizarán el sistema de acciones. Tenga en cuenta que al no existir "plantilla de alertas" aqui, las condiciones y los campos pasados como parámetro al comando funciona diferente a como funciona una alerta normal. Los campos de datos de la alerta sobre escriben a los campos de la acción y no existen alertas de recuperación (no se puede recuperar un trap), ya que en caso de que se reciba otro trap para advertir de que algo deja de estar mal, hay que tratarlo como un trap diferente.

1.3.1 Añadir una alerta ( >= 5.0 )

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.
  • Enterprise String: OID principal del Trap. Se puede utilizar una expresión regular. Si no se usa una expresion regular se buscará la presencia de la cadena, pudiendo ser un trozo del OID, de forma que si queremos buscar, por ejemplo: 1.21.34.2.3 en un OID más largo, podemos emplearlo del mismo modo en el campo, y realizará la búsqueda como si se tratase de: .*1.21.34.2.3.* Por lo que NO hay que emplear asteriscos.
  • 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. La mayoria de los traps generados suelen ser de tipo "Other"; si no espefica nada, buscará cualquier tipo de trap.
  • Single value: Filtra por el valor del trap. En el ejemplo igual a .666. Esto solo hace referencia al valor simple del OID principal, no de cualquier OID secundario.
  • Custom OID/Data #1-20: Son expresiones regulares que intentan casar con las variables 1 a 20. Si hay un acierto, se dispara la alerta. El valor de la variable se guarda en la macro _snmp_fx_ correspondiente (_snmp_f1_, _snmp_f2_, ...). Aunque sólo se puede especificar una expresión regular para veinte variables, las macros _snmp_fx_ macros están disponibles para todas ellas (_snmp_f11_, _snmp_f12_, ...).
  • 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, o el mail de destino en caso de elegir una accion de email (si queremos sobreescribir el mail que tenga por defecto en la accion).
  • 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. Si se deja en blanco utilizaría lo que hubiera definido en la acción.
  • 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. Si se deja en blanco utilizaría lo que hubiera definido en la acción.
  • 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á.
  • Position: Las alertas con menor posición se evalúan primero. Si hay varias alertas con la misma posición que coinciden con el trap, se lanzarán todas las alertas coincidentes con la misma posición. Las de menor posición, aunque coincidan, no se lanzarán.

A continuación, vemos un ejemplo de creación de alerta:



Snmp trap alert.png


Como hemos visto, se pueden almacenar hasta 20 variables. Estas variables no tienen por qué seguir un órden consecutivo. La posición que ocupa la variable se puede definir en el campo que precede su valor. Es decir, si nosotros queremos hacer una alerta que busque los valores “Uno” en la primera variable recibida en el trap, “tres” en la tercera variable recibida por el trap y lo mismo para Cinco y Siete, se configuraría como se puede ver más abajo:



Alerta snmp2.png



Podemos hacer uso del valor de las variables con coincidencia en las macros _snmp_f1_ .. _snmp_f7_ de forma que al definir la alerta, la acción nos permite usar esas macros:



Alerta snmp3.png


En este caso concreto, al definir la alerta usando un evento, resultaría un evento como el siguiente:



Snmp trap alert event.png


La alerta generada, un evento de auditoria tiene este texto:

SNMP Alert of 192.168.5.2 with OID .1.3.6.1.4.1.2789.2005 Binding 1: “uno” Binding 3: “tres” Binding 5: “cinco” Binding 7: “siete”

De esta manera, si el trap tiene 200 variables, se pueden usar hasta 20 filtros de variables (bindings) y tomar el valor de hasta 20 variables, independientemente si están en la posición 10, 50, o 170.

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

1.4 Protección ante tormenta de traps

Existen un par de parámetros en el servidor que se utilizan para proteger al sistema ante la llegada de una tormenta de traps del mismo origen. Para ello se utilizan los siguientes parámetros de configuración en el fichero pandora_server.conf.

  • snmp_storm_protection: Máximo número de traps procesados en el intervalo de protección.
  • snmp_storm_timeout: Intervalo en segundos de protección ante tormenta de traps. Durante ese intervalo solo pueden procesarse X traps de la misma fuente (misma IP).


1.5 Estadísticas de traps SNMP

Desde la version 5.1 SP1 existe una seccion nueva que permite ver estadísticas de traps, tanto por origen (IP) como por OID, esto permite una gestion eficaz de los filtros, al permitir identificar las IP's que mas traps generan y los OIDs que mas se repiten. El sistema muestra estadisticas de los traps de los ultimos 30 dias.


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

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.6.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.7 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 identificador sería la siguiente:

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

La expresión regular para obtener el mensaje de error sería la siguiente:

.*.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_, _snmp_f3_ (etc) 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.7.1 Ejemplo adicional

Esto otro ejemplo, utiliza una alerta de tipo email para enviar información sobre el nombre del interfaz cada vez que se recibe un trap específico que notifica problemas en dicha interfaz. De forma que al email me llega la informacion del dispositivo y la interfaz, sacando esa información del interior del trap.

Este es el trap recibido del switch:



Another trap alert sample.png



Asi es como quiero que me llegue el mail



Trap email.png



Así es como defino el trap.



Another snmp trap sample.png



1.8 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.9 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 origen (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.10 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.10.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.10.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.10.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.10.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.10.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.10.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


1.11 SNMP trap forwarding ( > v5.0 )

Con Pandora FMS es posible habilitar el reenvío de traps SNMP a un host externo habilitando el snmp_forward_trap token en el fichero de configuración de Pandora.

1.11.1 Ejemplo de configuración para reenvío de traps usando 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.11.2 Ejemplo de configuración para reenvío de traps usando 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.11.3 Ejemplo de configuración para reenvío de traps usando SNMP v3

Este ejmplo es particularmente complicado debido al conocimiento requerido en SNMP v3. Vamos a suponer que el agente SNMP remoto definido en snmp_forward_ip tiene la siguiente entrada en su fichero de configuración /etc/snmp/snmptrapd.conf:

createUser -e 0x0102030405 myuser MD5 mypassword DES myotherpassword

La configuración en el fichero de configuración de Pandora sería entonces:

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

Más información en NET-SNMP v3 Traps

1.12 Gestión independiente del demonio snmptrapd ( > v5.1 )

Es posible que por alguna razón prefiera gestionar el demonio snmptrapd de forma independiente a Pandora (para pararlo o levantarlo de forma independiente al Daemon principal de Pandora). Para ello debe tener en cuenta varias cosas.

1. Debe activar igualmente el parametro snmpconsole en el servidor de pandora.

2. Los logs configurados en el servidor de pandora deben ser los mismos que se generen en la llamada independiente a snmptrapd

3. La llamada a snmptrapd debe tener un formato específico no vale la llamada al demonio estandard del sistema. La llamada debe ser como esta (el parámetro -A es especialmente importante!):

/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. Debe configurar en el fichero de configuracion del servidor, el token:

snmp_trapd manual

5. Cuando establezcla este funcionamiento. Debe realizar la siguiente operacion:

  • Cambiar la configuracion en /etc/pandora/pandora_server.conf
  • Parar el servidor de pandora.
  • Verificar que el proceso snmptrapd ya no se ejecuta (y si es asi, esperar a que se muera o matarlo)
  • Arrancar snmptrapd manualmente (con el formato indicado arriba).
  • Arrancar el servidor de pandora.

1.12.1 Gestión del fichero de log de traps

El proceso snmptrapd puede ser parado y arrancando sin necesidad de parar y arrancar el proceso de pandora server, siempre y cuando que los ficheros pandora_snmptrap.log.index y pandora_snmptrap.log no sean modificados. Si estos ficheros son modificados, es preciso reiniciar el servidor de pandora. Si necesita rotar de forma externa el log de traps, deberá reiniciar Pandora server después de borrar los ficheros anteriormente mencionados.

Volver a Indice de Documentacion Pandora FMS