FACULTAD DE INFORMATICA

Asignatura: Gestin de Redes o

(Aint Gonna Insist On Sainthood)

A Corua, 3 de julio de 2012 n

Autor: Jorge L pez Fern ndez o a Login: infjlf02 E-mail de contacto: lopez.fernandez.jorge@gmail.com

En este documento se aborda un resumen de las principales caracter sticas y otros aspectos relevantes del sistema Nagios, una de las aplicaciones para monitorizacin de redes ms populares gracias a sus mltiples opciones, como a u patibilidad con los principales SOs y a su cualidad de software libre. En el cuerpo del documento se explican las caracter sticas de Nagios, su instalacin y su manejo ms elemental. En los anexos se explican algunos apartados o a avanzados que pueden resultar de inters, aunque existen much e simos ms, como a monitorizacin distribuida, monitorizacin redundante, rotaciones de noticacioo o nes, servicios voltiles, etc. a

 Indice general
Indice general Indice de tablas Indice de guras 1. Introduccin o 1.1. Qu es Nagios? . . . . . . . . . . . . . . . . . . . . . . . . . . e 1.2. Qu puede hacer Nagios? . . . . . . . . . . . . . . . . . . . . . e 1.3. Por qu usar Nagios? . . . . . . . . . . . . . . . . . . . . . . . e 2. Puesta a punto 2.1. Instalacin . . . . . . . . . . . . . . . . . . . . . . . . . o 2.1.1. Prerrequisitos . . . . . . . . . . . . . . . . . . . 2.1.2. Creacin de las cuentas . . . . . . . . . . . . . . o 2.1.3. Compilacin e instalacin de Nagios . . . . . . . o o 2.1.4. Personalizacin de los archivos de conguracin . o o 2.1.5. Conguracin de la interfaz web . . . . . . . . . . o 2.1.6. Compilacin e instalacin de los plugins de Nagios o o 2.1.7. Iniciando Nagios . . . . . . . . . . . . . . . . . . 2.1.8. Modicar la conguracin de SELinux (Fedora) . o 2.1.9. Entrando en la interfaz web . . . . . . . . . . . . 2.1.10. Otras modicaciones . . . . . . . . . . . . . . . . 2.2. Conguracin . . . . . . . . . . . . . . . . . . . . . . . o 2.2.1. Fichero de conguracin principal . . . . . . . . . o 2.2.2. Fichero(s) de recursos . . . . . . . . . . . . . . . 2.2.3. Ficheros de denicin de objetos . . . . . . . . . o 2.2.4. Fichero de conguracin de CGIs . . . . . . . . . o 2.2.5. Autenticacin y autorizacin . . . . . . . . . . . . o o 2.2.6. Congurando Apache . . . . . . . . . . . . . . . i
I

VII

1 1 1 2 5 5 5 6 7 7 7 8 8 9 9 9 10 10 12 12 14 15 17

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

ii

INDICE GENERAL 19 19 19 20 21 22 23 23 23 24 24 25 25 26 26 26 26 27 27 27 27 28 28 29 29 30 30 31 32 32 33 33 33 34 35 36 36 36 37

3. Manejo bsico a 3.1. Vericacin de la conguracin . . . . . . . . . . . . . . . . . . o o 3.2. Lanzando y parando Nagios . . . . . . . . . . . . . . . . . . . . 3.3. Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5. Tests de hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1. Cachs de chequeo de hosts . . . . . . . . . . . . . . . . e 3.5.2. Dependencias entre tests . . . . . . . . . . . . . . . . . 3.5.3. Paralelizacin de tests de hosts . . . . . . . . . . . . . . o 3.5.4. Estados de los hosts . . . . . . . . . . . . . . . . . . . . 3.5.5. Determinacin del estado de los hosts . . . . . . . . . . . o 3.5.6. Cambios de estado en hosts . . . . . . . . . . . . . . . . 3.6. Tests de servicios . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6.1. Cachs de chequeo de servicios . . . . . . . . . . . . . . e 3.6.2. Dependencias entre tests . . . . . . . . . . . . . . . . . 3.6.3. Paralelizacin de tests de servicios . . . . . . . . . . . . . o 3.6.4. Estados de los servicios . . . . . . . . . . . . . . . . . . 3.6.5. Determinacin del estado de los servicios . . . . . . . . . o 3.6.6. Cambios de estado en servicios . . . . . . . . . . . . . . 3.7. Tests activos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.1. Realizacin de los tests activos . . . . . . . . . . . . . . o 3.7.2. Cundo se ejecutan los tests activos . . . . . . . . . . . . a 3.8. Tests pasivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.8.1. Usos de los tests pasivos . . . . . . . . . . . . . . . . . . 3.8.2. Funcionamiento de los tests pasivos . . . . . . . . . . . . 3.8.3. Permitiendo tests pasivos . . . . . . . . . . . . . . . . . 3.8.4. Enviando los resultados de los tests de servicios pasivos . 3.8.5. Enviando los resultados de los tests de hosts pasivos . . . 3.8.6. Tests pasivos y estados de hosts . . . . . . . . . . . . . . 3.8.7. Enviando resultados de tests pasivos desde hosts remotos 3.9. Tipos de estados . . . . . . . . . . . . . . . . . . . . . . . . . . 3.9.1. Reintentos de tests de servicios y hosts . . . . . . . . . . 3.9.2. Estados SOFT . . . . . . . . . . . . . . . . . . . . . . . 3.9.3. Estados HARD . . . . . . . . . . . . . . . . . . . . . . . 3.9.4. Ejemplo de transiciones de estados . . . . . . . . . . . . 3.10. Per odos de tiempo . . . . . . . . . . . . . . . . . . . . . . . . 3.10.1. Precedencia en per odos de tiempo . . . . . . . . . . . . 3.10.2. Cmo funcionan los per o odos de tiempo con los tests de servicios y hosts . . . . . . . . . . . . . . . . . . . . . . 3.10.3. Cmo funcionan los per o odos de tiempo con noticaciones

 INDICE GENERAL

iii

3.10.4. Cmo funcionan los per o odos de tiempo con la intensicacin de noticaciones . . . . . . . . . . . . . . . . . o 3.10.5. Cmo funcionan los per o odos de tiempo con las dependencias . . . . . . . . . . . . . . . . . . . . . . . . . . 3.11. Determinando el estado y accesibilidad de los hosts . . . . . . . 3.11.1. Red de ejemplo . . . . . . . . . . . . . . . . . . . . . 3.11.2. Deniendo las relaciones padre/hijo . . . . . . . . . . . 3.11.3. Lgica de accesibilidad en accin . . . . . . . . . . . . o o 3.11.4. Estado UNREACHABLE y noticaciones . . . . . . . . . . 3.12. Noticaciones . . . . . . . . . . . . . . . . . . . . . . . . . . 3.12.1. Cundo ocurren las noticaciones? . . . . . . . . . . . a 3.12.2. A quin se notica? . . . . . . . . . . . . . . . . . . . e 3.12.3. Qu ltros deben pasar las noticaciones antes de llegar e a su destino? . . . . . . . . . . . . . . . . . . . . . . . 3.12.4. Mtodos de noticacin . . . . . . . . . . . . . . . . . e o 3.12.5. Macro de tipos de noticaciones . . . . . . . . . . . . . 3.13. Interfaces de usuario . . . . . . . . . . . . . . . . . . . . . . . 3.13.1. Interfaz de estado . . . . . . . . . . . . . . . . . . . . 3.13.2. Interfaz de mapa de estado . . . . . . . . . . . . . . . 3.13.3. Interfaz WAP . . . . . . . . . . . . . . . . . . . . . . 3.13.4. Interfaz mundo de estados . . . . . . . . . . . . . . . . 3.13.5. Interfaz de vista tctica . . . . . . . . . . . . . . . . . a 3.13.6. Interfaz de fallos de red . . . . . . . . . . . . . . . . . 3.13.7. Interfaz de conguracin . . . . . . . . . . . . . . . . . o 3.13.8. Interfaz de comandos . . . . . . . . . . . . . . . . . . 3.13.9. Interfaz de informacin extendida . . . . . . . . . . . . o 3.13.10.Interfaz de log de eventos . . . . . . . . . . . . . . . . 3.13.11.Interfaz de histrico de alertas . . . . . . . . . . . . . . o 3.13.12.Interfaz de noticaciones . . . . . . . . . . . . . . . . 3.13.13.Interfaz de tendencias . . . . . . . . . . . . . . . . . . 3.13.14.Interfaz de informes de disponibilidad . . . . . . . . . . 3.13.15.Interfaz de histograma de alertas . . . . . . . . . . . . 3.13.16.Interfaz de resumen de alertas . . . . . . . . . . . . . . 4. Conclusiones

. 37 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 38 38 39 39 41 41 41 41 42 44 44 45 45 46 47 48 48 49 50 50 51 52 52 53 54 55 55 56 59

A. Implementacin de cachs de chequeo o e 61 A.1. Slo tests bajo demanda . . . . . . . . . . . . . . . . . . . . . . 61 o A.2. Funcionamiento de la cach . . . . . . . . . . . . . . . . . . . . 62 e

iv

INDICE GENERAL

B. Traduccin de estados de tests pasivos de hosts o 63 B.1. Diferentes puntos de vista . . . . . . . . . . . . . . . . . . . . . 63 B.2. Permitiendo la traduccin de estados . . . . . . . . . . . . . . . 64 o C. Manejadores de eventos C.1. Cundo se ejecutan los manejadores de eventos? a C.2. Tipos de manejadores de eventos . . . . . . . . . C.3. Activando los manejadores de eventos . . . . . . . C.4. Orden de ejecucin de los manejadores de eventos o C.5. Escribiendo comandos manejadores de eventos . . C.6. Permisos de los comandos manejadores de eventos Bibliograf a 65 65 66 66 66 67 67 69

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

 Indice de tablas
2.1. Permisos otorgados por Nagios por defecto . . . . . . . . . . . . 16 3.1. 3.2. 3.3. 3.4. Traduccin de los estados de los plugins . . . . . . . o Resolucin del estado preliminar DOWN . . . . . . . . o Ejemplo de determinacin de estados . . . . . . . . o Posibles valores de la macro $NOTIFICATIONTYPE$ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 25 35 45

 Indice de guras
1.1. Sencilla red de ejemplo para Nagios . . . . . . . . . . . . . . . . 3

2.1. Dependencias entre los cheros de conguracin de Nagios . . . 10 o 2.2. Los servicios como objetos en Nagios . . . . . . . . . . . . . . . 13 2.3. Los hosts en jerarqu como objetos en Nagios . . . . . . . . . . 14 a 3.1. Opciones del proceso en la interfaz web . . . . . . . . . . . . . 3.2. Utilizacin de los plugins en Nagios . . . . . . . . . . . . . . . o 3.3. Ejecucin de los tests activos desde el daemon . . . . . . . . . o 3.4. Funcionamiento de los tests pasivos de manera externa a Nagios 3.5. Funcionamiento del addon NSCA . . . . . . . . . . . . . . . . 3.6. Red de ejemplo para la determinacin de accesibilidad de hosts o 3.7. Relaciones padre/hijo en la red de ejemplo . . . . . . . . . . . 3.8. Escenario problemtico en la red de ejemplo . . . . . . . . . . a 3.9. Estados que ha determinado Nagios . . . . . . . . . . . . . . . 3.10. Ejemplo de la interfaz de estado . . . . . . . . . . . . . . . . . 3.11. Ejemplo de la interfaz de mapa de estado . . . . . . . . . . . . 3.12. Ejemplo de la interfaz WAP . . . . . . . . . . . . . . . . . . . 3.13. Ejemplo de la interfaz mundo de estados . . . . . . . . . . . . 3.14. Ejemplo de la interfaz de vista tctica . . . . . . . . . . . . . . a 3.15. Ejemplo de la interfaz de fallos de red . . . . . . . . . . . . . . 3.16. Ejemplo de la interfaz de conguracin . . . . . . . . . . . . . o 3.17. Ejemplo de la interfaz de comandos . . . . . . . . . . . . . . . 3.18. Ejemplo de la interfaz de informacin extendida . . . . . . . . o 3.19. Ejemplo de la interfaz de log de eventos . . . . . . . . . . . . 3.20. Ejemplo de la interfaz de histrico de alertas . . . . . . . . . . o 3.21. Ejemplo de la interfaz de noticaciones . . . . . . . . . . . . . 3.22. Ejemplo de la interfaz de tendencias . . . . . . . . . . . . . . . 3.23. Ejemplo de la interfaz de informes de disponibilidad . . . . . . 3.24. Ejemplo de la interfaz de histograma de alertas . . . . . . . . . 3.25. Ejemplo de la interfaz de resumen de alertas . . . . . . . . . . vii . . . . . . . . . . . . . . . . . . . . . . . . . 20 21 28 30 32 38 39 40 40 46 46 47 48 49 49 50 50 51 52 53 53 54 55 55 56

viii

INDICE DE FIGURAS

A.1. Funcionamiento bsico del cacheo de tests . . . . . . . . . . . . 62 a B.1. Esquema de un sistema de monitorizacin redundante . . . . . . 63 o

