Configuración de Nagios

Venga, pues este post se ha hecho esperar, pero espero que la espera valga la pena.

Hace unos días contaba como instalar Nagios, un sistema de auditoria de servidores realmente útil para aquellos que tienen entre sus manos la ardua tarea de la administración de servidores. En este post hacía referencia a SNMP, pero Nagios nativamente no es un graficador de trazas SNMP, pero mediante unos plugins va a ser posible.

De momento en este post vamos a comentar como añadir maquinas, capturar las alertas que nos mandan el resto de maquinas que tengamos configuradas y armar un mapa con los hosts que tenemos en la red.

Todos los ficheros de configuración se hallan en /etc/nagios3/conf.d y estos terminan con la extensión .cfg, este último apunte nos va a servir para poder tener ficheros de prueba dentro del mismo directorio.

Cada uno de los ficheros de configuración tiene una estructura muy simple y que se va a repetir en cada uno de los objetos:

define objeto {
        propiedad valor
        }

Para facilitar la tarea de administración de nagios, vamos a tener un fichero para cada tipo de objeto, vamos a empezar así con algunos de los objetos que podemos encontrar. Destacar que nagios trae con la instalación unos ficheros de configuración con algunos parámetros ya configurados, pero por facilidad le he cambiado los nombres de los ficheros por defecto.
Por otra parte no voy a pegar todo el fichero de configuración sino sólo un trozo que es el que vamos a usar como ejemplo:

# vi periodos_tiempo.cfg
define timeperiod{
        timeperiod_name 24x7
        alias           24 Hours A Day, 7 Days A Week
        sunday          00:00-24:00
        monday          00:00-24:00
        tuesday         00:00-24:00
        wednesday       00:00-24:00
        thursday        00:00-24:00
        friday          00:00-24:00
        saturday        00:00-24:00
        }

el objeto timeperiod nos servirá para indicar cada cuando nos tiene que avisar nagios a la que ocurre un problema. El método mas común es por correo electrónico, pero si nos lo curramos podríamos hacer que el sistema nos mandase un sms.

timeperiod_name: es el nombre del objeto timeperiod
alias: es otro nombre, normalmente un nombre corto al que también podemos hacer referencia, si los separamos por coma, podemos definir varios nombres alternativos.

# vi contactos.cfg
define contact{
        contact_name                    root
        alias                           Root
        service_notification_period     24x7
        host_notification_period        24x7
        service_notification_options    w,u,c,r
        host_notification_options       d,r
        service_notification_commands   notify-service-by-email
        host_notification_commands      notify-host-by-email
        email                           root@localhost
        }

El objeto contact es la definición de la persona que va a recibir las alertas, cuándo y dónde.

contact_name: nombre de referencia
alas: otro nombre de referencia
service_notification_period: nombre del objeto timeperiod en el caso que se requiera notificar un cambio de estado de un servicio
host_notificacion_period: nombre del objeto timeperiod en el caso que se requiera notificar un cambio de estado de una maquina
service_notificacion_options & host_notificacion_options:

Notify on transition	Option
WARNING service states	w
UNKNOWN service states	u
CRITICAL service states	c
Service RECOVERY states	r
Send NO service notifications	n

service_notification_commands & host_notification_commands: forma como se nos va a notificar

Este último objeto se define en /etc/nagios3/commands.cfg y al igual que los otros ficheros de configuración ya vienen definidos, a partir de aquí si somos mañosos podremos usar el sistema de envio de mensajes que nos plazca:

# vi /etc/nagios3/commands.cfg
define command{
        command_name    notify-host-by-email
        command_line    /usr/bin/printf "%b" "***** Nagios *****nnNotification Type: $NOTIFICATIONTYPE$nHost: $HOSTNAME$nState: $HOSTSTATE$nAddress: $HOSTADDRESS$nInfo: $HOSTOUTPUT$nnDate/Time: $LONGDATETIME$n" | /usr/bin/mail -s "** $NOTIFICATIONTYPE$ Host Alert: $HOSTNAME$ is $HOSTSTATE$ **" $CONTACTEMAIL$
        }

