Desde hace algo más de cuatro meses estoy enfrascado en una tarea interesante que tengo que hacer en el trabajo. Se trata de hacer que las alarmas de todo tipo de aparatos hardware (cabinas de discos, chasis blade de virtualización, librerías de cintas, SAIs, electrónica de red, balanceadores) estén integradas en el Nagios.
Nagios es la aplicación que utilizamos para monitorizar las aplicaciones y que nosmartiriza avisa cuando hay algún problema.
A bote pronto la cantidad y variedad de chismes que tenemos es grande, con lo que la tarea puede ser abrumadora:
La forma de implementar una sistema que recoja los traps y que los transforme en alarmas para el nagios se basa en aprovechar varios demonios -no hay que reinventar la rueda- llamados snmptrapd y nsca.
El primero, snmptrapd, es una aplicación que recoge las notificaciones que les envian los agentes y que segun sea esa notificación puede ejecutar un script -manager-. Se puede hacer que el script manager sea genérico, es decir que sea invocado ante cualquier trap, o que sea determinado según sea el trap recibido.
La lógica de los managers es bastante sencilla. Primero recoge el OID del trap, que es un identificador de la notificación. Cada trap diferente tendrá un OID distinto. Luego tratará los parámetros del trap. Como existen parámetros comunes a todos los traps y otros especificos, el manager se encarga de saber que parametros recoger y qué hacer con ellos.
Por último, la lógica del trap determinara como notificar al Nagios del problema. Para ello se sirve del otro demonio llamado nsca, que no es más que un sistema para enviar mensajes al Nagios con el nombre del servicio, una gravedad del problema y listo.
Hasta el momento, mi implementación consistía en realizar un manager en bash por cada tipo de sistema hardware a monitorizar. De esa forma tengo un manager para cabinas de disco Netapp, otro para los chasis blade de Egenera, etc. Y un manager general para guardar en un log todas las notificaciones.
Una de las parte más complicadas es averiguar cuales son los traps que suponen que existe un problema y cuales son aquellos que pueden indicar que el sistema ha vuelto a la normalidad. Para ello es indispensable disponer de la especificación de los MIBs del dispositivo. El mib contiene la relación de OIDs de los traps y variables del dispositivo.
Casi todos los dispositivos que disponen de un agente snmp, el fabricante ofrece el MIB del mismo, siendo posible entender sus problemas. De esa forma, la lógica del script se reduce al manejo de unas notificaciones y poco más.
Llegados a cierto punto, uno se da cuenta de que no puede estar creando script para cada tipo de dispositivo, sino que debe haber algo más general.
Lo primero es entender que el funcionamiento de un sistema de alerta para un dispositivo cualquier se basa en una maquina de estado con cuatro estados 'de notificación' distintos.
Los traps que envia el agente snmp del aparato no hacen otra cosa que cambiar el estado de notificación. Si llega un trap 'de warning', el estado del dispositivo se pone Warning. Si es de Ok, entonces pasamos a Ok. Estos cambios de estados son independientes del estado anterior que pudiese tener el aparato.
Así que estoy empezando a hacer un programita que reuna el trabajo de configurar un manager y traducir sus estados de notificación a algo visual e incluso pueda notificar los cambios a terceros programas (nagios por ejemplo).
El programa tiene los siguientes componentes:
Nagios es la aplicación que utilizamos para monitorizar las aplicaciones y que nos
A bote pronto la cantidad y variedad de chismes que tenemos es grande, con lo que la tarea puede ser abrumadora:
- Cabinas de disco NetApp y SGI.
- Balanceadores Alteon y BipIP.
- Electrónica de red Cisco, HP y MRW.
- Switches de fibra Brocade.
- Chasis Blade de Egenera y HP.
- Virtualización PrimeQuest de Futjisu.
- Librerias de cintas virtuales CentricStor de Fujitsu.
- SAIs Merling-Gerin, Riello y APC.
La forma de implementar una sistema que recoja los traps y que los transforme en alarmas para el nagios se basa en aprovechar varios demonios -no hay que reinventar la rueda- llamados snmptrapd y nsca.
El primero, snmptrapd, es una aplicación que recoge las notificaciones que les envian los agentes y que segun sea esa notificación puede ejecutar un script -manager-. Se puede hacer que el script manager sea genérico, es decir que sea invocado ante cualquier trap, o que sea determinado según sea el trap recibido.
La lógica de los managers es bastante sencilla. Primero recoge el OID del trap, que es un identificador de la notificación. Cada trap diferente tendrá un OID distinto. Luego tratará los parámetros del trap. Como existen parámetros comunes a todos los traps y otros especificos, el manager se encarga de saber que parametros recoger y qué hacer con ellos.
Por último, la lógica del trap determinara como notificar al Nagios del problema. Para ello se sirve del otro demonio llamado nsca, que no es más que un sistema para enviar mensajes al Nagios con el nombre del servicio, una gravedad del problema y listo.
Hasta el momento, mi implementación consistía en realizar un manager en bash por cada tipo de sistema hardware a monitorizar. De esa forma tengo un manager para cabinas de disco Netapp, otro para los chasis blade de Egenera, etc. Y un manager general para guardar en un log todas las notificaciones.
Una de las parte más complicadas es averiguar cuales son los traps que suponen que existe un problema y cuales son aquellos que pueden indicar que el sistema ha vuelto a la normalidad. Para ello es indispensable disponer de la especificación de los MIBs del dispositivo. El mib contiene la relación de OIDs de los traps y variables del dispositivo.
Casi todos los dispositivos que disponen de un agente snmp, el fabricante ofrece el MIB del mismo, siendo posible entender sus problemas. De esa forma, la lógica del script se reduce al manejo de unas notificaciones y poco más.
Llegados a cierto punto, uno se da cuenta de que no puede estar creando script para cada tipo de dispositivo, sino que debe haber algo más general.
Lo primero es entender que el funcionamiento de un sistema de alerta para un dispositivo cualquier se basa en una maquina de estado con cuatro estados 'de notificación' distintos.
- OK. El dispositivo esta funcionando correctamente. No hay problemas.
- Warning. El dispositivo esta funcionando pero hay ciertas partes que tienen problemas y que es posible que hagan que el aparato deje de funcionar.
- Critical. El aparato no esta funcionando bien. Existe algun problema que no le deja hacer su función.
- Unknow. Algo le pasa pero no se sabe concretamente en que consiste o se desconoce el estado del funcionando del aparato.
Los traps que envia el agente snmp del aparato no hacen otra cosa que cambiar el estado de notificación. Si llega un trap 'de warning', el estado del dispositivo se pone Warning. Si es de Ok, entonces pasamos a Ok. Estos cambios de estados son independientes del estado anterior que pudiese tener el aparato.
Así que estoy empezando a hacer un programita que reuna el trabajo de configurar un manager y traducir sus estados de notificación a algo visual e incluso pueda notificar los cambios a terceros programas (nagios por ejemplo).
El programa tiene los siguientes componentes:
- Manager general, instalado como manager 'default' del demonio snmptrapd, que guardará las notificaciones en una base de datos.
- Manager despachador, que es el encargado de determinar que manager específico se tiene que ejecutar en función de la notificacion que ha llegado y del dispositivo que lo envia.
- Cliente de estados que consulta la base de datos y muestra el estado de un dispositivo.
- Cliente configurador de manager específicos que sirve para configurar la máquina de estados de notificación de un dispositivo.
Mamona... como que aún estoy esperando el metrónomo. Pero no te preocupes... si quieres te echo un cable.
ResponderEliminar¡Si es que eres un sentimental!
Todavía te acuerdas de él? Al final va a resultar que no eres un desmemoriao.
ResponderEliminar