Cap tulo 1 Introduccin o

1.1. Qu es Nagios? e

Debido a la gran complejidad de las redes empleadas hoy en d incluso a, las pertenecientes a PYMEs, el uso de aplicaciones de monitorizacin es algo o indispensable. Como otras tantas aplicaciones, con ese objetivo naci Nagios. o A grandes rasgos, Nagios es una aplicacin de monitorizacin de redes, es o o decir, nos permite comprobar el estado de los hosts y servicios que le especicamos, avisndonos cuando su situacin empeora y tambin en los momentos en a o e que mejora. Diseada por Ethan Galstad inicialmente para Linux, es compatible n con cualquier sistema Unix. Como una simple ancdota, podemos explicar el signicado del acrnimo e o de Nagios: en un principio la aplicacin se llamaba NetSaint, pero, debido a o una amenaza de demanda de los dueos de una marca registrada similar, se n decidi cambiar el nombre por el acrnimo recursivo Nagios Aint Gonna Insist o o On Sainthood. La palabra Nagios proviene concretamente de la unin de las o palabras Network y Hagios (o Agios), la cual signica santo en griego.

1.2.

Qu puede hacer Nagios? e

Entre sus mltiples caracter u sticas podemos destacar las siguientes: Monitorizacin de servicios de red (SMTP, POP3, HTTP, NNTP, PING, o etc.). Monitorizacin se recursos en los hosts (carga del procesador, uso del disco, o etc.). 1

1. Introduccin o

Diseo de plugins sencillo que permite a los usuarios preparar sus propios n tests de servicios. Tests de servicios en paralelo. Capacidad de denir jerarqu de hosts en la red con hosts padre, permias tiendo deteccin y distincin de hosts ca o o dos e inalcanzables. Opcin de enviar noticaciones a los contactos cuando ocurre o se soluciona o un problema en un servicio o host (mediante e-mail, mensaje en un terminal o mtodo denido por el usuario). e Posibilidad de denir manejadores de eventos para ser lanzados cuando suceden problemas de servicios o hosts a n de solucionarlos de manera proactiva. Rotacin automtica de logs. o a Soporte para la implementacin de monitorizacin redundante de hosts. o o Interfaz web opcional para visualizar el estado actual de la red, noticacin o e histrico de problemas, cheros de log, etc. o

1.3.

Por qu usar Nagios? e

Aunque existen alternativas a Nagios bastante populares y ecaces como Big Brother, OpenNMS, OpenView o SysMon, Nagios es una de las mejores aplicaciones de monitorizacin existentes, destacando entre sus puntos fuertes: o Aplicacin de cdigo abierto. o o Robusto y able. Altas capacidades de conguracin. o Fcilmente extensible. a Su equipo de desarrollo sigue activo. Cuenta con una comunidad de usuarios extensa y activa. Funciona en muchos SOs.

1.3. Por qu usar Nagios? e

Un ejemplo de red a monitorizar con Nagios ser el que se puede ver en la a figura 1.1, la cual dispone de un servidor en el cual Nagios estar corriendo a como un daemon o servicio. Peridicamente lanza plugins residentes en el mismo o servidor (lo habitual), los cuales contactan (e.g., por PING) con los hosts y otros servidores de la red o de internet. Tambin es posible que se env directamente e e informacin a Nagios. Entonces se podr comprobar el estado de la red mediante o a la interfaz web. Adems se puede congurar para que env noticaciones por a e e-mail o SMS si algo sucede, y los manejadores de eventos pueden ser congurados para realizar alguna accin en esos momentos. o

Figura 1.1: sencilla red de ejemplo para Nagios

Cap tulo 2 Puesta a punto

Ahora, antes de adentrarnos en su funcionamiento y capacidades, abordaremos cmo conseguir que Nagios funcione en nuestro sistema. o

2.1.

Instalacin o

Nagios, en su ultima versin, est preparado para una instalacin sencilla en o a o los siguientes sistemas operativos: Fedora Core openSUSE Ubuntu

2.1.1.

Prerrequisitos

Antes de instalarlo en cualquiera de estas distribuciones necesitamos disponer de unos paquetes por las dependencias existentes, los cuales variarn segn el a u sistema operativo. Fedora Core (versin 6): o Apache Compilador de GCC Librer de desarrollo de GD as openSUSE (versin 10.2): o apache 2 5

2. Puesta a punto

Librer de desarrollo de C/C++ as Ubuntu (versin 7.10): o Apache 2 Compilador y librer de desarrollo de GCC as Librer de desarrollo de GD as

2.1.2.

Creacin de las cuentas o

A n de funcionar correctamente en el sistema, Nagios necesita una cuenta propia para sus procesos, crendose del siguiente modo: a Fedora Core (versin 6): o 1. Nos autenticamos como usuario root . 2. Creamos una nueva cuenta nagios y le asignamos un password. 3. Creamos un nuevo grupo nagcmd para permitir que los comandos externos puedan ser enviados a travs de la interfaz web. e 4. Aadimos a los usuarios nagios y apache a ese grupo. n openSUSE (versin 10.2): o 1. Nos autenticamos como usuario root . 2. Creamos una nueva cuenta nagios y le asignamos un password. 3. Creamos un nuevo grupo nagios. 4. Aadimos al usuario nagios a ese grupo. n 5. Creamos un nuevo grupo nagcmd para permitir que los comandos externos puedan ser enviados a travs de la interfaz web. e 6. Aadimos a los usuarios nagios y apache a ese grupo. n Ubuntu (versin 7.10): o 1. Nos autenticamos como usuario root . 2. Creamos una nueva cuenta nagios y le asignamos un password. 3. Creamos un nuevo grupo nagios (este paso lo podemos omitir en versiones desktop de Ubuntu). 4. Aadimos al usuario nagios a ese grupo (este paso lo podemos n omitir en versiones desktop de Ubuntu).

2.1. Instalacin o

5. Creamos un nuevo grupo nagcmd para permitir que los comandos externos puedan ser enviados a travs de la interfaz web. e 6. Aadimos a los usuarios nagios y apache a ese grupo. n

2.1.3.

Compilacin e instalacin de Nagios o o

Tras descargar Nagios y sus plugins, los extraemos de sus archivos comprimidos, nos situamos en la carpeta de Nagios y ejecutamos el script de conguracin o indicndole el nombre del grupo que creamos anteriormente: a 1. ./configure --with-command-group=nagcmd Despus compilamos e instalamos todos sus componentes: e 1. make all 2. make install 3. make install-init 4. make install-config 5. make install-commandmode

2.1.4.

Personalizacin de los archivos de conguracin o o

Los archivos de conguracin instalados deber funcionar correctamente o an para un uso sencillo de Nagios, pero necesitamos realizar un cambio: editamos el archivo /usr/local/nagios/etc/objects/contacts.cfg para indicar el e-mail asociado al contacto nagiosadmin donde queremos recibir noticaciones.

2.1.5.

Conguracin de la interfaz web o

Instalamos el chero de conguracin web de Nagios en el directorio conf.d o de Apache: 1. make install-webconf Creamos un usuario nagiosadmin para acceder a la interfaz web de Nagios. Es importante recordar el password que se le asigna. Ahora reiniciamos Apache para que los cambios surtan efecto.

2. Puesta a punto

2.1.6.

Compilacin e instalacin de los plugins de Nao o gios

Nos situamos en la carpeta de los plugins y los conguramos, compilamos e instalamos: 1. ./configure --with-nagios-user=nagios --with-nagios-group=nagios 2. make 3. make install

2.1.7.

Iniciando Nagios

Aadimos Nagios a la lista de servicios del sistema y lo conguramos para n que lo inicie automticamente al iniciarse: a Fedora Core (versin 6): o 1. chkconfig --add nagios 2. chkconfig nagios on openSUSE (versin 10.2): o 1. chkconfig --add nagios 2. chkconfig nagios on Ubuntu (versin 7.10): o 1. ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios A continuacin vericamos los cheros de conguracin por defecto de Nao o gios: 1. /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg Si no hay errores, lanzamos Nagios: Fedora Core (versin 6): o 1. service nagios start

2.1. Instalacin o

openSUSE (versin 10.2): o 1. service nagios start Ubuntu (versin 7.10): o 1. /etc/init.d/nagios start

2.1.8.

Modicar la conguracin de SELinux (Fedora) o

Fedora viene con SELinux (Security Enhanced Linux) instalado y con el modo Enforcing por defecto. Esto puede causar mensajes Error interno del servidor cuando se intenta acceder a las interfaces de Nagios. Comprobamos si SELinux est en modo Enforcing. a 1. getenforce En caso de que lo est, lo ponemos en modo Permissive. e 1. setenforce 0 Para hacer permanente este cambio, hay que modicar la conguracin en o /etc/selinux/config y reiniciar.

2.1.9.

Entrando en la interfaz web

Ahora ya se deber poder acceder a la interfaz web de Nagios con la direccin a o http://localhost/nagios/. Se nos pedir el nombre de usuario (nagiosadmin ) a y el password que se especic anteriormente. o Hacemos click en el enlace a Service Details para comprobar qu servicios e est monitorizando Nagios en nuestro sistema. a

2.1.10.

Otras modicaciones

En caso de querer usar la interfaz web de manera remota, deberemos congurar correctamente nuestro rewall para que no bloquee las peticiones a la mquina. a En Ubuntu es necesario instalar el paquete mailx para poder recibir por e-mail las alertas de Nagios. Despus deberemos editar el comando de e noticaciones por e-mail de Nagios que se encuentra en /usr/local/nagios/etc/objects/commands.cfg y sustituir las referencias a /bin/mail por /usr/bin/mail. Necesitaremos reiniciar Nagios para que los cambios surtan efecto.

10

2. Puesta a punto

2.2.

Conguracin o

Para lograr que Nagios funcione de manera correcta, deberemos preparar adecuadamente una serie de cheros de coguracin1 . o

Figura 2.1: dependencias entre los cheros de conguracin de Nagios o

2.2.1.

Fichero de conguracin principal o

Este chero contiene un buen nmero de directivas que afectan al funciou namiento del daemon de Nagios. Es le tanto por el daemon como por las do interfaces CGI.

Localizacin o Este chero se llama habitualmente nagios.cfg y se encuentra en el directorio /usr/local/nagios/etc/.

Nagios instala por defecto cheros de conguracin de ejemplo en o /usr/local/nagios/etc/, los cuales deber an valer durante el proceso de instalacin descrito anteriormente para comprobar que todo fue sin problemas, pero no para un o funcionamiento ecaz.
1

2.2. Conguracin o

11

Variables de chero Este chero contiene un gran nmero de opciones de conguracin, todas u o con el formato opcin = valor, de las cuales indicaremos unas cuantas2 como o ejemplo: Fichero de log (log file): indica dnde se crear el chero de log de o a Nagios. Fichero conguracin de objetos (cfg file): sirve para sealar los o n cheros con las deniciones que Nagios emplear para monitorizar esos a elementos. Fichero de estado (status file): chero que emplear Nagios para a almacenar el estado actual de la red y otros aspectos. Fichero de retencin de estado (state retention file): chero que o emplear Nagios para almacenar el estado de la red y otros aspectos antes a de cerrarse, para as recuperar este estado cuando se vuelva a iniciar. Timeout para tests de servicios (service check timeout): nmero u mximo de segundos que Nagios contempla para la ejecucin de los tests a o de los servicios; si se exceden, los tests son detenidos y se devuelve estado cr tico. Timeout para tests de hosts (host check timeout): nmero mximo u a de segundos que Nagios contempla para la ejecucin de los tests de las o mquinas cliente; si se exceden, los tests son detenidas, se asume que la a mquina est ca y se devuelve estado cr a a da tico. Comando obsesivo-compulsivo para procesamiento de servicios (ocsp command): permite la ejecucin de un comando despus de todos los o e tests de servicio, siendo especialmente util en monitorizacin distribuida; o se le indica el nombre de una denicin de comando incluida en el chero o de conguracin de objetos. o Opcin de procesamiento de informacin de rendimiento (processo o performance data): le indica a Nagios si debe o no (1/0) procesar la informacin de rendimiento de hosts y servicios. o Comando para procesamiento de informacin de rendimiento de o hosts (host perfdata command): permite la ejecucin de un comando o
2

El resto pueden consultarse en la documentacin ocial de Nagios [1]. o

12

2. Puesta a punto

despus de todos los tests de rendimiento de hosts; se le indica el nombre e de una denicin de comando incluida en el chero de conguracin de o o objetos. Comando para procesamiento de informacin de rendimiento de o servicios (service perfdata command): permite la ejecucin de un coo mando despus de todos los tests de rendimiento de servicios; se le indica e el nombre de una denicin de comando incluida en el chero de conguo racin de objetos. o Formato de fecha (date format): permite cambiar el formato que utilizar Nagios en la interfaz web y las macros; tiene una serie de opcioa nes prejadas, como la fecha en formato estadounidense (us) o europeo (euro). Caracteres ilegales para el nombrado de los objetos (illegalobject name chars): especica una serie de caracteres que no se podrn a emplear dentro de los nombres de los objetos; se recomienda incluir al menos los siguientes: !$ %^&*"|<>?,()= . Direccin de e-mail del administrador (admin email): permite espeo cicar una direccin de correo para el administrador de la mquina local, o a a la cual se podrn enviar noticaciones. a Nivel de debug (debug level): indica qu cantidad de informacin debe e o escribir Nagios en el chero de debug.

