Configurando Nagios 3.x (y III)

Josemaría

hace 17 años

Continuamos donde lo dejamos. Una de las cosas que tenemos pendiente es hacer que nagios nos notifique las alertas que detecta, porque si tenemos que estar pendientes de las pantallas de estado en todo momento la cosa, después de las primeras horas, no tiene tanta gracia ¿verdad? Para ello lo único que tenemos que hacer es editar el fichero /usr/local/nagios/etc/objects/contacts.cfg y modificar la dirección de correo del contacto que trae por defecto por la nuestra:

define contact{ contact_name nagiosadmin ; Short name of user use generic-contact ; Inherit default values from generic-contact template (defined above) alias Nagios Admin ; Full name of user email alertas.nagios@midominio.es ; <

Si lo del aviso por correo electrónico se nos queda corto existen al menos una solución comercial que permite que nagios nos alerte a través de SMS. Referencias aquí.

Ahora vamos a añadir algunos plugins que requieran de alguna configuración adicional para que veais que también es muy sencillo. Empezamos por uno que nos compruebe el estado de un servidor de mysql. El plugin necesario (check_mysql) viene con nagios aunque no está configurado para su uso. Lo primero que tenemos que hacer es abrir un shell, irnos al directorio de plugins y ver que entrada necesita:

nagios:/usr/lib/nagios/plugins# ./check_mysql -h check_mysql (nagios-plugins 1.4.8) 1.35 Copyright (c) 1999-2006 Nagios Plugin Development Team

This program tests connections to a mysql server

Usage:check_mysql [-d database] [-H host] [-P port] [-u user] [-p password] [-S]

Parece evidente ¿no? Creamos un usuario con privilegios mínimos en nuestro servidor de mysql (el mismo que aloja la intranet en este ejemplo) y probamos:

nagios:/usr/lib/nagios/plugins# ./check_mysql -H 192.168.0.3 -u nagios-test -p nagios-test-pass Uptime: 17940713 Threads: 1 Questions: 796357 Slow queries: 0 Opens: 33 Flush tables: 1 Open tables: 27 Queries per second avg: 0.044

Funciona. Con esta información hacemos una plantilla para este servicio en el archivo commands.cfg:

define command{ command_name mycheck_mysql # check_mysql [-d database] [-H host] [-P port] [-u user] [-p password] [-S] command_line /usr/lib/nagios/plugins/check_mysql -H $HOSTADDRESS$ -u nagios-test -p nagios-test-pass }

Y, finalmente, en el archivo mired.cfg definimos el servicio listando los hosts que queremos que se comprueben con el:

define service{ use generic-service host_name intranet service_description MYSQL check_command mycheck_mysql }

Ha sido fácil ¿verdad? Un par más y acabamos. Ahora necesitamos comprobar la carga de CPU y ocupación de memoria de nuestros controladores de dominio de windows. Nagios trae plugins para hacerlo pero requieren instalar un servicio específico en los servidores a monitorizar y a mi, existiendo SNMP, esto no me parece necesario. Así que nos damos una vuelta por el directorio de plugins de Nagios Exchange hasta encontrar algo que nos venga bien. Allí encontramos dos plugins escritos en perl que pueden servirnos: check_winmen y win_check_cpuload. Los descargamos, descomprimimos, emplazamos en el directorio de plugins de nagios y repetimos el mismo procedimiento de antes. Primero comprobar la entrada que necesitan desde la línea de comandos:

nagios:/usr/lib/nagios/plugins# perl check_win_snmp_cpuload.pl

######## check_win_snmp_process.pl ######## # Version : 1.0 # Date : Dec 20 2005 # Author : Benjamin Jakubowski # Help : http://www.xenux.net # Licence : GPL - http://www.fsf.org/licenses/gpl.txt #################################### check_win_snmp_cpuload.pl IP COMMUNITY PORT warning critical

nagios:/usr/lib/nagios/plugins# perl check_winmen.pl

######## check_winmem ######## # Version : 1.0 # Date : Apr 11 2006 # Author : Peter Stimpel # Thanks to Benjamin Jakubowski for the idea to walk through snmp # Help : http://www.peters-webcorner.de/nagios/ # Licence : GPL - http://www.fsf.org/licenses/gpl.txt #################################### check_winmem IP COMMUNITY warnlevel criticallevel

check_winmem -v for version info

Al igual que en otras ocasiones, vemos que este tipo de plugins requiere que le definamos los niveles que vamos a considerar como warning o crítico. Aunque aquí no aparece especificado en la documentación que acompaña a los plugins nos dice que han de expresarse en porcentajes. Por cierto: no voy a pararme a explicaros como definir y configurar el servicio de SNMP en un servidor windows pero es evidente que hay que hacerlo, además de autorizar en el mismo a nuestro servidor nagios para que pueda recoger estos datos.

Seguimos. Al igual que hicimos antes probamos primero sobre línea de comandos:

nagios:/usr/lib/nagios/plugins# perl check_winmen.pl 192.168.0.4 mi_comunidad_snmp 75 95 OK MEM: usage 20.59 perc - 209064 KBytes of 1015248 KBytes -w 75 -c 95

nagios:/usr/lib/nagios/plugins# perl check_win_snmp_cpuload.pl 192.168.0.4 mi_comunidad_snmp 161 75 90 OK : CPU load HOST-RESOURCES-MIB::hrProcessorLoad.2 = INTEGER: 0 %

Luego con estos datos creamos las plantillas en commands.cfg (observad que, al igual que en línea de comandos, necesitamos ejecutarlos a través del intérprete de perl):

define command{ command_name check_winmen # perl check_winmen.pl IP COMMUNITY warnlevel criticallevel command_line /usr/bin/perl /usr/lib/nagios/plugins/check_winmen.pl $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ }

define command{ command_name check_cpuload # perl check_snmp_cpuload.pl IP COMMUNITY PORT warnlevel criticallevel command_line /usr/bin/perl /usr/lib/nagios/plugins/check_win_snmp_cpuload.pl $HOSTADDRESS$ $ARG1$ $ARG2$ $ARG3$ $ARG4$ }

Y, finalmente, la definición de los servicios en mired.cfg:

define service{ use generic-service host_name windows#1, windows#2 service_description Ocupacion de memoria check_command check_winmen!ietcc!75!95 normal_check_interval 5 retry_check_interval 1 }

define service{ use generic-service host_name windows#1, windows#2 service_description CPU Load check_command check_cpuload!ietcc!161!75!90 normal_check_interval 5 retry_check_interval 1 }

Para acabar un último truco que suelo usar en las instalaciones. Para comprobar que la salida a internet es correcta suelo elegir un par de servidores públicos y añadirlos en mi configuración colgando de nuestro router de salida a internet. De esta forma ya no sólo comprobamos que nuestro router está encendido y responde a los pings sino que está operativo y nuestro proveedor de servicios no está fallando. Nos quedaría por comprobar que nuestros DNS resuelven correctamente (aquí la comprobación la estamos haciendo por IP) pero eso os lo dejo a vosotros como ejercicio ¿vale? El plugin que necesitais para ello se llama check_dns y acompaña a la distribución estándar de nagios. No tiene pérdida. Ah, lo de usar los servidores de microsoft y terra no es porque me fie especialmente de ellos sino porque siempre prefiero hacerle un ping a intervalos regulares a alguien que no me caiga bien 😉

Y bueno... Con esto concluyo el tema que me tengo que ir de vacaciones. Mi intención era demostrar que configurar un sistema con Nagios y dejarlo operativo y funcional es bien sencillo. Pero la cosa no acaba aquí. Nagios permite mucho más de lo que hemos visto. La librería de plugins disponibles es enorme y si aun así ninguno cumple lo que necesitamos para una necesidad muy específica podemos seguir esta guía de desarrollo para hacernos uno a medida en C, perl, python, shell script o practicamente lo que nos de la gana. Para entornos muy críticos, aparte de la notificaciòn por SMS que hemos apuntado antes existen dispositivos hardware que nos permiten controlar la temperatura, humedad relativa, iluminación, estabilidad de la tensión, presencia de líquidos, intrusiones, vibraciones, etc.

Y si estás haciendo una propuesta técnica en tu departamente y tienes dudas de que tus superiores te autoricen a usar una solución open source échale un vistazo al directorio de empresas y organismos que usan nagios y elige las que crees que van a impresionarle más. Seguro que las encuentras...

Comparte esto: