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

Los dispositivos de red que soportan SNMP, como switches, routers, servidores, impresoras o AP's pueden enviar alarmas (o traps SNMP) cuando suceden determinados eventos, tales como caída de un interfaz, la carga de la CPU o de la red es muy alta, una UPS cambia de estado o se llena una partición de disco. Cada dispositivo tiene su propia "colección" de posibles eventos, que se refleja en una colección, llamaba MIB, en este caso, diferente de la MIB que usábamos para hacer consultas al dispositivo.

Trap-example.png

Los traps son enviados sólo cuando sucede algo, de forma asíncrona (no repetitiva en el tiempo) por el dispositivo hacia un receptor de traps SNMP. 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 demonio, almacena los traps en un log ubicado por defecto en

/var/log/pandora/pandora_snmptrap.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 poder trabajar con traps 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.1.1 SNMPv3

Los traps SNMPv3 son rechazados a menos que el usuario que los envía se añada a /etc/snmp/snmptrapd.conf utilizando la directiva createUser. Por ejemplo:

disableAuthorization yes
createUser -e 0x0102030405 snmpv3user SHA mypassword AES

Template warning.png

Se debe especificar el engineID con la opción -e. De lo contrario, sólo se recibirán INFORMs SNMPv3.

 


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. Mediante el icono de la lupa se puede desplegar toda la información del trap, igual que ocurre con los eventos. Aquí podemos ver la información detallada de un trap SNMP.


Traps.JPG


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.

Color

Además los traps tienen 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.

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


1.2.1 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. También es posible validar múltiples traps marcándolos y pinchando en el botón de “validate”. El procedimiento es similar a como funcionan los eventos en Pandora FMS.


Traps2.JPG


1.2.2 Borrar traps

Es posible borrar traps una vez que los mismos se han tratado, bien individualmente o mediante selección múltiple y acción "Delete". Para evitar que los traps se acumulen, existe una opción de configuración que por defecto borra los traps de más de 10 días automáticamente.


Traps3.JPG


1.3 Alertas de Traps SNMP

Pandora FMS también dispone de un sistema de alertas para los traps SNMP que recibe. Se basan principalmente en reglas de filtrado, buscando coincidencias en todos los campos posibles de acuerdo a reglas que configuremos para disparar la alerta. Antes de seguir leyendo, podemos saber más sobre las alertas de Pandora [1]

1.3.1 Añadir una alerta

Las alertas de traps SNMP tienen varios campos que se utilizarán para buscar coincidencias en los trap SNMP recibidos en la consola. Pueden utilizarse de forma opcional los campos que se quieran para crear reglas más generales o más específicas en función de la necesidad:

  • 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 expresión 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. Aquí funciona, igualmente, la búsqueda por expresión regular. Por ejemplo si tenemos un trap que envía la cadena "Testing TRAP 225" yo puedo buscar cualquier trap con la subcadena "Testing TRAP" con la expresión 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 mayoría de los traps generados suelen ser de tipo "Other"; si no especifica 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.
  • Variable bindings/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 acción de email (si queremos sobreescribir el mail que tenga por defecto en la acción). Para entender a fondo como funcionan los campos personalizados en las acciones/plantillas de alertas, lea a fondo el capítulo de la documentación que explica las alertas en Pandora FMS [2]
  • 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 en el intervalo dado (o time threshold).
  • 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. Las prioridades de las alertas son diferentes y no tienen nada que ver con la prioridad de los traps, ni con la de los eventos de Pandora FMS.
  • Alert Action: Combo donde se determina la acción que va a ejecutar la alerta. Si se elige 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.

1.3.1.1 Ejemplo de alerta de traps

Supongamos que recibimos un trap como el que sigue:

Trap sample for alert.jpg

En este caso, tenemos un OID principal (.1.3.6.1.4.1.2789.2005) que identifica un trap que puede contener mensajes de sobrecalientamiento de CPU (no sabemos si más cosas) pero sabemos que en dos variables deja la CPU que se calienta y la temperatura de esa CPU en ese momento, en las variables 1 y dos respectivamente. Como queremos identificar solo los traps de calentamiento de CPU hacemos coincidir la cadena de "Heat alert" en la primera variable del trap (recordemos que tenemos hasta 20 para hacer búsquedas).

Definir la primera parte del trap es sencillo, solo utilizamos el OID principal para hacer el primer y más importante filtro previo:

Trap alert definition 1.jpg

La segunda parte de la definición del trap es la que contiene la parte esencial. En la primera variable del trap, buscamos la cadena "Heat alert" si llegaran traps con el OID principal pero en la primera variable no contuvieran esa cadena de texto, la alerta no saltaría

Trap alert definition 2.jpg

Y finalmente, al escoger una alerta de tipo "Evento de pandora", conformamos el mensaje usando las variables que contienen el valor de las variables 1 y 2 del trap recibido:

Trap alert definition 3.jpg

De esta forma, cuando salte la alerta, el evento generado tendrá este aspecto:

Event result of alert.jpg

1.4 Trabajando en entornos con muchos traps

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

La protección ante tormenta de traps, combinada con el filtrado de traps (ver a continuación) permite que si recibimos cientos de miles de traps al día, trabajemos solo con unos pocos miles, a fin de eliminar los redundantes o aquellos que no son útiles.

1.4.2 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. Con 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 fijo:

%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.50.20 podríamos definir el siguiente filtro:

Snmp filter example.png