2.2.2.

Fichero(s) de recursos

Permiten almacenar macros denidas por el usuario. Su principal uso es el almacenamiento de informacin de conguracin condencial (como passwords), o o hacindola inaccesible a las CGIs. En la variable correspondiente del chero de e conguracin principal se indican estos cheros. o

2.2.3.

Ficheros de denicin de objetos o

Permiten denir hosts, comandos, servicios, grupos de hosts, contactos, etc. Es decir, contiene todo lo que se va a monitorizar, y el modo de hacerlo. En la variable correspondiente del chero de conguracin principal se indican estos o cheros (o un directorio que los contiene).

2.2. Conguracin o

13

Qu son los objetos? e Como ya indicamos anteriormente, los objetos denen los elementos a monitorizar por Nagios, e incluyen ciertas caracter sticas que indican cmo hacerlo o (sealaremos algunas esenciales de ciertos objetos3 ). Los objetos denibles son: n Servicios: uno de los objetos centrales en la lgica de monitorizacin. Los o o servicios se asocian con hosts y pueden ser: 1. Atributos de un host (CPU, carga uso de disco, etc.). 2. Servicios proporcionados por el host (HTTP, POP3, FTP, etc.). 3. Otros aspectos relacionados con el host (DNS, registros, etc.).

Figura 2.2: los servicios como objetos en Nagios

Grupos de servicios: son grupos de uno o ms servicios. Facilitan la a consulta del estado de sus servicios en la interfaz web y simplican la conguracin con ciertos trucos de los objetos. o Hosts: otro de los objetos centrales para la monitorizacin. Algunos de sus o atributos son: Tipo de dispositivo (servidor, impresora, router, etc.). Direccin (IP, MAC, etc.). o Servicios asociados. Otros hosts padre/hijo (empleado para la lgica de accesibilidad). o Grupos de hosts: son grupos de uno o ms hosts. Al igual que los grupos a de servicios, facilitan la consulta del estado de sus hosts en la interfaz web y simplican la conguracin con ciertos trucos de los objetos. o
3

De nuevo, el resto pueden consultarse en la documentacin ocial de Nagios [1]. o

14

2. Puesta a punto

Figura 2.3: los hosts en jerarqu como objetos en Nagios a

Contactos: gente involucrada en el proceso de noticacin. Cada uno tiene o uno o ms mtodos de noticacin, y reciben noticaciones por hosts y a e o procesos de los que son responsables. Grupos de contactos: son grupos de uno o ms contactos. Facilitan la a conguracin de las noticaciones. o Comandos: sirven para indicarle a Nagios programas, scripts, etc. a ejecutar. Per odos de tiempo: se emplean para controlar los per odos de monitorizacin y el env de noticaciones. o o Crecimiento de las noticaciones. Dependencias de noticaciones y ejecuciones.

2.2.4.

Fichero de conguracin de CGIs o

Contiene directivas que afectan al funcionamiento de los CGIs. Adems ina cluye una referencia al chero de conguracin principal, de modo que los CGIs o saben cmo est congurado Nagios y dnde se encuentran los cheros de deo a o nicin de los objetos. o Localizacin o Este chero por defecto se llama cgi.cfg y se encuentra en el directorio /usr/local/nagios/etc/. Es posible cambiar ambos valores mediante variables de entorno de Apache.

2.2. Conguracin o

15

Variables de chero Este chero contiene un gran nmero de opciones de conguracin, todas u o con el formato opcin = valor, de las cuales indicaremos unas cuantas4 como o ejemplo: Fichero de conguracin principal (main config file): especica la o ruta completa del chero de conguracin principal. o Path f sico para HTML (physical html path): especica la ruta donde se guardarn los cheros HTML de Nagios. a URL para HTML (url html path): la porcin de URL empleada para o acceder a la interfaz web de Nagios. Uso de autenticacin (use authentication): indica a las CGIs si deo ben emplear o no (1/0) la funcionalidad de autenticacin y autorizacin o o en los usuarios que intentan acceder. Alertas por audio (* * sound): permiten especicar archivos de sonido para reproducir con el navegador cuando se encuentren problemas al visualizar la interfaz de estado. Sintaxis de Ping (ping syntax): especica un comando a ejecutar al intentar realizar ping a un host desde la interfaz WAP. Se debe especicar la ruta completa del comando, con todos sus parmetros. a

2.2.5.

Autenticacin y autorizacin o o

Como ya se seal en apartados anteriores, Nagios proporciona la funcionalin o dad de restringir el acceso a la informacin de la red y su conguracin mediante o o la autenticacin de los usuarios. o Deniciones Nagios distingue dos categor globales para la autenticacin: as o Usuarios autenticados: son aqullos autenticados contra el servidor mee diante un nombre de usuario y una contrasea, y al que se la proporcionado n acceso a la interfaz web de Nagios. Contactos autenticados: es un usuario autenticado cuyo nombre de usuario coincide con el de un contacto.
4

De nuevo, el resto pueden consultarse en la documentacin ocial de Nagios [1]. o

16

2. Puesta a punto

Preparando la autenticacin y autorizacin o o En primer lugar deberemos denir los contactos y usuarios en los cheros de conguracin previamente explicados, recordando que los contactos deber o an coincidir con un nombre de usuario si queremos otorgarle facilidades para consultar informacin sobre la red. o A continuacin se congurarn los CGIs para emplear estas opciones, como o a se vio en la seccin anterior, simplemente cambiando el valor de un parmetro. o a Permisos por defecto Cuando activamos la opcin de autenticacin y autorizacin, los permisos o o o que se otorgan por defecto son los siguientes:
Contactos autenticados Otros usuarios autenticados

Datos del CGI Informacin de estado de o host Informacin de o conguracin de host o Histrico del host o Noticaciones del host Comandos del host Informacin de estado de o servicio Informacin de o conguracin de servicio o Histrico del servicio o Noticaciones del servicio Comandos del servicio Informacin de todas las o conguraciones Informacin de o proceso/sistema Comandos de proceso/sistema

Tabla 2.1: permisos otorgados por Nagios por defecto

Conviene resaltar que los permisos se aplican a aquellos servicios y hosts de los cuales los usuarios son contactos, y en el caso de los hosts se extiende tambin e a todos sus servicios de manera idntica. e

2.2. Conguracin o

17

Podemos comprobar que por defecto nadie tiene permisos para las siguientes acciones: Consultar el chero base de log a travs de la interfaz. e Comprobar la informacin de procesos de Nagios a travs de la interfaz de o e informacin extendida. o Introducir comandos de proceso de Nagios a travs de la interfaz de coe mandos. Consultar grupos de hosts, contactos, grupos de contactos, franja horaria y deniciones de comandos con la interfaz de conguracin. o Evidentemente, alguien querr acceder a estos datos, por lo que Nagios pera mite autorizar su consulta a travs de variables del chero de conguracin de e o 5 CGIs . Autenticacin en servidores web seguros o Si se dispone de un servidor en un dominio seguro (e. g., tras un rewall), o si se emplea SSL, se puede denir un nombre de usuario por defecto para acceder a las interfaces. A travs de la opcin default user name en el chero de e o conguracin de CGIs podemos permitir que los usuarios accedan a las interfaces o sin tener necesariamente que autenticarse en el servidor. Evidentemente, esta opcin slo se debe emplear en entornos seguros. o o

2.2.6.

Congurando Apache

Para que Apache conozca la existencia de Nagios es necesario hacer unos cambios en sus archivos. Aqu indicaremos el modo habitual de resolverlo en Linux. En el archivo httpd.conf debemos aadir la siguiente l n nea, cambindola a segn el SO y la versin de Apache: u o # ee /usr/local/etc/apache2/httpd.conf

De nuevo, en la documentacin ocial de Nagios [1] se pueden consultar todas las o variables que nos lo permiten.

18

2. Puesta a punto

Despus copiamos en l el siguiente texto: e e ScriptAlias /nagios/cgi-bin /usr/local/share/nagios/cgi-bin <Directory "/usr/local/share/nagios/cgi-bin"> AllowOverride AuthConfig Options ExecCGI Order allow,deny Allow from all </Directory> Alias /nagios /usr/local/share/nagios <Directory "/usr/local/share/nagios"> Options None AllowOverride AuthConfig Order allow,deny Allow from all </Directory>

Con estos cambios ya deber amos poder acceder a Nagios en nuestro servidor para comprobar su correcto funcionamiento.

Cap tulo 3 Manejo bsico a

En este cap tulo explicaremos los aspectos de Nagios que nos permiten utilizarlo para efectuar una monitorizacin bsica. o a

3.1.

Vericacin de la conguracin o o

Antes de nada es conveniente vericar que los cheros de modicacin no o incumplen su estructura antes de lanzar Nagios (debe hacerse tambin siempre e que se modiquen los cheros, para asegurarse). Para comprobarlo ejecutamos con la opcin -v, de esta manera: o /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg En caso de haber olvidado algn dato crucial, o no estar correctamente indiu cados, Nagios nos indicar el primer error detectado y su localizacin. Tambin a o e es habitual que lance Warnings, pero se pueden obviar, ya que en su mayor a son recomendaciones y no requerimientos.

3.2.

Lanzando y parando Nagios

Existen diversas maneras de lanzar, parar y reiniciar Nagios. Algunas de las ms comunes son: a Iniciando Nagios 1. Mediante script: el modo ms sencillo de lanzarlo es mediante el script a de init, del siguiente modo: /etc/rc.d/init.d/nagios start 19

20

3. Manejo bsico a

2. Manualmente: podemos lanzarlo por l nea de comando con la opcin o -d y el chero de conguracin: /usr/local/nagios/bin/nagios o -d /usr/local/nagios/etc/nagios.cfg Reiniciando Nagios 1. Mediante script: el modo ms sencillo de reiniciarlo es mediante a el script de init, del siguiente modo: /etc/rc.d/init.d/nagios reload 2. Manualmente: podemos reiniciarlo por l nea de comando envindole a una seal SIGHUP al proceso: kill -HUP <nagios pid> n 3. Con la interfaz web: se puede reiniciar en el link Informacin de o proceso, seleccionandoReiniciar el proceso de Nagios. Parando Nagios 1. Mediante script: el modo ms sencillo de pararlo es mediante el script a de init, del siguiente modo: /etc/rc.d/init.d/nagios stop 2. Manualmente: podemos pararlo por l nea de comando envindole una a seal SIGTERM al proceso: kill <nagios pid> n 3. Con la interfaz web: se puede parar en el link Informacin de proceo so, seleccionandoCerrar el proceso de Nagios.

Figura 3.1: opciones del proceso en la interfaz web

3.3.

Plugins

Al contrario de otras aplicaciones de monitorizacin, Nagios no incluye meo canismos internos para comprobar el estado de servicios o hosts. En su lugar, se apoya en programas externos, plugins, para realizar ese trabajo. Nagios ejecuta los plugins, los cuales sirven para conocer el estado de servicios o hosts, y con esos datos determina su estado actual, llevando a cabo las acciones necesarias (manejadores de eventos, noticaciones, etc.).

3.4. Macros

21

Figura 3.2: utilizacin de los plugins en Nagios o

Los plugins funcionan como una capa abstracta entre la lgica de monitorio zacin del daemon de Nagios y los servicios y hosts que se estn monitorizando. o a La gran ventaja de este enfoque es que se puede monitorizar cualquier elemento del que se cree un plugin para comprobarlo, y actualmente ya existen numerosos plugins para monitorizar cuotas de disco, carga del procesador, tiempos de ping, etc. La desventaja es que Nagios no conoce el tipo de dispositivo que est monia torizando, por lo que trata igual los datos recogidos del trco de una red, carga a del procesador o el programa que utiliza actualmente tu nueva sper-lavadora. u Slo los plugins pueden saber qu estn monitorizando y de qu modo hacerlo. o e a e Existen un gran nmero de plugins1 para monitorizar servicios HTTP, POP3, u IMAP, etc. y muchos otros aspectos como carga de la CPU, cuotas de disco, etc. Podemos descargarlos de diversas, pginas, entre las que destacamos: a Nagios Plugins Project: http://nagiosplug.sourceforge.net/ Nagios Downloads Page: http://www.nagios.org/download/ NagiosExchange.org: http://www.nagiosexchange.org/

3.4.

Macros

Nagios tiene un gran nmero de macros para facilitar la denicin de nuevos u o comandos, tanto estndares como realizados bajo demanda. a
Cualquiera puede crear sus propios plugins consultando la API en la documentacin o ocial de Nagios [1].
1

22

3. Manejo bsico a