Si continuamos con el fichero de contactos.cfg, veremos que hay otro tipo de objeto, contactgroups, donde agruparemos los distintos contactos que tengamos definidos en grupos, así podremos hacer referencia a los encargados de web, de bbdd, de dns, etc.

# vi contactos.cfg
define contactgroup{
        contactgroup_name       admins
        alias                   Nagios Administrators
        members                root,blackhold
        }

En este caso el nombre del grupo de contactos es admins, y el miembro es root y blackhold, así que a la que ocurra algo, tanto root, como blackhold van a recibir el mensaje.

Una vez configurado como se comunica nagios con los administradores, vamos a indicarle qué maquinas tenemos que auditar:

# vi maquinas.cfg
define host {
        host_name   tesla
        alias       tesla
        address     195.160.225.38
        use         generic-host
        parents     gateway_guifi
        }

Campos a destacar:
parents: esto permite a la hora de generar el “status map” que unas maquinas hagan referencia a otras, es así una forma para poder tener nuestros hosts un poco mas organizados y agrupados, por ejemplo en mi caso por distintas ubicaciones de las maquinas (gateway_guifi es un router que está definido como otro host mas). Gracias Dani.
use: al crear un nuevo host podemos decirle que use la configuración de otro host, en este caso se genera un fichero a parte con este tipo de definiciones:

# vi auditoria_maquinas.cfg
define host{
        name                            generic-host    ; The name of this host template
        notifications_enabled           1       ; Host notifications are enabled
        event_handler_enabled           1       ; Host event handler is enabled
        flap_detection_enabled          1       ; Flap detection is enabled
        failure_prediction_enabled      1       ; Failure prediction is enabled
        process_perf_data               1       ; Process performance data
        retain_status_information       1       ; Retain status information across program restarts
        retain_nonstatus_information    1       ; Retain non-status information across program restarts
                check_command                   check-host-alive
                max_check_attempts              10
                notification_interval           0
                notification_period             24x7
                notification_options            d,u,r
                contact_groups                  admins
        register                        0       ; DONT REGISTER THIS DEFINITION - ITS NOT A REAL HOST, JUST A TEMPLATE!
        }

La estructura sigue siendo la misma…. y mas o menos las opciones no necesitan mucha explicación excepto check_command.

check_command: es el comando que ejecuta nagios para comprobar que el host está vivo.

En nagios es posible configurar infinidad de alertas y checks que comprueben el funcionamiento correcto de nuestras maquinas, pero por defecto y para facilitar un poco el uso de nagios vienen por defecto algunos templates:

tesla:/etc# ls -lh /usr/share/nagios-plugins/templates-basic/
total 68K
-rw-r--r-- 1 root root  277  1 feb  2009 apt.cfg
-rw-r--r-- 1 root root  458  1 feb  2009 dhcp.cfg
-rw-r--r-- 1 root root  935  1 feb  2009 disk.cfg
-rw-r--r-- 1 root root  673  1 feb  2009 dummy.cfg
-rw-r--r-- 1 root root  414  1 feb  2009 ftp.cfg
-rw-r--r-- 1 root root 3,5K  1 feb  2009 http.cfg
-rw-r--r-- 1 root root  195  1 feb  2009 load.cfg
-rw-r--r-- 1 root root 2,8K  1 feb  2009 mail.cfg
-rw-r--r-- 1 root root  420  1 feb  2009 news.cfg
-rw-r--r-- 1 root root  466  1 feb  2009 ntp.cfg
-rw-r--r-- 1 root root 2,0K  1 feb  2009 ping.cfg
-rw-r--r-- 1 root root  511  1 feb  2009 procs.cfg
-rw-r--r-- 1 root root  397  1 feb  2009 real.cfg
-rw-r--r-- 1 root root  753  1 feb  2009 ssh.cfg
-rw-r--r-- 1 root root  784  1 feb  2009 tcp_udp.cfg
-rw-r--r-- 1 root root  438  1 feb  2009 telnet.cfg
-rw-r--r-- 1 root root  155  1 feb  2009 users.cfg

