Monitorización de equipos con Nagios

Monitorización de equipos

con Nagios 3

[email protected]

Nagios 3

N

Surgido con el nombre NetSaint y transformado en el proyecto Nagios (http://www.nagios.org), se trata de una herramienta para monitorizar los equipos y servicios de una red. Mediante el uso de distintos comandos, supervisa hasta el mí­ nimo detalle de sus estados, informando a los administradores en caso de detectar­ se cualquier tipo de problema.

Con respecto a versiones anteriores, Nagios 3 está dividido en diferentes archi­ vos para la configuración de los dispositi­ vos y contactos, haciendo más sencilla su administración. Además incluye numero­ sas optimizaciones al poder monitorizar múltiples elementos, generar un mayor número de estadísticas para la interfaz web y agregar nuevas funciones en el in­ térprete de Perl integrado.

CARACTERÍSTICAS

 Monitorizado de servicios de red,

por ejemplo HTTP, SMTP o POP3, dis­ positivos como impresoras o redes de

almacenamiento, y recursos tipo el es­ pacio en disco o la cantidad de memo­ ria utilizada. Mediante el uso del com­ plemento NRPE también es posible monitorizar los recursos de un equipo remoto.

 Envío de notificaciones por correo electrónico o sMs, según su grave­ dad, podemos definir que se envíen co­ mo simples advertencias o marcados como urgentes. También se manda un mensaje informando de la corrección del problema originado, por ejemplo al resolverse automáticamente.

 interfaz web integrada, para ver los estados actuales de monitorizado, su histórico, gráficos de la topología de red para revisar si algún nodo está caído, listado mensajes enviados y generar in­ formes de disponibilidad.

 Creación de eventos, para ejecutar­ los al producirse determinadas situacio­ nes, por ejemplo reiniciar algún servicio cuando la carga de los recursos del equipo sea muy alta.

 agrupación de los elementos mo-nitorizados, como los de servidores web distintos, cambiando sus avisos y alertas según el grupo al que pertenez­ can. Esto permite una administración más sencilla, al cambiar el comporta­

miento de varios elementos a la vez con un mínimo de modificaciones.  grabación y rotación automática

de los estados de los elementos monitorizados en archivos logs, su contenido lo leemos desde cualquier editor de texto o mediante la interfaz web.

 asignación de roles para los usua-rios, permitiendo dividir las tareas en distintos usuarios. Por ejemplo, unos encargados del estado de los servicios y otros de los recursos del equipo, a los que se envían diferentes mensajes.  ampliación de funciones mediante

el uso de complementos, permitien­ do el control de nuevos servicios como los gestores de bases de datos MySQL o PostgreSQL. Para programarlos, po­ demos utilizar el lenguaje que prefira­ mos, ya que Nagios funciona como una pasarela transparente para enviar men­ sajes con las salidas de los programas.

REQUISITOS

Para poder utilizar todas las prestaciones que ofrece Nagios debemos instalar el servidor web Apache 2, el compilador GCC y las librerías GD. Estas últimas son necesarias para crear de manera dinámi­ ca las imágenes generadas en los infor­ mes.

La interfaz web integrada en Nagios genera informes con

el estado actual de los elementos monitorizados

Página oficial del proyecto Nagios.

Listado de contactos creados.

INSTALACIÓN

Primero necesitamos un usuario junto a su respectivo grupo, que será el utilizado por Nagios para funcionar. Podemos crearlos desde las herramientas provistas por nuestra distribución, o utilizar el co­ mando:

# /usr/sbin/adduser nagios con los que añadimos el nuevo usuario y escribimos su contraseña.

Para crear el grupo, ejecutamos: # /usr/sbin/groupadd nagiosgroup # /usr/sbin/usermod

-G nagiosgroup nagios # /usr/sbin/usermod -G nagiosgroup www-data

con los dos últimos comandos añadimos al grupo el usuario creado nagios y el uti­ lizado por Apache, www-data. Este se­ gundo puede variar en algunas instala­ ciones, estando definido en los archivos de configuración del servidor web.

 PASO 2

Entramos a la página: http://www.nagios. org/download y descargamos los archi­ vos de los dos primeros desplegables,

Get Nagios y Get Plugins, utilizando en ambos el botón “Go”, y seleccionado para este último el paquete de nombre nagios-plugins. El primero contiene el programa en sí y el segundo los complementos esenciales.

 PASO 3

Después de descomprimir el paquete de Nagios:

$ tar xvzf nagios-3.0.3.tar.gz y acceder a su contenido:

$ cd nagios-3.0.3

creamos el archivo makefile, indicando el grupo antes creado:

$ ./configure --with-comand-group= nagiosgroup  PASO 4 invocamos su compilación. $ make all  PASO 5

Al finalizar, identificados como root, ejecu­ tamos cuatro comandos más para su ins­ talación:

# make install # make install-init # make install-config # make install-commandmode copiando los archivos, librerías, ejecuta­ bles y archivos de configuración, y asig­ nando los permisos adecuados.

 PASO 6

A continuación, procedemos a instalar los complementos descargados, descompri­ miendo su paquete:

$ tar xvzf

nagios-plugins-1.4.12.tar.gz y dentro de este directorio:

$ cd nagios-plugins-1.4.12 compilamos e instalamos, indicando el usuario y grupo creados.

$ ./configure user=nagios --with-nagios-group=nagiosgroup $ make # make install  PASO 7

Como último paso nos faltaría copiar el ar­ chivo de configuración de Nagios para el servidor web, para lo cual entramos en el directorio nagios-3.0.3 y ejecutamos:

# make install-webconf

Para bloquear los intentos de lectura de las páginas con la información y esta­ dísticas generadas, creamos un nuevo usuario, de nombre nagios_admin, y su contraseña con el comando:

# htpasswd -c /usr/local/nagios /etc/htpasswd.users nagios_admin reiniciando Apache para habilitar el nuevo directorio web creado, ejecutando uno de los dos siguientes comandos según la dis­ tribución que utilicemos:

# /etc/init.d/apache2 reload # /etc/init.d/httpd reload

CONFIGURACIÓN

Nagios divide en varios archivos las opcio­ nes de configuración, utilizando cada uno para definir diferentes parámetros de mo­ nitorizado. Así, encontramos dentro del di­ rectorio /usr/local/nagios/etc/objects

ocho archivos; de los cuales hay tres que se recomienda no modificar, a otro le de­ bemos añadir al menos un correo electró­ nico y otros cuatro que eliminamos o adaptamos a nuestras necesidades, ya que las opciones que almacenan sirven solo de ejemplo.

Los tres primeros, que inicialmente no modificamos, definen los comandos, pa­ rámetros de tiempo y plantillas para los equipos y dispositivos utilizados en otros archivos de configuración:

 commands.cfg: son todos los co­ mandos de control instalados junto a Nagios. Algunos de estos comandos son el acceso por red de un equipo, su espa­ Listado de módulos disponibles que se pueden utilizar.

Creando el nuevo grupo y un usuario asociado.

cio en disco, la memoria swap libre, los usuarios conectados o la disponibilidad de servicios como HTTP, FTP, SSH, SMTP o POP. Estos comandos son proporciona­ dos a los equipos para definir los controles que queremos asignar.

Por ejemplo, el control de acceso por

ping tiene la siguiente sintaxis: define command{ comand_name check_ping command_line $USER1$/check_ping -H $HOSTADRESS$ -w $ARG1$ -c $ARG2$ -p 5 }

donde el valor de command_name es utili­ zado para asignar a un equipo este con­ trol, y los parámetros de command_line

también serán asignados automáticamen­ te con otros archivos CFG.

Los comandos disponibles, a los que sumaremos los provistos por otros com­ plementos, son suficientes para monitori­ zar cualquier equipo o red, incluyendo sus recursos y servicios.

 templates.cfg: colección de plantillas para ser utilizadas en contactos, equipos y servicios. Definen los períodos de tiempo, comandos de monitorizado o frecuencia de reintentos en caso de error, entre otros muchos parámetros. El uso de estas plan­ tillas permite aplicar un conjunto común de opciones a los elementos que se van a controlar, haciendo más sencillo su cam­ bio.

El número de plantillas contenidas es suficiente para casi cualquier equipo y red, definida cada una por la opción na-me. Encontramos seis plantillas de espe­ cial utilidad: generic-contact, para los

contactos; linux-server, servidor GNU/ Linux; windows-server, servidor Windows;

generic-printer, dispositivo de impresión en red; generic-switch, switchs o routers; y generic-service, común para los servi­ cios. A su vez, las cinco primeras depen­ den de otra plantilla de nombre generic-host.

Para que un elemento que va a ser monitorizado pueda hacer uso de los pa­ rámetros de una plantilla (ver Listado 1), por ejemplo linux-server, añadimos en sus parámetros de configuración la línea

use linux-server

 timeperiods.cfg: períodos de tiempo en que los comandos definidos en com-mand.cfg van a ejecutarse, y configura­ ción de cuándo se enviarán los mensajes de alerta a los contactos de contacts.cfg. Admite la definición de franjas temporales por día y hora, por ejemplo definiendo alertas por período laboral para los proce­ sos menos importantes o las 24 horas pa­ ra los críticos.

Para crear un nuevo período de tiem­ po, por ejemplo con la franja horaria de Lunes a Jueves de 9:00 a 19:00, y los Viernes de 9:00 a 15:00, añadimos las lí­ neas:

define timeperiod{

timeperiod_name hora_trabajo alias Hora de trabajo

monday 09:00-19:00 tuesday 09:00-19:00 wednesday 09:00-19:00 thursday 09:00-19:00 friday 09:00-15:00 }

Dentro de este archivo, encontramos otros ejemplos para añadir períodos de tiempo distintos, incluyendo filtros según el día y mes del año.

Aunque podemos añadir las configura­ ciones de estos tres ficheros en un solo archivo, por ejemplo opciones.cfg, e inser­ tarlo dentro de nagios.cfg, es preferible conservar esta separación de ficheros, ya que facilita su modificación al no mezclar parámetros con distintas finalidades.

El cuarto fichero solo lo modificamos para añadir al menos un contacto válido, junto a su nombre y dirección de correo electrónico:

 contacts.cfg: contiene cada uno de los contactos con su nombre y dirección de correo electrónico. A cada elemento monitorizado asignamos al menos un contacto, al cual se le remitirá un mensaje

en caso de generarse un estado de alerta. Para añadir un contacto utilizamos las lí­ neas:

define contact{

contact_name nagiosadmin use generic-contact

alias Administrador Nagios email [email protected] }

donde utilizamos los parámetros: contact_ name, nombre del contacto; use, plantilla del contacto, definido en el archivo tem-plates.cfg; alias, nombre completo del usuario para identificarlo fácilmente; y

email, dirección de correo a la que enviar las alertas. Para cada nuevo contacto, añadimos estos mismos datos pero cam­ biando como mínimo su nombre y correo electrónico.

Para simplificar su configuración hace­ mos uso de los grupos, que unen más de un contacto, por ejemplo:

define contactgroup { contactgroup_name administradores

alias Administradores Nagios members nagiosadmin

}

siendo: contactgroup_name, el nombre del nuevo grupo que asignamos a los ele­ mentos monitorizados; alias, descripción del grupo; y members, listado de contac­ tos separados por comas que constituyen el grupo.

Los tres últimos archivos solo nos sir­ ven como ejemplos, ya que definen los equipos, dispositivos, topología de red y los comandos, plantillas y contactos aso­ ciados:

 localhost.cfg: controla los procesos y servicios del equipo en el que Nagios está ejecutándose.

 printer.cfg: ejemplos de control de im­ presoras.

 switch.cfg: monitorizado de dispositi­ vos de red, como routers y switches.  windows.cfg: monitorizado de equi­

pos y servicios Windows.

El uso de estos archivos se realiza desde el fichero nagios.cfg, mediante las líneas que comienzan por cfg_file. Así, si queremos obviar el uso de alguno, por ejemplo este último para equipos Windows, añadimos a su inicio el carácter “#”. En la configuración predeterminada están desactivados: switch.cfg, printer.cfg

y windows.cfg. define host{ name linux-server use generic-host check_period 24x7 check_interval 5 retry_interval 1 max_check_attempts 10 check_command check-host-alive notification_period workhours notification_interval 120 notification_options d,u,r contact_groups admins register 0 }

Listado 1. Opciones de la plantilla Linux-server

Aunque podemos utilizar estos archi­ vos como base para monitorizar los equi­ pos, y redes modificándolos según nues­ tras necesidades, vamos a crear un archivo de configuración nuevo, de nombre mired. cfg. Únicamente controlará un equipo prin­ cipal, en el que está instalado Nagios, y un servidor situado en la misma red local.

Primero creamos en el directorio /usr/ local/nagios/etc/objects un nuevo archivo de nombre mired.cfg, inicialmente vacío. Lo añadimos junto al resto de opciones de configuración insertando en el fichero na-gios.cfg la línea:

cfg_file=/usr/local/nagios/etc/ objects/mired.cfg

Dentro de este archivo, mired.cfg, in­ sertamos los equipos que vamos a moni­ torizar y sus servicios. Primero utilizamos la opción host, para definir los equipos:

define host{ use linux-server host_name localhost alias localhost address 127.0.0.1 } define host{ use linux-server host_name servidor1 alias Servidor 1 address 192.168.0.5 }

donde hacemos uso de cuatro opciones para cada equipo: use, nombre de la plan­ tilla, indicando la predeterminada linux-server; host_name, el nombre con el que identificarlo; alias, descripción del equipo; y address, dirección iP, utilizando localhost

para referirse al propio ordenador. Cada uno de estos equipos lo relacio­ namos con uno o más servicios, indicando en la opción host_name, el mismo nombre antes definido.

Por ejemplo, añadimos el control de la carga a localhost: define service{ use local-service host_name localhost service_description Current Load check_command check_local_load!5.0,4.0!10.0 }

y el de acceso a nivel ping para el servidor. define service{ use local-service host_name servidor1 service_description PING check_command check_ping!100.0,20%!500.0,60% }

aparte de la opción host_name antes des­ crita, hemos añadido cuatro nuevas: use, nombre de la plantilla, de nuevo utilizamos una predeterminada; service_description, la descripción que queremos dar al servi­ cio; y check_command, con el comando a ejecutar para monitorizar. En esta última, indicamos el nombre de los comandos disponibles en el archivo commands.cfg y los valores de advertencia y emergencia. Así con la línea

check_local_load!5.0,4.0!10.0 definimos que al llegar a la carga 4.0 ó 5.0

se lance un mensaje de advertencia, y al alcanzar el valor 10.0 sea de alerta.

Otros comandos de monitorizado, co­ mo los de HTTP o SSH, no poseen niveles de advertencia, quedando la definición de su control como: define service{ use local-service host_name servidor1 service_description HTTP check_command check_http }

que solo informa de si están o no activos. Similares líneas las podemos utilizar para el resto de comandos, cuya sintaxis podemos ver en el archivo commands. cfg.

Con cada cambio realizado, para acti­ varlo necesitamos ejecutar dos coman­ dos. Primero:

$ /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc /nagios.cfg

para comprobar la configuración, indicán­ donos los errores que encuentre.

Si el resultado de este es satisfactorio, mostrará los mensajes:

Total Warnings: 0 Total Errors: 0 reiniciamos el servicio:

# /etc/init.d/nagios restart

INTERFAZ WEB

Para acceder a la interfaz web de Nagios, abrimos un navegador e introducimos en la barra de URL la dirección:

http://localhost/nagios

se nos pedirá el usuario y su clave que creamos al principio con el comando

htpasswd.

Desde el menú situado en la parte iz­ quierda de la página accedemos a las di­ ferentes estadísticas generadas por Nagios, así como a su estado actual.

Los enlaces más importantes por la in­ formación que ofrecen, son los siguientes:  Tactical overview: un completo resu­

men de todos los servicios y equipos en el momento actual. informando de los alertas críticas y advertencias, caídas y de aquellos elementos que no tengan problemas. Su principal utilidad es ver en pocos segundos el estado completo de los elementos monitorizados, incluyendo una sección de título Network Health con dos barras para indicar su salud comple­ ta con colores –verde todo correcto–, –amarillo– con problemas, o rojo para alertas. Todos los textos de información son enlaces a través de los cuales pode­ mos acceder rápidamente a una infor­ mación más completa.

 service Detail y Host Detail: respec­ tivamente son los listados de servicios y equipos monitorizados. Contienen su nombre, estado actual, fecha y hora de la última y próxima comprobación y la salida del comando de monitorización. Opciones de control de un servidor web.

Si alguno de estos nodos está en esta­ do crítico o con advertencia, presiona­ mos sobre su nombre para desplegar información más detallada.

 status Map: información sobre el es­ tado de la red con los equipos y sus servicios. Podemos ir situándonos so­ bre cada uno de sus nombres. Repre­ senta gráficamente la topología de la red, y mostrará también aquellos orde­ nadores que no estén accesibles.  service Problems y Host Problems:

todos los servicios y equipos que pre­ sentan estado de error, incluyendo en­ laces similares a los mostrados en las páginas Detail antes vistas. Las adver­ tencias definidas en los comandos se representan con color amarillo y las alertas críticas en rojo.

 Reporting: un conjunto de opciones orientadas a generar informes con el historial de disponibilidad de equipos y servicios.

Por ejemplo, si queremos obtener el histórico del equipo localhost, presiona­ mos el enlace Availability, seleccionamos

Host(s) y elegimos la opción localhost.

Finalmente, escogemos el período de fe­ chas de la disponibilidad del equipo y pre­ sionamos “Create Availability Report!” para obtener una nueva página con el detalla­ do informe.

Todos los datos de estas páginas, así como los nombres de los elementos, son tomados a partir de los archivos de confi­ guración antes explicados.

AÑADIENDO COMPLEMENTOS

La instalación realizada de Nagios solo está limitada por el hecho de que no es posible monitorizar equipos remotos, también por algunos servicios no soportados y porque el número de dispositivos es reducido. Pero gracias a la APi provista con la propia aplicación es posible añadir nuevos contro­ les. De hecho podemos encontrar un gran número de ellos ya desarrollados por otros usuarios en la página http://www.nagio-sexchange.org. Los controles están clasifi­ cados según su cometido, como redes, hardware, software o sistemas operativos.

Por ejemplo, para instalar el comando de monitorizado TFTP descargamos su archivo PL, que copiamos al directorio

/usr/local/nagios/libexec.

A continuación, añadimos al archivo

commands.cfg el nuevo comando: define command{ command_name check_tftp command_line $USER1$/check_tftp.pl $HOSTADDRESS$ directorio/archivo }

reemplazando directorio/archivo por la ru­ ta al fichero con el que monitorizar el envío por TFTP.

Para añadir este control a un equipo, insertamos en su archivo de configuración correspondiente las líneas:

define service{ use local-service host_name servidor2 service_description TFTP check_command check_tftp }

siendo servidor2 el equipo que vamos a monitorizar, que está definido en otro ar­ chivo de configuración como hemos visto antes. n

Resumen de los elementos monitorizados.

Informe histórico del estado del servidor web.