Aunque las macros se pueden usar en todos los comandos denidos por el usuario, no todas las macros se pueden emplear en un comando particular. Por ejemplo, algunas macros son vlidas slo en los comandos de noticacin, miena o o tras que otras slo se pueden emplear en los comandos de chequeo de servicios. o Existen los siguientes diez tipos de comandos que Nagios reconoce y trata de manera diferente:
1. Tests de servicios. 2. Noticaciones de servicios. 3. Tests de hosts. 4. Noticaciones de hosts. 5. Manejadores de eventos de servicios, tanto espec cos como globales. 6. Manejadores de eventos de hosts, tanto espec cos como globales. 7. Comandos OCSP (Obsessive Compulsive Service Processor). 8. Comandos OCHP (Obsessive Compulsive Host Processor). 9. Comandos de datos de rendimiento de servicios. 10. Comandos de datos de rendimiento de hosts.

En la documentacin ocial [1] podemos consultar todas las macros existentes o actualmente en Nagios, con una descripcin de cada una y los tipos de comandos o en los que es vlida. Si se emplea un macro en un comando invlido, se sustituye a a por una cadena vac a.

3.5.

Tests de hosts

El daemon de Nagios comprueba el estado de las mquinas host en los sia guientes casos: A intervalos regulares, tal y como se especic al denir las mquinas o a cliente en la denicin de objetos, apartado 2.2.3 en la pgina 12. o a Bajo demanda cuando un servicio asociado al host cambia de estado. Bajo demanda debido a la lgica de accesibilidad de las mquinas. o a Bajo demanda cuando se necesitan tests predictivos de dependencia entre hosts.

3.5. Tests de hosts

23

Los tests regulares son opcionales, por lo que si su intervalo (atributo checkinterval de su denicin) lo indicamos como 0, Nagios no realizar tests reo a gulares en la mquina, aunque seguir haciendo los que son bajo demanda ya a a que los requieren otras partes de la lgica de monitorizacin. o o Los tests cuando un servicio cambia de estado son necesarios para comprobar si la propia mquina tambin ha cambiado de estado. Cambios de estado en a e los servicios son habitualmente un buen indicador de un cambio de estado en la mquina.Por ejemplo, si Nagios detecta que el servicio HTTP de una mquina a a cambia de CRTICO a OK, puede ser un indicador de que el host se recuper de I o un reinicio y ahora ya funciona correctamente. Saber si una mquina es accesible puede ser de gran ayuda para el adminisa trador a la hora de localizar rpidamente la causa de un fallo de red, por lo que a los tests con ese n tambin son importantes. e Por ultimo, para intentar que la lgica de dependencia entre hosts sea lo ms o a precisa posible, se realizan ms tests bajo demanda. a

3.5.1.

Cachs de chequeo de hosts e

Los tests bajo demanda se pueden mejorar signicativamente si implementamos el uso de cachs para ellas, lo cual permitir a Nagios no ejecutarlas si e a determina que el resultado de otra comprobacin reciente sigue siendo vlido. En o a el anexo A en la pgina 61 se incluye un apartado sobre el uso de cachs para a e los tests bajo demanda.

3.5.2.

Dependencias entre tests

Se pueden denir dependencias de ejecuciones entre hosts que evitan que Nagios compruebe el estado de un host en funcin del estado de otro/s host/s. o

3.5.3.

Paralelizacin de tests de hosts o

Los tests peridicos de hosts son ejecutados en paralelo. Cuando Nagios o necesita realizar una comprobacin peridica, el daemon principal crear un nuevo o o a proceso que se encargar de realizarla, y volver a sus otras tareas. Cuando el a a proceso hijo termina el chequeo, informar a Nagios, su proceso padre, de los a resultados del chequeo. El proceso principal entonces interpretar los resultados a y llevar a cabo la accin apropiada. a o

24

3. Manejo bsico a

Los tests bajo demanda tambin se pueden ejecutar en paralelo si es necesario, e y, como ya se mencion, se puede hacer uso de una cach para aumentar el o e rendimiento. Cuando Nagios procesa el resultado de los tests peridicos y bajo demanda o por cambio de estado en un servicio, se comienzan los tests secundarios por dependencia y accesibilidad, los cuales normalmente se realizan en paralelo, a no e ser que el atributo max check attempts de un host est establecido como 1, lo cual provocar que sus tests se realizarn en serie. Esto nunca es recomendable, a a ya que supone una penalizacin para el rendimiento de Nagios. o

3.5.4.

Estados de los hosts

Los estados en que se pueden encontrar las mquinas tras una comprobacin a o son: UP DOWN UNREACHABLE

3.5.5.

Determinacin del estado de los hosts o

Los plugins son los encargados de realizar los tests, y pueden devolver OK, WARNING, UNKNOWN o CRITICAL. La traduccin de estados se realiza como sigue, aunque se realizan algunas o labores posteriores de procesado que se describen ms adelante. a Resultado del plugin OK WARNING UNKNOWN CRITICAL Estado preliminar del host UP UP o DOWN DOWN DOWN

Tabla 3.1: traduccin de los estados de los plugins o

El estado de WARNING signica normalmente que el host est disponible (UP), a aunque se interpreta como ca (DOWN) si la opcin use aggressive host chedo o cking est activada. a Si el estado preliminar del host es DOWN, Nagios intentar comprobar si reala mente est ca o se encuentra como inalcanzable (UNREACHABLE). Esta disa do tincin es importante ya que permite a los administradores determinar la causa o

3.6. Tests de servicios

25

de fallos en la red mucho ms rpido. Se determina en base al estado de las a a mquinas padre, denidas con la directiva parent en la denicin del host. a o
Estado preliminar del host DOWN DOWN Estado de los padres Al menos un padre est disponible (UP) a Todos los padre estn ca a dos o inalcanzables (DOWN o UNREACHABLE) Estado nal del host DOWN UNREACHABLE

Tabla 3.2: resolucin del estado preliminar DOWN o

3.5.6.

Cambios de estado en hosts

Evidentemente, los hosts no se encuentran siempre en el mismo estado. Sus componentes se estropean, se aplican parches, hay que reiniciar los servidores. . . Cuando Nagios comprueba el estado de un host, es capaz de detectar entre qu estados cambia y tomar las acciones apropiadas. Estos cambios se traducen e en diferentes tipos de estados (HARD o SOFT), que pueden activar manejadores o enviar noticaciones. Detectar los cambios de estado y actuar acorde a ellos es de lo que trata Nagios. Cuando los hosts cambian de estado con mucha frecuencia, se los considera apping. Un buen ejemplo ser un servidor que se mantiene continuamente a reiniciando debido a un problema al cargar el SO. Nagios puede detectar los hosts que cambian de estado continuamente de este modo, para as no enviar noticaciones hasta que el estado se estabilice.

3.6.

Tests de servicios

El daemon de Nagios comprueba el estado de los servicios: A intervalos regulares, tal y como se especic al denir los servicios en la o denicin de objetos, apartado 2.2.3 en la pgina 12. o a Bajo demanda cuando se necesitan tests predictivos de dependencia entre servicios. Los tests bajo demanda son realizados como parte de la lgica de comproo bacin de dependencias entre servicios, asegurando que la lgica de dependencia o o es precisa. Si no se emplean las dependencias entre servicios, Nagios no realiza

26

3. Manejo bsico a

tests bajo demanda.

3.6.1.

Cachs de chequeo de servicios e

Los tests bajo demanda se pueden mejorar signicativamente si implementamos el uso de cachs para ellas, lo cual permitir a Nagios no ejecutarlas si e a determina que el resultado de otra comprobacin reciente sigue siendo vlido. En o a el anexo A en la pgina 61 se incluye un apartado sobre el uso de cachs para a e los tests bajo demanda.

3.6.2.

Dependencias entre tests

Se pueden denir dependencias de ejecuciones entre servicios que evitan que Nagios compruebe el estado de un servicio en funcin del estado de otro/s sero vicio/s.

3.6.3.

Paralelizacin de tests de servicios o

Los tests peridicas de servicios son ejecutados en paralelo. Cuando Nagios o necesita realizar una comprobacin peridica, el daemon principal crear un nuevo o o a proceso que se encargar de realizarla, y volver a sus otras tareas. Cuando el a a proceso hijo termina el chequeo, informar a Nagios, su proceso padre, de los a resultados del chequeo. El proceso principal entonces interpretar los resultados a y llevar a cabo la accin apropiada. a o Los tests bajo demanda tambin se pueden ejecutar en paralelo si es necesario, e y, como ya se mencion, se puede hacer uso de una cach para aumentar el o e rendimiento.

3.6.4.

Estados de los servicios

Los estados en que se pueden encontrar los servicios tras una comprobacin o son: OK WARNING UNKNOWN CRITICAL

3.7. Tests activos

27

3.6.5.

Determinacin del estado de los servicios o

Los plugins son los encargados de realizar los tests, y pueden devolver OK, WARNING, UNKNOWN o CRITICAL. La traduccin de estados es directa al tener los mismos valores. o

3.6.6.

Cambios de estado en servicios

Cuando Nagios comprueba el estado de un servicio, es capaz de detectar entre qu estados cambia y tomar las acciones apropiadas. Estos cambios se traducen e en diferentes tipos de estados (HARD o SOFT), que pueden activar manejadores o enviar noticaciones. Cambios de estado en servicios tambin pueden provocar e tests bajo demanda de hosts. De nuevo recalcamos que detectar los cambios de estado y actuar acorde a ellos es de lo que trata Nagios. Cuando los servicios cambian de estado con mucha frecuencia, se los considera apping. Nagios puede detectar los servicios que cambian de estado continuamente de este modo, para as no enviar noticaciones hasta que el es tado se estabilice.

3.7.

Tests activos

Nagios es capaz de monitorizar hosts y servicios de manera activa y pasiva. Los tests activos son el mtodo ms comn para monitorizar hosts y servicios. e a u Sus principales caracter sticas son: Son iniciados por el proceso de Nagios. Son ejecutados en base a un esquema regular.

3.7.1.

Realizacin de los tests activos o

Los tests activos son iniciados por la lgica de chequeo en el daemon de o Nagios. Cuando necesita comprobar el estado de un host o servicio, ejecutar un a plugin al que pasar informacin sobre qu necesita comprobar. El plugin comproa o e bar el estado requerido y devolver el resultado al daemon, el cual lo procesar y a a a tomar las acciones que considere apropiadas (e. g. mandar noticaciones, lanzar a manejadores de eventos, etc.). En el apartado 3.3 en la pgina 20 ya se coment la losof y funcionamiento a o a de los plugins.

28

3. Manejo bsico a

Figura 3.3: ejecucin de los tests activos desde el daemon o

3.7.2.

Cundo se ejecutan los tests activos a

Los tests activos se ejecutan: A intervalos regulares, tal y como se especic en la denicin de objetos, o o apartado 2.2.3 en la pgina 12. a Bajo demanda cuando se necesitan. Los tests planicados ocurren a intervalos que se corresponden con el valor check interval o retry interval en la denicin del host o servicio, depeno diendo del estado en que se encuentre. Si se encuentra en un estado HARD, los intervalos se correspondern con el primer valor, mientras que si es SOFT lo harn a a con el segundo. Los tests bajo demanda se realizan siempre que Nagios necesita obtener la informacin de estado ms reciente de un host o servicio. Por ejemplo, si o a est intentando determinar la accesibilidad de un host, ejecutar habitualmente a a tests de hosts padres e hijos para determinar el estado de un segmento de la red. Los tests bajo demanda tambin se realizan para que la lgica de prediccin de e o o dependencias tenga la informacin ms reciente. o a

3.8.

Tests pasivos

Nagios se emplea en la mayor de los casos para monitorizar servicios y hosts a mediande tests activos regulares, pero tambin soporta la monitorizacin pasiva. e o Sus principales caracter sticas son:

3.8. Tests pasivos

29

Son iniciados y llevados a cabo por procesos/aplicaciones externas a Nagios. Sus resultados se transmiten a Nagios para que los procese. La principal diferencia entre activos y pasivos es que los primeros son iniciados por Nagios (aunque los lleve a cabo a travs de sus plugins) mientras que los e segundos son iniciados y realizados por aplicaciones externas.

3.8.1.

Usos de los tests pasivos

Los tests pasivos son utiles para monitorizar servicios que: Son as ncronos por naturaleza y no se pueden monitorizar de una manera efectiva mediante tests peridicos. o Estn situados tras un rewall que impide que la mquina encargada de la a a monitorizacin pueda comprobar activamente su estado. o Ejemplos de servicios as ncronos que se encargan ellos mismos de su monitorizacin son los traps de SNMP o las alertas de seguridad, ya que nunca sabemos o cuntos traps o alertas vamos a recibir en un intervalo de tiempo. a Los tests pasivos tambin se emplean al congurar instalaciones de monitoe rizacin distribuidas o redundantes. o

3.8.2.

Funcionamiento de los tests pasivos