1.4.3 Estadísticas de traps SNMP

Esta vista permite ver estadísticas de traps, tanto por origen (IP) como por OID, esto permite una gestión eficaz de los filtros, al permitir identificar las IP's que mas traps generan y los OIDs que mas se repiten. El sistema muestra estadísticas de los traps de los últimos 30 días.


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 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.5.1 Renombrado y personalización de 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 icono de edición del trap que desea personalizar:


Traps5.JPG


Aparecerá una página similar a la siguiente:


Traps7.JPG


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 diferenciarlos. Su contenido (incluido el 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.

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


Traps8.JPG


1.5.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.6 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 trap 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:


Traps9.JPG


Si nos fijamos en detalle en la información extendida (Variable bindings) 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 busque coincidencias 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í: [3].

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.6.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.7 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.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 muchísima información. A veces ocurre que la única monitorización que podamos hacer está basada en traps. Para ello podemos optar por "postprocesar" la información recogida en un trap a través de un script externo, que actúa a modo de plugin.

Para procesar los datos de un trap con detalle, se puede enviar toda la información 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 estaría 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 crearía 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 tipología (.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 dejándolo en /var/spool/pandora/data_in a modo de datos como si vinieran de un agente. Un script básico para este caso podría por ejemplo, generar información compleja ya que tenemos bastante información 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 genérico mas un numero aleatorio p.e snmp_gateway.31415.data

El XML generado debería 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>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>

La aplicación de esta tecnología es infinita, pero eso si, cada script debe ser particularizado ya que puede tener una estructura muy dinámica, en muchos sistemas la información que se recibe, no solo es de texto, si no también numérica, con lo que puede alimentar a módulos de información numéricos y así representar gráficas etc. Eso sí, habrá que tener en cuenta que los datos generados en el XML deberían ser siempre de tipo asíncrono.

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 se puede ver, los traps son utilizados para recolectar información del CPU, el Disco, o la Memoria. La idea general detrás 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


1.9 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.9.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.9.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.9.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.10 Gestión independiente del demonio snmptrapd

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

1. Debe activar igualmente el parámetro snmpconsole en el servidor de Pandora FMS.

2. Los logs configurados en el servidor de Pandora FMS 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 estándar 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 configuración del servidor, el token:

snmp_trapd manual

5. Cuando establezca este funcionamiento. Debe realizar la siguiente operación:

  • Cambiar la configuración en /etc/pandora/pandora_server.conf
  • Parar el servidor de Pandora FMS.
  • 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 FMS.

1.10.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 FMS 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 FMS. Si necesita rotar de forma externa el log de traps, deberá reiniciar el servidor de Pandora FMS después de borrar los ficheros anteriormente mencionados.

1.11 Buffering de traps SNMP

Si los traps SNMP se envían a un manager externo a través de una conexión poco fiable se perderá parte de la información. Pandora FMS le permite, en vez de eso, reenviar los traps desde un snmptrapd local a su servidor de Pandora FMS de una forma fiable.

1.11.1 Arquitectura

Remote snmp trap schema.jpg

  • Un agente SNMP envía traps a un snmptrapd local.
  • Un agente de Pandora FMS local lee traps del fichero de log de snmptrapd's y los manda al servidor de Pandora FMS designado dentro de un fichero de datos XML, guardándolo en el buffer de XML y reintentándolo más tarde si fuese necesario.
  • El Data Server lee traps de ficheros de datos XML y los vuelca en un fichero de texto plano.
  • La consola SNMP procesa los traps desde el fichero de texto plano.

Template warning.png

Es más eficiente que la consola SNMP procese directamente los traps desde el fichero de log snmptrapd's. Esta configuración se recomienda sólo si la fiabilidad o la conectividad directa son motivo de preocupación.

 


1.11.2 Prerequisitos

  • Un snmptrapd local que está recibiendo traps.
  • Un agente de Pandora FMS local.
  • Una instalación de Pandora FMS.

1.11.3 Configuración

1.11.3.1 snmptrapd

Edite el fichero /etc/snmp/snmptrapd.conf y asegúrese de que está logueando a un fichero en un formato compatible con Pandora FMS (puede cambiar el nombre del fichero de log si fuese necesario):

[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

Utilizaremos el plug-in grep_snmptrapd que viene con el agente de Pandora FMS para leer datos del fichero de log de snmptrapd.

Edite el fichero de configuración del agente local, /etc/pandora/pandora_agent.conf, y añada la siguiente línea, ajustando el path del fichero de log de snmptrad si fuese necesario:

module_plugin grep_snmptrapd /var/log/snmptrapd.log

1.11.3.3 Servidor de Pandora FMS

Tenemos que indicarle a la Consola SNMP que procese traps de un fichero de log externo escrito por el Data Server.

Edite el fichero de configuración del servidor, /etc/pandora/pandora_server.conf, y:

  • Asegúrese de que la Consola SNMP está habilitada:
snmpconsole 1
  • Asegúrese de que el Data Server está habilitado:
dataserver 1
  • Configure un fichero de log SNMP externo. Si no existe, la Consola SNMP lo creará:
snmp_extlog /var/log/pandora/pandora_snmptrap.ext.log

Template warning.png

snmp_extlog puede ser cualquier fichero en el que el servidor de Pandora FMS pueda escribir, pero tiene que ser distinto de snmp_logfile (también definido en /etc/pandora/pandora_agent.conf).

 


Volver a Indice de Documentacion Pandora FMS