A partir de aquí ya tenemos los hosts, y sabemos como hacer los checks, otra cosa interesante relacionada con los hosts es que podemos añadirle extensiones, como el tipo de sistema operativo que estamos usando para los hosts (e incluso que nos ponga un dibujito del sistema operativo):

# vi hosts-ext.cfg
define hostextinfo{
        hostgroup_name   debian-servers
        notes            Debian GNU/Linux servers
#       notes_url        http://webserver.localhost.localdomain/hostinfo.pl?host=netware1
        icon_image       base/debian.png
        icon_image_alt   Debian GNU/Linux
        vrml_image       debian.png
        statusmap_image  base/debian.gd2
        }

Es a partir de los hostextinfo donde podemos conectar nuestro nagios con programas externos, por ejemplo con un sistema externo de gráficas (como cacti) o incluso un mediawiki. Esta parte la dejaremos para otro día ;)

Luego para relacionar los hosts y los hostextinfo vamos a usar los hostgroups:

# vi hostgroups.cfg
# A list of your Debian GNU/Linux servers
define hostgroup {
        hostgroup_name  debian-servers
                alias           Debian GNU/Linux Servers
                members         tesla,tesla_guifi,cobalt,cobalt_guifi,...
        }

De la misma forma que podemos agrupar las maquinas por su sistema operativo podemos agrupar las maquinas por tipo de servicio y aplicar a cada grupo un check específico:

# vi tipo_services.cfg
# check that ping-only hosts are up
define service {
        hostgroup_name                  ping-servers
        service_description             PING
        check_command                   check_ping!300.0,20%!900.0,60%
        use                             generic-service
        notification_interval           0 ; set > 0 if you want to be renotified
}

En este caso vamos a definir un servicio de ping, vamos a hacer ping a las maquinas y depende de lo que tarden van a mostrar un WARNING o un CRITICAL con los parámetros que le pasamos en el check_command.

Luego en el hostgroups, las máquinas agrupadas por ping quedarían así:

# vi hostgroups.cfg
define hostgroup {
        hostgroup_name  ping-servers
                alias           Pingable servers
                #members         gateway
                members         gateway_guifi,gateway_guifi2,gateway_guifi_blackhold,tesla,tesla_guifi,cobalt,cobalt_guifi,...
        }

Y finalmente, para cerrar este post de hoy, servicegroups, una forma para agrupar físicamente las maquinas, en este caso por ubicación:

# vi servicegroup_datacenter1.cfg
define servicegroup{
   servicegroup_name DATA1
   alias ServiceGroup Datacenter 1

   members tesla,PING
   [...]
   members cobalt,PING
}

En cada una de las maquinas que auditamos, será necesario instalar el paquete nrpe (# apt-get install nagios-nrpe-server), esto instalará un agente para que el servidor de nagios se pueda comunicar con el host y usar los checks por defecto.
Otra cosa importante además es que la máquina cliente tendrá que ser accesible por la maquina servidora por el puerto 5666 y tendremos que andar con mucho cuidado que si creamos checks nuevos no revelen información crítica de nuestra maquina:

tesla:/etc/nagios3/conf.d# netstat -lanp |grep 'LISTEN ' |grep nrpe
tcp        0      [oculto]:5666            0.0.0.0:*               LISTEN      2683/nrpe

Si deseamos mejorar la seguridad de nuestro nagios, podemos configurar el puerto y las redes de las cuales se permiten peticiones del nrpe en el fichero nrpe.cfg dentro de /etc/nagios/