Los tests pasivos funcionan del siguiente modo: 1. Una aplicacin externa comprueba el estado de un host o servicio. o 2. La aplicacin externa escribe los resultados en el chero de comandos o o externos (atributo command file del chero de conguracin principal, visto en el apartado 2.2.1 en la pgina 10). a 3. La prxima vez que Nagios lea el chero de comandos externos colocar los o a resultados de todos los tests pasivos en una cola para procesarlos ms tarde. a La misma cola es usada para almacenar los resultados de tests pasivos y activos. 4. Nagios ejecutar un evento recolector de resultados de tests, escaneando a la cola de resultados de tests. Cada resultado de chequeo que encuentra en la cola para es procesado del mismo modo, sin importar si fue activo o pasivo, actuando del modo que considere apropiado.

30

3. Manejo bsico a

Como se puede ver, el procesamiento de resultados de tests activos y pasivos es idntico en esencia, lo que permite integrar de manera muy directa informacin e o de aplicaciones externas con Nagios.

Figura 3.4: funcionamiento de los tests pasivos de manera externa a Nagios

3.8.3.

Permitiendo tests pasivos

Para poder emplear tests pasivos en Nagios 2 hay que hacer lo siguiente: Poner la directiva accept passive service checks a 1. Poner la directiva passive checks enabled a 1 en las deniciones de hosts y servicios. Si lo que deseamos es deshabilitar el procesado de tests pasivos de manera global, debemos poner la directiva accept passive service checks a 0. Si lo que queremos es deshabilitarlo slo en algunos hosts o servicios, entonces o pondremos la directiva passive checks enabled a 0 en sus deniciones.

3.8.4.

Enviando los resultados de los tests de servicios pasivos

Las aplicaciones externas pueden transmitir los resultados de tests pasivos de servicios a Nagios escribiendo un comando externo PROCESS SERVICECHECK RESULT en el chero de comandos externos.
Aparte de los pasos aqu indicados, debemos resaltar que Nagios slo admite resultados o de tests pasivos para servicios y hosts denidos.
2

3.8. Tests pasivos

31

El formato del comando es el siguiente: [<timestamp>] PROCESS SERVICE CHECK RESULT;<host name>; <svc description>;<return code>;<plugin output> Donde: timestamp es el tiempo en formato time t en el que el chequeo del servicio fue realizado, o enviados sus resultados. Notemos el espacio en blanco despus del corchete derecho. e host name es el nombre corto del host asociado con el servicio en la denicin del servicio. o svc description es la descripcin del servicio tal y como se especic en o o la denicin del servicio. o return code es el cdigo de retorno del chequeo (0=OK, 1=WARNING, o 2=CRITICAL, 3=UNKNOWN). plugin output es el texto de salida del chequeo del servicio (e. g. la salida del plugin).

3.8.5.

Enviando los resultados de los tests de hosts pasivos

Las aplicaciones externas pueden transmitir los resultados de tests pasivos de hosts a Nagios escribiendo un comando externo PROCESS HOST CHECK RESULT en el chero de comandos externos. El formato del comando es el siguiente: [<timestamp>] PROCESS HOST CHECK RESULT;<host name>; <host status>;<plugin output> Donde: timestamp es el tiempo en formato time t en el que el chequeo del host fue realizado, o enviados sus resultados. Notemos el espacio en blanco despus del corchete derecho. e host name es el nombre corto del host. host status es el estado del host (0=UP, 1=DOWN, 2=UNREACHABLE).

32

3. Manejo bsico a

plugin output es el texto de salida del chequeo del host (e. g. la salida del plugin).

3.8.6.

Tests pasivos y estados de hosts

Al contrario que los tests activos de hosts, Nagios no intenta determinar por defecto si un host est ca (DOWN) o inaccesible (UNREACHABLE) con los tests a do pasivos. En su lugar, toma el resultado del test pasivo como el verdadero estado del host y no intenta determinar su estado real mediante la lgica de accesibilidad. o Esto puede causar problemas si estamos enviando tests pasivos desde un host remoto o si tenemos un sistema de monitorizacin distribuido donde las relaciones o padre/hijo entre hosts son diferentes. Podemos indicarle a Nagios que traduzca los estados del test pasivo a su verdadero estado mediante la traduccin de tests pasivos de hosts3 . Este apartado o se comenta en el anexo B en la pgina 63 a

3.8.7.

Enviando resultados de tests pasivos desde hosts remotos

Si una aplicacin en el mismo host que Nagios quiere enviar los resultados de o un chequeo pasivo de un servicio o host, simplemente debe escribir los resultados en el archivo de comandos externo indicado anteriormente. Pero las aplicaciones en hosts remotos no lo pueden hacer de una manera tan sencilla.

Figura 3.5: funcionamiento del addon NSCA

Para poder permitir a hosts remotos enviar sus resultados de tests pasivos a la mquina encargada de la monitorizacin, se desarroll el addon NSCA, el cual a o o consiste en un daemon lanzado en la mquina host de Nagios y un cliente en los a hosts remotos. El daemon escuchar conexiones desde hosts remotos, har tareas a a
Los resultados de tests pasivos son tratados normalmente como estados HARD, a no ser que est activada la opcin espec e o ca para hacerlos SOFT.
3

3.9. Tipos de estados

33

bsicas de validacin sobre los resultados recibidos y despus escribir el resultado a o e a directamente en el chero de comandos externo.

3.9.

Tipos de estados

El estado actual de los hosts y servicios monitorizados se determina en base a dos componentes: El estado del servicio o host (e .g. OK, WARNING, DOWN, etc.). El tipo de estado en que se encuentra el host o servicio. Hay dos tipos de estados en Nagios, estados SOFT y estados HARD. Estos tipos son cruciales para la lgica de monitorizacin, y se usan para determinar o o cundo se ejecutan los manejadores de eventos y se env las noticaciones. a an

3.9.1.

Reintentos de tests de servicios y hosts

A n de prevenir falsas alarmas por problemas transitorios, Nagios permite denir el nmero de veces que un tests de servicio o host se reintenta anu tes de considerar que tiene un problema real. Esto se controla con la opcin o o max check attempts en la denicin del host o servicio. Entender que los reintentos ocurren para determinar si un problema es real es importante a la hora de entender los tipos de estados.

3.9.2.

Estados SOFT

Los estados SOFT ocurren en las siguientes situaciones: Cuando un test de servicio o host no da como resultado OK o UP y el test an no se ha repetido el nmero de veces especicado por la opcin u u o max check attempts en la denicin del host o servicio. A esto se le llama o error SOFT. Cuando un servicio o host se recupera de un error SOFT. A esto se le llama recuperacin SOFT. o Cuando un host o servicio llega a un estado SOFT ocurren los siguientes eventos: El estado SOFT se guarda en el log. Se ejecutan manejadores de eventos para el estado SOFT.

34

3. Manejo bsico a

Los estados SOFT se guardan en el log slo si est activada la opcin log sero a o o vice retries o log host retries en el chero de conguracin principal (apartado 2.2.1 en la pgina 10) a Lo unico realmente importante que sucede durante un estado SOFT es la ejecucin de manejadores de eventos. Estos pueden ser especialmente utiles para o intentar arreglar de manera proactiva un problema antes de que se pase a estado HARD. Las macros $HOSTSTATETYPE$ o $SERVICESTATETYPE$ tendrn el valor a SOFT cuando se ejecuten los manejadores de eventos, por lo que sabrn cundo a a deben tomar acciones correctivas. En el apartado C en la pgina 65 se hablar ms a a a a fondo de los manejadores de eventos.

3.9.3.

Estados HARD

Los estados HARD para hosts y servicios ocurren en las siguientes situaciones: Cuando un test de servicio o host no da como resultado OK o UP y el test ya se ha repetido el nmero de veces especicado por la opcin u o o max check attempts en la denicin del host o servicio. A esto se le llama error HARD. Cuando un host o servicio pasa de un estado de error HARD a otro estado de error (e. g. de WARNING a CRITICAL). Cuando un test de servicio no da como resultado OK y su host se encuentra ca (DOWN) o inaccesible (UNREACHABLE). do Cuando un servicio o host se recupera de un error HARD. A esto se le llama recuperacin HARD. o Cuando se recibe el resultado de un test de host pasivo, a no ser que la e opcin passive host checks are soft est activada. o Cuando un host o servicio llega a un estado HARD ocurren los siguientes eventos: El estado HARD se guarda en el log. Se ejecutan manejadores de eventos para el estado HARD. Se notica a los contactos del problema o recuperacin del host o servicio. o Las macros $HOSTSTATETYPE$ o $SERVICESTATETYPE$ tendrn el valor a HARD cuando se ejecuten los manejadores de eventos, por lo que sabrn cundo a a deben tomar acciones correctivas. En el anexo C en la pgina 65 se hablar ms a a a a fondo de los manejadores de eventos.

3.9. Tipos de estados

35

3.9.4.

Ejemplo de transiciones de estados

Ahora veremos un ejemplo de cmo se determinan los tipos de estados, o cundo ocurren y cundo se ejecutan los manejadores de eventos y se env a a an las noticaciones. El servicio elegido tiene como max check attempts un valor de 3.
Tiempo 0 1 Chequeo # 1 2 Estado OK CRITICAL Tipo de estado HARD SOFT Cambio de estado No S Notas Estado inicial del servicio Primera deteccin de un estado o distinto de OK. Se ejecutan los manejadores de eventos correspondientes. El servicio contina sin estar OK. u Se ejecutan los manejadores de eventos correspondientes. Se ha alcanzado el nmero mxiu a mo de intentos, as que el servi cio pasa a estado HARD. Se ejecutan los manejadores de eventos correspondientes y se env las an noticaciones. El nmero de inu tentos se reinicializa a 1. El servicio cambia a WARNING HARD. Los manejadores de eventos se ejecutan y se env las noan ticaciones. El servicio se estabiliza en el estado. Segn los intervalos de nou ticaciones del servicio, es posible que otra noticacin sea eno viada. El servicio se recupera de manera HARD. Se ejecutan los manejadores de eventos correspondientes y se env las noticaciones. an El servicio sigue OK. Se detecta que el servicio cambia a un estado SOFT distinto de OK. Se ejecutan los manejadores de eventos correspondientes. El servicio se recupera de manera SOFT. Se ejecutan los manejadores de eventos correspondientes, pero no se env noticaciones an ya que no fue un problema real. El estado pasa a HARD y el nmeu ro de reintentos se reinicializa a 1. El servicio se estabiliza como OK.

WARNING

SOFT

CRITICAL

HARD

WARNING

HARD

WARNING

HARD

No

OK

HARD

7 8

1 1

OK UNKNOWN

HARD SOFT

No S

OK

SOFT

10

OK

HARD

No

Tabla 3.3: ejemplo de determinacin de estados o

36

3. Manejo bsico a

3.10.

Per odos de tiempo

Los per odos de tiempo, objetos Timeperiod, permiten controlar cuando funcionan diversos aspectos de la lgica de monitorizacin y alerta. En principio o o se puede restringir: Cundo los tests regulares de hosts y de servicios pueden realizarse. a Cundo se env noticaciones. a an Cundo se pueden intensicar las noticaciones. a Cundo son vlidas las dependencias. a a

3.10.1.

Precedencia en per odos de tiempo

Las deniciones de per odos de tiempo pueden contener mltiples tipos de diu rectivas, incluyendo d de la semana, d del mes y fechas. Los diferentes tipos as as de directivas tienen distintos niveles de precedencia y pueden sobreescribir otras directivas de las deniciones de per odos de tiempo4 . Su orden de precedencia, de manera descendiente, es: 1. Fechas de calendario (01-01-2008). 2. Fecha concreta de un mes (1 de enero). 3. D del mes genrico (d 15). a e a 4. Nmero de secuencia de d de la semana de un mes concreto (2o martes u a de diciembre). 5. Nmero de secuencia de d de la semana (3er lunes). u a 6. D normal de la semana (martes). a

3.10.2.

Cmo funcionan los per o odos de tiempo con los tests de servicios y hosts

Las deniciones de hosts y servicios tienen una directiva opcional, check period, que permite especicar un per odo de tiempo que se usar para restringir a cundo se ejecutan los tests activos regulares del host o servicio. a
En la documentacin ocial de Nagios [1] podemos encontrar todas las directivas y o ejemplos de su uso.
4

3.10. Per odos de tiempo

37

Si no se emplea la directiva, Nagios podr realizar los tests activos en cuala quier momento, 24 horas al d 7 d a la semana. a as Especicar un per odo de tiempo con la directiva check period permite restringir los per odos en que Nagios puede realizar tests activos regulares. Cuando Nagios reintenta un test, se asegura de que cae dentro del per odo vlido, por a lo que es posible que un host o servicio no se compruebe durante una hora, d a, mes, etc. Debemos destacar que los per odos de tiempo no afectan a los tests pasivos o bajo demanda. A no ser que se tenga una buena razn para no hacerlo, siempre es recomeno dable monitorizar durante el 100 % del tiempo, ya que en otro caso crearemos agujeros negros de tiempo, en los cuales parecer que los estados de los hosts a y servicios no cambian, adems de que los contactos no recibirn noticaciones a a por ca o recuperacin en ese per da o odo.

3.10.3.

Cmo funcionan los per o odos de tiempo con noticaciones

Especicando un per odo de tiempo en la directiva notification period en la denicin de un host o servicio, podemos controlar cundo Nagios puede enviar o a noticaciones por problemas o recuperaciones para ese host o servicio. Cuando una noticacin de host se va a enviar, Nagios se asegurar de que el momento o a actual est dentro de un rango vlido del per a a odo de tiempo especicado en dicha directiva. En caso de que as sea, Nagios intentar noticar a cada contacto del a problema o recuperacin. o Tambin podemos emplear los per e odos de tiempo para controlar las noticaciones a contactos individuales, gracias a las directivas service notification period y host notification period en las deniciones de contactos. Emplendolas lograremos que los contactos slo reciban noticaciones de hosts a o 5 o servicios en los per odos especicados .

3.10.4.

Cmo funcionan los per o odos de tiempo con la intensicacin de noticaciones o

La intensicacin de noticaciones para hosts y servicios tiene una directiva o odo de tiempo en opcional, escalation period, que permite especicar un per cuyos tiempos ser vlida la intensicacin. En caso de no emplear la directiva, a a o ser vlida en todo momento. a a
En la documentacin ocial de Nagios [1] se incluyen ejemplos sobre la denicin de o o per odos de tiempo que incluyen rotaciones de contactos, utiles para repartir trabajo.
5

38

3. Manejo bsico a

3.10.5.

Cmo funcionan los per o odos de tiempo con las dependencias

Las dependencias de servicios y hosts tienen una directiva opcional, dependency period, que permite especicar un per odo de tiempo en cuyos tiempos sern vlidas las dependencias. En caso de no emplear la directiva, sern vlidas a a a a en todo momento.

3.11.

Determinando el estado y accesibilidad de los hosts

Todo aquel que ha trabajado en servicio tcnico ha tenido usuarios con el e problema de que Internet se ha ca do. Evidentemente, Internet no ha desaparecido, pero s que ha ocurrido algo entre la silla del usuario y la salida a Internet. Si asumimos que es un problema tcnico, habr que empezar a buscar cul e a a es. Quizs el usuario slo ha encendido la pantalla, es posible que su cable de a o red se haya desconectado, o quizs el router se est tomando un descanso. En a a cualquier caso, algo est claro: Internet no se ha ca aunque no sea accesible a do, para ese usuario. Como hemos visto, no es lo mismo estar ca que inaccesible, aunque lo do pueda parecer desde cierto punto de vista. Nagios tiene sistemas para determinar si un host se encuentra realmente ca o simplemente est inaccesible. De este do a modo podremos determinar ms fcilmente la causa del problema. a a

3.11.1.

Red de ejemplo

Figura 3.6: red de ejemplo para la determinacin de accesibilidad de hosts o

3.11. Determinando el estado y accesibilidad de los hosts

39

Aqu vemos un diagrama de una sencilla red de ejemplo. Asumiremos que se monitorizan todos los hosts y que Nagios est funcionando en el host Nagios. a

3.11.2.

Deniendo las relaciones padre/hijo

Para que Nagios pueda distinguir entre hosts ca dos e inaccesibles, es necesario decirle cmo estn conectados entre ellos, desde el punto de vista del daemon o a de Nagios. Para hacerlo, debemos determinar la traza que seguir un paquete a desde el daemon hasta cada host. Cada switch, router, host, etc. que pasa es un salto, y requiere denir una relacin padre/hijo. Aqu comprobamos cmo ve o o Nagios esas relaciones en esta red:

Figura 3.7: relaciones padre/hijo en la red de ejemplo

Ahora que sabemos las relaciones padre/hijo, debemos congurar Nagios con ellas. Para ello emplearemos la directiva parents en la denicin de los hosts, o donde le indicaremos el/los nodo/s padre/s de cada uno.

3.11.3.

Lgica de accesibilidad en accin o o

Ahora que hemos congurado Nagios con las relaciones padre/hijo apropiadas para los hosts, veamos qu ocurre cuando surge un problema. Asumamos que los e hosts Web y Router1 caen... Cuando los hosts cambian de estado (e. g. desde UP a DOWN), la lgica de o accesibilidad de Nagios entra en juego. Esta iniciar comprobaciones paralelas a

40

3. Manejo bsico a

Figura 3.8: escenario problemtico en la red de ejemplo a

en padres e hijos del host cuyo estado ha cambiado. Esto permite a Nagios determinar rpidamente el estado actual de la infraestructura de red cuando a ocurre cualquier cambio.

Figura 3.9: estados que ha determinado Nagios

3.12. Noticaciones

41

En este ejemplo, Nagios determina que Web y Router1 estn ca (DOWN) a dos ya que la ruta hasta esos hosts no est bloqueada, y que todos los hosts tras a Router1 estn inaccesibles (UNREACHABLE) ya que no puede llegar hasta ellos. a Puede que esos hosts funcionen bien o estn realmente ca e dos, pero para Nagios son inaccesibles y as los considera.

3.11.4.

Estado UNREACHABLE y noticaciones

Por defecto, Nagios noticar a los contactos por hosts en estados DOWN y a UNREACHABLE. Al administrador es probable que no le interesen las noticaciones sobre hosts inaccesibles, ya que conoce su estructura de red, y por tanto con saber que un host se ha ca ya conocer qu partes son inaccesibles. do a e Si preferimos evitar una avalancha de noticaciones por UNREACHABLE, podemos excluirlas con la directiva notification options en las deniciones de hosts y/o en la directiva host notification options en las deniciones de contactos.

3.12.

Noticaciones

En este apartado explicaremos cmo funcionan las noticaciones, cundo se o a env y quines las reciben. an e

3.12.1.

Cundo ocurren las noticaciones? a

La decisin de enviar una noticacin se realiza en base a la lgica de tests o o o de servicios y hosts. Sus noticaciones ocurren en las siguientes situaciones: Cuando se produce un cambio de estado en un estado HARD. Cuando un estado o servicio permanece en un estado HARD distinto de OK y el tiempo especicado por la opcin notification interval en la o denicin del host o servicio ha transcurrido desde que se envi la ultima o o noticacin de ese host o servicio. o

3.12.2.

A quin se notica? e

Cada host y servicio tiene una opcin contact groups que especica los o grupos de contacto que reciben noticaciones para ese host o servicio concreto. Los grupos de contacto pueden contener uno o ms contactos. a Cuando Nagios env una noticacin de un servicio o host, se la enviar a a o a cada miembro de cualquier grupo de contacto especicado en contact groups.

42

3. Manejo bsico a

Nagios comprende que un contacto puede ser miembro de ms de un grupo a de contactos, as que quita las noticaciones a contactos duplicados antes de enviarlas.

3.12.3.

Qu ltros deben pasar las noticaciones ane tes de llegar a su destino?

Slo porque haya que enviar noticaciones sobre un host o servicio no sigo nica que cualquier contacto vaya a ser noticado. Existen varios ltros que las noticaciones potenciales deben atravesar antes ser tenidas en consideracin lo o suciente como para ser enviadas. Incluso entonces, es posible que contactos espec cos no las reciban si sus ltros no las permiten pasar. Filtro de programa general El primer ltro que las noticaciones deben pasar es un test de si las noticaciones estn activadas en la lgica global del programa. Esto se determina a o o con la directiva enable notifications en el chero de conguracin principal (apartado 2.2.1 en la pgina 10), pero se pueden cambiar en tiempo de ejecucin a o desde la interfaz web. Si las noticaciones estn desactivadas, ninguna noticaa cin puede ser enviada. En caso de estar permitidas, existen ms tests que deben o a pasar. . . Filtros de servicio y host El primer ltro para hosts y servicios comprueba si el host o servicio se encuentra en un per odo de inactividad programado (por ejemplo, si se est actualizando a o haciendo labores de mantenimiento en la red). En caso de que as sea, nadie es noticado. Si no, continuamos con el siguiente ltro. Como es evidente, tampoco se notica sobre los servicios de un host que se encuentra en inactividad programada. El segundo ltro consiste en comprobar si el host o servicio se encuentra en un estado inestable (apping), ya que en tal caso no se notica a nadie. El tercero consiste en comprobar las opciones de noticacin espec o cas del host o servicio. Cada denicin de servicio contiene opciones que determinan si o se env noticaciones o no para estados WARNING o CRITICAL o para recupean raciones. De manera similar, cada denicin de host puede permitir o no enviar o noticaciones por DOWN o UNREACHABLE o recuperaciones. Si el host o servicio no

3.12. Noticaciones

43

activa esas opciones, ninguna noticacin del tipo correspondiente es enviada6 . o En otro caso, seguimos con el siguiente ltro. El cuarto ltro es el test de per odo de tiempo. Como vimos en el apartado 3.10 en la pgina 36, cada host y servicio tiene una opcin notificaa o o e a tion period en su denicin que especica en qu momentos son vlidas sus noticaciones. Si el momento en que se crea la noticacin no entra dentro del o per odo, ninguna es enviada7 . En caso contrario, la noticacin se enfrenta al o siguiente ltro. El ultimo conjunto e ltros de servicios o hosts se basa en dos aspectos: 1. Una noticacin ya fue enviada sobre un problema en ese host o servicio o en algn momento pasado. u 2. El host o servicio ha permanecido en el mismo estado distinto de OK desde la ultima noticacin. o Si se cumplen estos dos criterios, Nagios se asegurar de que el tiempo a transcurrido desde la ultima noticacin es menor o igual que el indicado en la o o opcin notification interval en la denicin del host o servicio. Si no ha o pasado el tiempo suciente, nadie es noticado. En caso de que haya pasado el tiempo suciente o no se cumplan ambos criterios, la noticacin es nalmente o enviada. Si alcanza a sus contactos o no, ya es cuestin de otros ltros. . . o Filtros de contactos En este punto las noticaciones han pasado el ltro general y los espec cos del host o servicio y Nagios comienza a noticar a toda la gente que deber a. Signica esto que todos los contactos van a recibir sus noticaciones? No! Cada contacto tiene su propio grupo de ltros que las noticaciones deben pasar antes de llegar realmente a ellos. El primer ltro que deben pasar para cada contacto son las opciones de noticacin. Cada denicin de contacto contiene opciones que determinan si se o o pueden enviar noticaciones de servicios por estados WARNING o CRITICAL o recuperaciones, y de manera similar para hosts por estados DOWN o UNREACHABLE
Las noticaciones sobre recuperaciones slo se env si se notic la incidencia origio an o nal. No tiene sentido avisar de la recuperacin de algo que se desconoce. o 7 Si no se pasa este ltro, Nagios planicar el env de la noticacin para el siguiente a o o momento vlido del per a odo de tiempo, de manera que se informe de las incidencias lo antes posible.
6

44

3. Manejo bsico a

o recuperaciones8 . Si las noticaciones no pasan este ltro, el contacto no es noticado, y en otro caso siguen con el siguiente ltro. El ultimo ltro a pasar para cada contacto es el test de per odo de tiempo. Cada denicin de contacto tiene su opcin notification period que especica o o en qu momentos son vlidas las noticaciones para el contacto. Si el momento e a en que se crea la noticacin no entra dentro del per o odo, entonces no se notica al contacto. En caso de que el momento sea vlido, entonces el contacto es al a n noticado!

3.12.4.

Mtodos de noticacin e o

Podemos hacer que Nagios notique problemas y recuperaciones de maneras muy diversas: fax, SMS, e-mail, mensaje instantneo, audio de alerta, descarga a elctrica, llamada al telfono rojo, etc. Cmo se env las noticaciones depende e e o an de los comandos de noticacin indicados en los cheros de denicin de objetos o o (apartado 2.2.3 en la pgina 12). a Los mtodos de noticacin espec e o cos no estn incorporados directamente a en el cdigo de Nagios ya que no tiene mucho sentido. El ncleo de Nagios no o u pretende ser una aplicacin universal. Si todos los tests estuvieran embebidos o en Nagios, entonces para los usuarios ser bastante complejo aadirlos nuevos, a n modicarlos, etc. Las noticaciones funcionan de un modo similar. Hay miles de modos diferentes de noticar, y ya existen montones de paquetes que realizan ese trabajo, as que por qu reinventar la rueda y limitarnos a usar la bicicleta? e Es mucho ms fcil dejar a un entidad externa (e. g. un simple script) que realice a a ese trabajo tan lioso9 .

3.12.5.

Macro de tipos de noticaciones

Cuando construimos los comandos de noticaciones, necesitamos tener en cuenta el tipo de noticacin que est ocurriendo. La macro $NOTIFICATIONo a TYPE$ contiene un string que lo identica exactamente. Sus posibles valores y descripciones son:
De nuevo, las noticaciones sobre recuperaciones slo se env si se notic la incio an o dencia original. No tiene sentido avisar de la recuperacin de algo que se desconoce. o 9 En la documentacin ocial de Nagios [1] encontramos ejemplos de paquetes para o noticaciones diversas, como SMS.
8

3.13. Interfaces de usuario

Valor PROBLEM

45

RECOVERY ACKNOWLEDGEMENT

FLAPPINGSTART FLAPPINGSTOP FLAPPINGDISABLED DOWNTIMESTART

DOWNTIMESTOP

DOWNTIMECANCELLED

Descripcin o Un servicio o host ha entrado (o sigue) en un estado problemtico. Si es una noticacin de servicio, signica que a o est como WARNING, UNKNOWN o CRITICAL. En caso de que a sea un host, estar como DOWN o UNREACHABLE. a Un servicio o host se ha recuperado. En caso de un host, ha vuelto al estado UP, y un servicio lo har con OK. a Esta noticacin es una conrmacin del conocimiento de o o un problema en un host o servicio. Estas noticaciones las inician con la interfaz web contactos para el host o servicio particular. El host o servicio ha entrado en un estado inestable. El host o servicio ha salido de un estado inestable. El host o servicio ha salido de un estado inestable ya que se ha activado su deteccin. o El host o servicio ha entrado en un per odo de inactividad programado, por lo que no se enviarn futuras noticacioa nes. El host o servicio ha salido de un per odo de inactividad programado, por lo que se volvern a enviar noticaciones a cuando surjan problemas. El per odo de inactividad programado se ha cancelado, por lo que se volvern a enviar noticaciones cuando sura jan problemas.

Tabla 3.4: posibles valores de la macro $NOTIFICATIONTYPE$

3.13.

Interfaces de usuario

Aqu describiremos las diversas interfaces de usuario ofrecidas por Nagios, junto con los requisitos de autorizacin de cada una para poder ser accedidas o (ya abordamos la conguracin de las autorizaciones en el apartado 2.2.5 en la o pgina 15). Por defecto requieren estar autenticado contra el servidor web y tener a autorizacin para ver cualquier informacin requerida. o o

3.13.1.

Interfaz de estado

Fichero: status.cgi Es la interfaz ms importante de Nagios. Permite comprobar el estado de toa dos los hosts y servicios monitorizados. Puede producir dos tipos de salida: una vista general del estado de todos los grupos de hosts (o uno particular) y una

46

3. Manejo bsico a

Figura 3.10: ejemplo de la interfaz de estado

vista detallada de todos los servicios (o aqullos asociados con un host concreto). e Sus requisitos de autorizacin son: o Si ests autorizado para todos los hosts, puedes ver todos los hosts y a servicios. Si ests autorizado para todos los servicios, puedes ver todos los servicios. a Si eres un contacto autenticado, puedes ver todos los hosts y servicios de los que eres contacto.

3.13.2.

Interfaz de mapa de estado

Figura 3.11: ejemplo de la interfaz de mapa de estado

Fichero: statusmap.cgi Crea un mapa de todos los hosts denidos en la red. Emplea la librer gd a de Thomas Boutell para crear la imagen PNG de la red. Las coordenadas usadas al dibujar cada host se toman de su denicin. Tambin podemos dejar que o e la interfaz genere automticamente las coordenadas de dibujo con la directiva a default statusmap layout para especicar un algoritmo a emplear.

3.13. Interfaces de usuario Sus requisitos de autorizacin10 son: o Si ests autorizado para todos los hosts, puedes ver todos los hosts. a

47

Si eres un contacto autenticado, puedes ver todos los hosts de los que eres contacto.

3.13.3.

Interfaz WAP

Figura 3.12: ejemplo de la interfaz WAP

Fichero: statuswml.cgi Sirve como una interfaz WAP para la informacin de estado de la red. Si o tienes un dispositivo WAP (e. g. un telfono mvil con acceso a internet), puee o des ver la informacin de estado en cualquier momento. Las diferentes vistas o de estado incluyen informes de grupos de hosts, resmenes de grupos de hosts, u detalles de hosts, detalles de servicios, todos los problemas y problemas no tratados. Adems de la informacin de estado, puedes deshabilitar noticaciones y a o tests y conrmar noticaciones de problemas desde el telfono. e Sus requisitos de autorizacin son: o Si ests autorizado para la informacin de sistema, puedes ver la informaa o cin de proceso de Nagios. o Si ests autorizado para todos los hosts, puedes ver todos los hosts y a servicios. Si ests autorizado para todos los servicios, puedes ver todos los servicios. a
Un usuario no autorizado a ver hosts espec cos ver nodos desconocidos en esas a posiciones. Lo ms lgico ser que no viesen nada, pero a ver cmo se genera un mapa de a o a o algo que no se debe ver.
10

48

3. Manejo bsico a

Si eres un contacto autenticado, puedes ver todos los hosts y servicios de los que eres contacto.

3.13.4.

Interfaz mundo de estados

Figura 3.13: ejemplo de la interfaz mundo de estados

Fichero: statuswrl.cgi Esta interfaz crea un modelo 3D de todos los hosts denidos en la red. Las coordenadas usadas al dibujar cada host se toman de su denicin. Tambin o e podemos dejar que la interfaz genere automticamente las coordenadas de dia bujo con la directiva default statuswrl layout para especicar un algoritmo a emplear. Se necesita un navegador VRML (como Cortona, Cosmo Player o WorldView ) para visualizarlo. Sus requisitos de autorizacin11 son: o Si ests autorizado para todos los hosts, puedes ver todos los hosts. a Si eres un contacto autenticado, puedes ver todos los hosts de los que eres contacto.

3.13.5.

Interfaz de vista tctica a

Fichero: tac.cgi Sirve como una vista de pjaro para toda la actividad de monitorizacin a o de la red. Muestra rpidamente ca a das en la red, estados de hosts y estados de servicios. Distingue entre problemas que se han manejado de algn modo y u aqullos que no, y por lo tanto necesitan atencin. Muy util cuando se monitoriza e o
De nuevo, un usuario no autorizado a ver hosts espec cos ver nodos desconocidos a en esas posiciones. Lo ms lgico ser que no viesen nada, pero a ver cmo se genera un a o a o mapa de algo que no se debe ver.
11

3.13. Interfaces de usuario

49

Figura 3.14: ejemplo de la interfaz de vista tctica a

un gran nmero de hosts y servicios y se necesita una unica pantalla para avisar u de problemas. Sus requisitos de autorizacin son: o Si ests autorizado para todos los hosts, puedes ver todos los hosts y a servicios. Si ests autorizado para todos los servicios, puedes ver todos los servicios. a Si eres un contacto autenticado, puedes ver todos los hosts y servicios de los que eres contacto.

3.13.6.

Interfaz de fallos de red

Figura 3.15: ejemplo de la interfaz de fallos de red

Fichero: outages.cgi Produce una lista de hosts problemticos en la red que estn causando fallos a a en ella. Puede ser util con redes grandes en las que se quiere identicar rpida a mente el origen del problema. Los hosts se ordenan segn la gravedad del fallo u que provocan. Sus requisitos de autorizacin son: o

50

3. Manejo bsico a

Si ests autorizado para todos los hosts, puedes ver todos los hosts y a servicios. Si eres un contacto autenticado, puedes ver todos los hosts y servicios de los que eres contacto.

3.13.7.

Interfaz de conguracin o

Figura 3.16: ejemplo de la interfaz de conguracin o

Fichero: config.cgi Permite ver los objetos denidos en el chero de conguracin de objetos o (apartado 2.2.3 en la pgina 12). a Sus requisitos de autorizacin son: o Debes estar autorizado para la informacin de conguracin para poder ver o o cualquier tipo de informacin de conguracin. o o

3.13.8.

Interfaz de comandos

Figura 3.17: ejemplo de la interfaz de comandos

Fichero: cmd.cgi

3.13. Interfaces de usuario

51

Permite enviar comandos al proceso de Nagios. Aunque esta interfaz tiene numerosos argumentos, es mejor dejarlos de lado, ya que la mayor cambian a entre las diferentes versiones de Nagios. Es mejor emplear la interfaz de informacin extendida (apartado 3.13.9) para enviar comandos. o Sus requisitos de autorizacin12 son: o Debes estar autorizado para comandos del sistema para poder enviar comandos que afectan al proceso de Nagios. Si ests autorizado para todos los comandos de hosts, puedes enviar coa mandos de todos los hosts y servicios. Si ests autorizado para todos los comandos de servicios, puedes enviar a comandos de todos los servicios. Si eres un contacto autenticado, puedes enviar comandos de todos los hosts y servicios de los que eres contacto.

3.13.9.

Interfaz de informacin extendida o

Figura 3.18: ejemplo de la interfaz de informacin extendida o

Fichero: extinfo.cgi Permite ver la informacin del proceso de Nagios, estad o sticas de estados de hosts y servicios, comentarios de hosts y servicios y ms. Tambin sirve como a e un punto para enviar comandos a Nagios a travs de la interfaz de comandos e (apartado 3.13.8 en la pgina anterior). Aunque esta interfaz tiene bastantes coa mandos, es mejor no emplearlos, ya que suelen variar entre diferentes versiones de Nagios. Sus requisitos de autorizacin son: o
Si hemos elegido no emplear autenticacin con las interfaces, entonces no permitirn o a a nadie enviar comandos. En cualquier caso, siempre es mejor quitar esta interfaz si no empleamos autenticacin. o
12

52

3. Manejo bsico a

Debes estar autorizado para informacin del sistema para poder ver inforo macin del proceso de Nagios. o Si ests autorizado para todos los hosts, puedes ver informacin extendida a o de todos los hosts y servicios. Si ests autorizado para todos los servicios, puedes ver informacin extena o dida de todos los servicios. Si eres un contacto autenticado, puedes ver informacin extendida de todos o los hosts y servicios de los que eres contacto.

3.13.10.

Interfaz de log de eventos

Figura 3.19: ejemplo de la interfaz de log de eventos

Fichero: showlog.cgi Muestra el chero de log. Si est activada la rotacin de logs, podemos naa o vegar por las noticaciones presentes en cheros de log archivados usando los links de navegacin de la parte superior de la pgina. o a Sus requisitos de autorizacin son: o Debes estar autorizado para informacin del sistema para poder ver el o chero de log.

3.13.11.

Interfaz de histrico de alertas o

Fichero: history.cgi Esta interfaz se emplea para mostrar el histrico de los problemas de un host o particular o de todos. La salida es bsicamente un subconjunto de la informaa cin que muestra la interfaz de log de eventos (apartado 3.13.10). Se puede o ltrar la informacin para mostrar slo determinados tipos de problemas (e. g. o o

3.13. Interfaces de usuario

53

Figura 3.20: ejemplo de la interfaz de histrico de alertas o

alertas SOFT/HARD, alertas de varios tipos de servicios, etc.). Si est activada la a rotacin de logs, podemos navegar por las noticaciones presentes en cheros o de log archivados usando los links de navegacin de la parte superior de la pgina. o a Sus requisitos de autorizacin son: o Si ests autorizado para todos los hosts, puedes ver los histricos de todos a o los hosts y servicios. Si ests autorizado para todos los servicios, puedes ver los histricos de a o todos los servicios. Si eres un contacto autenticado, puedes ver los histricos de todos los hosts o y servicios de los que eres contacto.

3.13.12.

Interfaz de noticaciones

Figura 3.21: ejemplo de la interfaz de noticaciones

Fichero: notifications.cgi Muestra las noticaciones de hosts y servicios que se han enviado a los diversos contactos. La salida es bsicamente un subconjunto de la informacin que a o muestra la interfaz de log de eventos (apartado 3.13.10 en la pgina anterior). Se a puede ltrar la informacin para mostrar slo determinados tipos de noticaciones o o (e. g. noticaciones de servicios, noticaciones de hosts, etc.). Si est activada a

54

3. Manejo bsico a

la rotacin de logs, podemos navegar por las noticaciones presentes en cheros o de log archivados usando los links de navegacin de la parte superior de la pgina. o a Sus requisitos de autorizacin son: o Si ests autorizado para todos los hosts, puedes ver las noticaciones de a todos los hosts y servicios. Si ests autorizado para todos los servicios, puedes ver las noticaciones a de todos los servicios. Si eres un contacto autenticado, puedes ver las noticaciones de todos los hosts y servicios de los que eres contacto.

3.13.13.

Interfaz de tendencias

Figura 3.22: ejemplo de la interfaz de tendencias

Fichero: trends.cgi Se emplea para crear un grafo de los estados de un host o servicio a lo largo de un per odo arbitrario de tiempo. Para que esta interfaz sea de verdadera utilidad, debe estar habilitada la opcin de rotacin de logs y mantener los logs archivados o o en la ruta especicada por la directiva log archive path. Esta interfaz emplea la librer gd de Thomas Boutell para crear la imagen de los estados. a Sus requisitos de autorizacin son: o Si ests autorizado para todos los hosts, puedes ver los grafos de todos los a hosts y servicios. Si ests autorizado para todos los servicios, puedes ver los grafos de todos a los servicios. Si eres un contacto autenticado, puedes ver los grafos de todos los hosts y servicios de los que eres contacto.

3.13. Interfaces de usuario

55

3.13.14.

Interfaz de informes de disponibilidad

Figura 3.23: ejemplo de la interfaz de informes de disponibilidad

Fichero: avail.cgi Esta interfaz sirve para comprobar la disponibilidad de hosts y servicios a lo largo de un per odo de tiempo especicado por el usuario. Para que esta interfaz sea de verdadera utilidad, debe estar habilitada la opcin de rotacin o o de logs y mantener los logs archivados en la ruta especicada por la directiva log archive path. Sus requisitos de autorizacin son: o Si ests autorizado para todos los hosts, puedes ver los datos de disponia bilidad de todos los hosts y servicios. Si ests autorizado para todos los servicios, puedes ver los datos de dispoa nibilidad de todos los servicios. Si eres un contacto autenticado, puedes ver los datos de disponibilidad de todos los hosts y servicios de los que eres contacto.

3.13.15.

Interfaz de histograma de alertas

Figura 3.24: ejemplo de la interfaz de histograma de alertas

Fichero: histogram.cgi

56

3. Manejo bsico a

Esta interfaz sirve para comprobar la disponibilidad de hosts y servicios a lo largo de un per odo de tiempo especicado por el usuario. Para que esta interfaz sea de verdadera utilidad, debe estar habilitada la opcin de rotacin o o de logs y mantener los logs archivados en la ruta especicada por la directiva a log archive path. Esta interfaz emplea la librer gd de Thomas Boutell para crear la imagen del histograma. Sus requisitos de autorizacin son: o Si ests autorizado para todos los hosts, puedes ver los histogramas de a todos los hosts y servicios. Si ests autorizado para todos los servicios, puedes ver los histogramas de a todos los servicios. Si eres un contacto autenticado, puedes ver los histogramas de todos los hosts y servicios de los que eres contacto.

3.13.16.

Interfaz de resumen de alertas

Figura 3.25: ejemplo de la interfaz de resumen de alertas

Fichero: summary.cgi Muestra algunos informes generales sobre informacin de alerta de hosts y o servicios, incluyendo el nmero total de alertas, los mayores generadores de aleru tas, etc. Sus requisitos de autorizacin son: o Si ests autorizado para todos los hosts, puedes ver la informacin de los a o resmenes de todos los hosts y servicios. u Si ests autorizado para todos los servicios, puedes ver la informacin de a o los resmenes de todos los servicios. u

3.13. Interfaces de usuario

57

Si eres un contacto autenticado, puedes ver la informacin de los resmenes o u de todos los hosts y servicios de los que eres contacto.

Cap tulo 4 Conclusiones

Tras haber visto las caracter sticas bsicas de Nagios (adems de algunas a a avanzadas incluidas en los anexos) podemos volver a destacar las principales ventajas de esta herramienta de monitorizacin: o Software libre, frente a otras herramientas de pago como Zyrion o uptime que tampoco aaden un nmero enorme de mejoras. n u Aplicacin de cdigo abierto con una comunidad amplia y activa. o o Fcilmente extensible e integrable. a Basado en conceptos sencillos. Catlogo amplio de plugins que crece d a d a a a. Funciona en mltiples sistemas operativos. u Numerosas interfaces y lgicas adicionales que ayudan a localizar problemas o en la red. Testeado durante largo tiempo por su amplia comunidad, convirtindose e en una herramienta eciente y ecaz. Incluye de serie funcionalidades avanzadas como cachs, avisos SMS, roe taciones de noticaciones, etc. Todas estas ventajas convierten a Nagios en una de las aplicaciones de monitorizacin ms extendidas, verstiles y utiles que podemos encontrar hoy en d o a a a, por lo que siempre es una excelente opcin a la hora de mantener nuestra red en o buen funcionamiento.

59

Anexo A Implementacin de cachs de o e chequeo

El rendimiento de la lgica de monitorizacin de Nagios se puede mejorar o o signicativamente mediante el uso de cachs para sus resultados, las cuales le e permiten evitar la ejecucin de los tests si determina que el resultado de uno o relativamente reciente sigue siendo vlido. a

A.1.

Slo tests bajo demanda o

Los tests regulares de hosts y servicios evidentemente no se vern mejorados a mediante el uso de cachs, pero aqullos que son bajo demanda s Los tests e e . regulares sirven para asegurar que el estado de hosts y servicios se actualiza regularmente, lo cual tambin aumenta las posibilidades de que estos resultados e sean empleados como resultados chequeados en el futuro. Recordemos que los tests bajo demanda de hosts ocurren... Cuando un servicio asociado al host cambia de estado. Debido a la lgica de accesibilidad de las mquinas. o a Cuando se necesitan tests predictivos de dependencia entre hosts. Y las de servicios... Cuando se necesitan tests predictivos de dependencia entre servicios. 61

62

A. Implementacin de cachs de chequeo o e

A.2.

Funcionamiento de la cach e

Cuando Nagios necesita realizar un chequeo bajo demanda de una mquina o a un servicio, determinar si puede emplear un resultado cacheado o si es necesario a un chequeo real mediante el uso de un plugin. Esto lo realiza comprobando si el ultimo chequeo ocurri en los X minutos ms recientes, donde X es el margen o a de chequeo del host o servicio. Si el ultimo chequeo se realiz dentro de ese margen, Nagios emplear ese o a resultado y no realizar un chequeo nuevo. Si an no se ha realizado ningn a u u chequeo de ese host o servicio, o bien si el tiempo transcurrido supera el margen, se invocar al plugin para que ejecute la comprobacin de nuevo. a o

Figura A.1: funcionamiento bsico del cacheo de tests a

Debemos destacar que no existe una margen de chequeo ptimo para las o cachs. A mayor valor, menos tests bajo demanda se ejecutarn, pudiendo llegar e a el caso en que slo se ejecuten tests bajo demanda, pero a cambio se emplear ino a formacin muy probablemente desactualizada que podr dar lugar a errores en la o a gestin de la red. Con un valor menor, corremos menos riesgo de manejar datos o incorrectos, pero la red sufrir una carga de trabajo mayor. a Lo ms aconsejable es probar la red con unos valores concretos y realizar a un anlisis estad a stico para comprobar el nmero de tests bajo demanda en un u intervalo de tiempo y cuntos pudieron servirse de la cach, hasta lograr un a e porcentaje aceptable sin que la red sufra problemas por datos desactualizados.

Anexo B Traduccin de estados de tests o pasivos de hosts

Cuando Nagios recibe estados de tests pasivos de hosts desde mquinas a remotas, el estado de host informado por el origen remoto es posible que no reeje elmente el estado del host desde el punto de vista de Nagios. Ya que los sistemas de monitorizacin distribuidos o tolerantes a fallos son bastante o comunes, es importante proveer de mecanismos para asegurar que los estados de los hosts son eles a la lgica de Nagios. o

B.1.

Diferentes puntos de vista

Aqu podemos ver un esquema simplicado de un sistema de monitorizacin o tolerante a fallos:

Figura B.1: esquema de un sistema de monitorizacin redundante o

63

64

B. Traduccin de estados de tests pasivos de hosts o

Nagios-A es el servidor de monitorizacin primario, y monitoriza de manera o activa todos los switches y routers. Nagios-B y Nagios-C son servidores de monitorizacin de reserva, y reciben o resultados de tests pasivos desde Nagios-A. Tanto Router-C como Router-D han sufrido fallos y se encuentran oine. En qu estado se encuentran actualmente Router-C y Router-D? La rese puesta depende de a qu instancia de Nagios le preguntes. e Nagios-A considera a Router-D como DOWN y a Router-C como UNREACHABLE. Nagios-B deber ver a Router-C como DOWN y a Router-D como UNREACHABLE. a Nagios-C deber ver a a ambos routers como DOWN. a Cada instancia de Nagios tiene una visin diferente de la red. Los servidores de o monitorizacin de reserva no deber aceptar a ciegas estados de tests pasivos o an de hosts desde el servidor de monitorizacin principal, o tendrn informacin o a o incorrecta sobre el estado de la red. Sin traducir los resultados de tests pasivos desde el servidor de monitorizacin o principal (Nagios-A), Nagios-C ver a Router-D como UNREACHABLE, cuando a realmente est DOWN desde su punto de vista. De manera similar, los resultados a de los tests pasivos enviados a Nagios-B deber ser comprobados1 . an

B.2.

Permitiendo la traduccin de estados o

Por defecto, Nagios no traduce automticamente los estados DOWN y UNREa ACHABLE de resultados de tests pasivos desde mquinas remotas. Es necesario a activarlo mediante la opcin translate passive host checks en el chero de o conguracin principal, visto en el apartado 2.2.1 en la pgina 10. o a

En algunos casos nos puede interesar saber la visin de la red desde unicamente un o servidor, por lo que no deber amos traducir los estados de los tests pasivos.

Anexo C Manejadores de eventos

Los manejadores de eventos son comandos de sistema opcionales (scripts o ejecutables) que se ejecutan cuando cambia el estado de un host o servicio. Un uso evidente de los manejadores es la habilidad de Nagios para arreglar de manera proactiva problemas antes de que se notique a los tcnicos. Otros e usos de los manejadores incluyen: Reiniciar un servicio que ha fallado. Almacenar informacin de eventos en la base de datos. o Cortar el suministro elctrico a un host. e Etc.

C.1.

Cundo se ejecutan los manejadores de a eventos?

Los manejadores de eventos se ejecutan cuando un host o servicio: Est en un estado problemtico SOFT. a a Entra inicialmente en un estado problemtico HARD. a Se acaba de recuperar de un estado problemtico, sea SOFT o HARD. a Los estados SOFT y HARD ya se describieron con detalle en el apartado 3.9 en la pgina 33. a 65

66

C. Manejadores de eventos

C.2.

Tipos de manejadores de eventos

Hay diferentes tipos de manejadores de eventos opcionales que se pueden denir para manejar cambios de estado de hosts y servicios: Manejadores de eventos de hosts globales. Manejadores de eventos de servicios globales. Manejadores de eventos de hosts espec cos. Manejadores de eventos de servicios espec cos. Los manejadores globales de eventos de hosts y servicios se ejecutan para todos los cambios de estado de cualquier host o servicio, inmediatamente antes de cualquier manejador espec co que se pueda ejecutar. Se pueden especicar comandos manejadores de eventos globales empleando las opciones global host event handler y global service event handler en el chero de conguracin principal (apartado 2.2.1 en la pgina 10). o a Hosts y servicios individuales pueden tener su propio comando manejador de eventos que se ejecutar para manejar los cambios de estado. Se puede especia o car un manejador a ejecutar con la directiva event handler en la denicin del host o servicio. Estos manejadores espec cos de host o servicio se ejecutan inmediatamente despus del manejador global de host o servicio (el cual es e opcional).

C.3.

Activando los manejadores de eventos

Los manejadores de eventos se pueden activar o desactivar de manera global en el programa usando la opcin enable event handlers en el chero de o conguracin principal (apartado 2.2.1 en la pgina 10). o a Los manejadores espec cos de eventos se pueden activar o desactivar mediante la directiva event handler enabled en la denicin del host o servicio. o Los manejadores espec cos tampoco se ejecutarn si todos los manejadores a estn desactivados de manera global en el chero de conguracin principal. a o

C.4.

Orden de ejecucin de los manejadores o de eventos

Como ya se mencion antes, los manejadores globales de hosts y servicios se o ejecutan inmediatamente antes de los manejadores espec cos.

C. Manejadores de eventos

67

Los manejadores se ejecutan para estados problemticos HARD y recuperacioa nes inmediatamente despus de enviar las noticaciones. e

C.5.

Escribiendo comandos manejadores de eventos

Los comandos manejadores de eventos probablemente sern scripts perl o a shell, pero pueden ser cualquier tipo de ejecutable que se pueda lanzar por l nea de comando. Como m nimo, los scripts deber tomar las siguientes macros coan mo argumentos: Para servicios: $SERVICESTATE$, $SERVICESTATETYPE$, $SERVICEATTEMPT$ Para hosts: $HOSTSTATE$, $HOSTSTATETYPE$, $HOSTATTEMPT$ Los scripts deber examinar los valores de los argumentos pasados y tomar an cualquier accin necesaria basada en dichos valores1 . o

C.6.

Permisos de los comandos manejadores de eventos

Los comandos manejadores de eventos normalmente se ejecutarn con los a mismos permisos que el usuario bajo el cual Nagios est funcionando en la mquia a na. Esto puede ser un problema si se quiere escribir un manejador de eventos que reinicie servicios del sistema, ya que normalmente se requieren privilegios de root para ese tipo de tareas. Idealmente se deber poder evaluar los tipos de manejadores de eventos que a se van a implementar y otorgar los permisos necesarios al usuario de Nagios para poder ejecutar los comandos de sistema necesarios. Se puede intentar este apartado empleando sudo.

El mejor modo de comprender su funcionamiento es con un ejemplo, del cual disponemos en la documentacin ocial de Nagios [1], y tambin en el subdirectorio o e contrib/eventhandlers/ en la distribucin de Nagios. o

Bibliograf a
[1] Documentacin ocial de Nagios: o http://nagios.sourceforge.net/docs/3 0/toc.html [2] The Nagios Book: http://www.nagiosbook.org/html/index.html [3] Entrada sobre Nagios en la Wikipedia: http://en.wikipedia.org/wiki/Nagios

69