LinuxParty

Anterior: Explicación de los componentes de configuración de Nagios

Arquitectura de ejemplo

Para poder explicar la configuración de Nagios de forma más didáctica, utilizaremos la siguiente arquitectura de red como ejemplo:

En esta simple estructura traté de cubrir los casos más frecuentes, al menos cubre todos los casos con los que me he topado. La red cuenta con:

- un servidor Nagios que monitoreará todo (192.168.0.100).

- un servidor Linux (linuxagent - 192.168.0.3) con el agente de Nagios instalado, que posee un servicio Web (puerto 80).

- un servidor Windows (winagent - 192.168.0.4) con el agente de Nagios instalado, que presta servicio de fileserver (CIFS puerto 445), y Web service en el puerto 81. En este servidor chequearemos que el servicio de Firewall de Windows esté iniciado (MpsSvc).

- un servidor al cual no se le instaló agente (noagent - 192.168.0.20), pero que presta un servicio no estándar en el puerto 4444.

- un servidor web colocado en internet (itfreekzone - 10.0.0.10, claro está que la IP no es una IP de internet válida, sólo se usa de ejemplo).

Los hosts de la red interna son alcanzables mediante ping, mientras que el servidor Web de internet no.

Si tienen algún caso que no entre en alguna de estos posibles, dejen su comentario y trato de añadirlo :)

Servidor Linux con agente

Arranquemos con la configuración del monitoreo de un servidor linux para el cual utilizamos un agente. Como se indicó anteriormente, NRPE es el protocolo elegido para la ejecución remota de comandos, así que el agente a instalar debe soportarlo. En debian existe un paquete denominado nagios-nrpe-server.

En el servidor Linux, instalaremos entonces los siguientes paquetes (buscar equivalentes en distribuciones no debian):

  # apt-get install nagios-nrpe-server nagios-plugins-basic

El paquete nagios-plugins-basic provee el set básico de plugins para los chequeos.

La configuración del agente NRPE se realiza desde el archivo /etc/nagios/nrpe.cfg. Las variables a tener en cuenta en este archivo son:

server_port=5666 #define en qué puerto (TCP) escuchará el agente. Por defecto es el 5666, pero se puede setear cualquiera.

server_address=192.168.0.3 # indica en qué dirección IP escuchará el agente, en caso que el servidor posea más de una IP.

allowed_hosts=192.168.0.100 # define qué IPs tienen permitido conectarse al agente en busca de datos. Es un parámetro de seguridad mínimo para limitar desde qué máquinas se conectan al agente.

dont_blame_nrpe=0 # mi variable favorita (por su nombre, claro). Esta variable indica si se permite que el agente reciba comandos con parámetros (por ejemplo, en la ejecución "check_disk -w 20%" el parámetro es "-w 20%").

Es muy mala idea permitir que hosts remotos envíen al agente parámetros, dado que podrían utilizarse para explotar alguna vulnerabilidad (qué pasa si se recibe "check_disk -w " ???).

Por ello, se recomienda crear alias de comandos, como por ejemplo "command[check_disk]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -x sda", donde el servidor sólo necesitará llamar "check_disk" (sin parámetros) para obtener los datos de espacio libre y alertas.

    command[check_users]=/usr/lib/nagios/plugins/check_users -w 5 -c 10 # alias check_user para obtener la cantidad de usuarios logueados y alertar si hay más de 5 logueados al mismo tiempo.
    command[check_load]=/usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20 #alias check_load para obtener la carga de CPU
    command[check_disk]=/usr/lib/nagios/plugins/check_disk -w 20% -c 10% -x sda #alias check_disk para obtener el espacio disponible en el disco /dev/sda y alertar si queda menos de 20% de espacio en alguna partición.

Como se ve, los alias son muy importantes, y se pueden agregar tantos como se desee. Estos definen un acceso a información con parámetros predefinidos, de modo que el servidor sólo debe llamar el comando sin parámetros, y disminuir el riesgo (el atributo lo dice, no le eches la culpa a NRPE si se te rompe todo por usar parámetros - dont_blame_nrpe). Sólo listé tres (check_disk, check_load, y check_users) pero podría haber creado todos los que quisiera.

Una vez configurado el agente, reiniciarlo para que tome los cambios:

  # /etc/init.d/nagios-nrpe-server restart

Servidor Windows con Agente

Para monitorear recursos en Windows, existe el demonio NSClient++ (http://www.nsclient.org). El demonio soporta todos los protocolos mencionados anteriormente, pero como comenté, utilizaremos NRPE.

La instalación es muy simple, bajan la última versión del instalador y la ejecutan. Pueden elegir la instalación típica y dar todo next, sin chequear nada, dado que luego reemplazaremos el archivo nsclient.ini con la información que les dejo a continuación. Si desean utilizar las opciones del instalador, verán que permite habilitar algunas cosas, como si utilizar NSCP (check_nt) y/o NRPE (check_nrpe), un password de acceso para el caso de check_nt (el cual no utilizaremos), los hosts que tienen permitido acceder a la información (allowed_hosts), checks WMI, y los check plugins.

Toda la configuración se guarda en el archivo C:\Program Files\NSClient++\nsclient.ini (o C:\Archivos de Programas\NSClient++\nsclient.ini). Si no tildaron nada durante la instalación, verán que está vacío, a excepción de unos comentarios.

NSClient no utiliza el mismo formato de configuración que el visto en el host Linux, es más, varía bastante. Para empezar, la configuración se divide en secciones (formato estándar de los .ini). Por otra parte, los plugins se deben habilitar antes de ser utilizados. Además los plugins se llaman con ejecutables diferentes (CheckCpu. CheckDriveSize, etc), y los alias se definen de otra manera. Para estandarizar, en la configuración utilicé los mismos alias que en el host Linux, así es posible realizar grupos de hosts que incluyan tanto servidores Linux como Windows, y ejecutar los mismos comandos en ambos.

La configuración que utilizaremos será la siguiente:

    [/modules]
    ; habilitamos el uso de NRPE
    NRPEServer = 1

    ; habilitamos plugins a utilizar. Como se ve, los plugins se agrupan por tipo.
    CheckSystem=1
    CheckDisk=1
    CheckExternalScripts=1

    ; creamos los mismos alias que en la definición del host Linux, y agregamos un alias para chequear servicios
    [/settings/external scripts/alias]
    check_load=CheckCpu MaxWarn=80 time=5m ; alias para chequear la carga de CPU. Si sobrepasa el 80% en un intervalo de 5 minutos, nos alertará.
    check_disk=CheckDriveSize ShowAll MinWarnFree=10% MinCritFree=5% ; alias para chequear el espacio en todos los discos del servidor
    check_firewall_service=CheckServiceState MpsSvc; alias para chequear el servicio del firewall de Windows (llamado MpsSvc).

    [/settings/default]
    ; permitimos el acceso al servidor Nagios para las consultas.
    allowed hosts = 192.168.0.100

Configuración de los checks en el servidor Nagios

Bien, con los agentes instalados y configurados, volvemos al servidor Nagios. Utilizamos el directorio /etc/nagios3/conf.d para poner nuestra configuración, tal vez adentro de un directorio nuevo, para que quede más ordenado y no se mezcle con el resto.

Observando el directorio conf.d encontramos varias definiciones, como las citadas generic-host y generic-service. También se agrega por defecto la definición de los servicios a chequear en localhost, algo que nos puede servir como ejemplo. En /etc/nagios-plugins/config encontramos la definición de varios comandos, que nos servirán para la mayoría de los casos, aunque habrá algunos que tendremos que definir nosotros.

Para comenzar, definimos un comando nuevo que utilice check_http, pero que nos permita chequear servicios Web en cualquier puerto. En /etc/nagios-plugins/config/http.cfg existen varios comandos predefinidos para llamar a check_http, pero no encontré ninguno que permita hacer un simple check a un puerto diferente al 80. Si quieren ser prolijos, podríamos incluir los comandos en un archivo commands.cfg dentro de nuestro directorio de configuración.

El comando se define de la siguiente manera:

    define command {
      command_name check_http_port
      command_line /usr/lib/nagios/plugins/check_http -I $HOSTADDRESS$ -p $ARG1$
    }

Cuando se llame el comando, deberá entregarse un puerto como argumento y realizará el chequeo HTTP.

A continuación me parece bien definir un grupo de hosts para agrupar los hosts que tienen instalado el agente, lo denominaremos remote-agent.

    define hostgroup {
      hostgroup_name remote-agent
      alias Hosts que tienen el agente de Nagios instalado
    }

De esta forma, podemos definir servicios que se chequeen en todos los host que tengan el agente instalado, tan solo agregando los hosts al grupo remote-agent y asignando los servicios al mismo. Para los checks remotos, debemos utilizar el comando check_nrpe_1arg (/etc/nagios-plugins/config/check_nrpe.cfg), al cual se le entrega como parámetro el nombre del comando a ejecutar en el host remoto. El “1arg” indica que se le entrega un parámetro (el nombre del comando a ejecutar). Los comandos que llamaremos son los alias que definimos en cada host anteriormente.

En los hosts con el agente realizaremos checks de CPU y disco:

    #checkear CPU
      define service {
        use generic-service # hereda los atributos de generic-service
        hostgroup_name remote-agent # indicamos que se aplica al hostgroup remote-agent
        service_description Load average # describimos lo que se testea
        check_command check_nrpe_1arg!check_load #llamamos a check_nrpe_1arg y le indicamos que debe ejecutar check_load
      }

      #checkear discos
      define service{
        use                             generic-service # heredamos
        hostgroup_name                  remote-agent # aplicamos al grupo remote-agent
        service_description             Disk Space # describimos lo que testeamos
        check_command                   check_nrpe_1arg!check_disk # indicamos que debe ejecutarse el alias check_disk
      }

Ya tenemos los checks genéricos que haremos en los hosts con agentes. Dado que el resto de los servicios los chequearemos por host, pasemos a la definición de los hosts.

    # host linux con agente
    define host {
      use generic-host
      host_name linuxagent
      alias Web Server Linux con agente instalado
      address 192.168.0.3
      hostgroups remote-agent,http-servers
    }

Acá aparece el grupo predefinido http-servers. El mismo se encuentra definido en /etc/nagios3/conf.d/hostgroups_nagios2.cfg y nos permite chequear Web servers que escuchen en el puerto 80.

    # host windows con agente
    define host {
      use generic-host
      host_name winagent
      alias Windows Server, File Server y Web service
      address 192.168.0.4
      hostgroups remote-agent
    }

    # host sin agente
    define host {
      use generic-host
      host_name noagent
      alias Servidor sin agente
      address 192.168.0.20
    }

    # host en internet
    define host {
      use generic-host
      host_name itfreekzone
      alias Web server en internet
      address 10.0.0.10
      hostgroups http-servers
      check_command check_http
      check_interval 5
    }

Nótese que en el servidor itfreekzone agregué el atributo check_command. Dado que el firewall no nos permite realizar pings a internet, es necesario encontrar una alternativa para detectar que el host está online, por ello utilicé check_http. También definí un nuevo intervalo de chequeos (por defecto era 1), para incrementar la distancia entre sucesivos checks y así no estar enviando requests continuamente a Internet.

La definición anterior ya nos alcanza para los chequeos en linuxagent e itfreekzone, pero todavía nos queda trabajo por hacer para monitorear al resto. Pasemos a definir los servicios que nos faltan.

Como comenté anteriormente, en winagent deseamos chequear que el servicio MpsSvc está levantado. Agregamos entonces la siguiente definición:

    define service {
      use generic-service
      service_description Check Firewall Windows
      check_command check_nrpe_1arg!check_firewall_service
      host_name winagent
    }

En la definición se ve que el servicio se aplica solamente al host winagent, y se llama el alias predefinido check_firewall_service. Ahora, en el host windows, resta chequear CIFS y el Web Service:

    define service {
      use generic-service
      service_description Check Web service en puerto 81
      check_command check_http_port!81
      host_name winagent
    }

    define service {
      use generic-service
      service_description Check CIFS
      check_command check_tcp!445
      host_name winagent
    }

Como se observa, para chequear el web service utilizamos el comando que definimos anteriormente (check_http_port), mientras que para chequear CIFS, simplemente realizamos una conexión TCP al puerto 445. Existen plugins específicos para un chequeo más a fondo del servicio CIFS, pero para nuestro ejemplo alcanza.

Qué resta? chequear el serivicio NN en el host noagent. En este caso también utilizaremos check_tcp, nada mágico:

    define service {
      use generic-service
      service_description Check Servicio NN
      check_command check_tcp!4444
      host_name noagent
    }

Ok, tenemos los hosts y los servicios a chequear. Ahora, a quién y cómo enviamos las alertas? Por defecto las alertas se envían al grupo admins (ver /etc/nagios3/conf.d/generic-host_nagios2.cfg), el cual las envía por mail al contacto root@localhost (ver /etc/nagios3/conf.d/contacts_nagios2.cfg). Definamos un nuevo contacto que pertenezca al grupo admins, pero al cual se le envíen solamente estados críticos y recoveries:

    define contact {
      contact_name demasiadovivo # mi nombre
      alias d3m4s1@d0v1v0 # mi alias
      service_notification_period 24x7 # indico que ante caída de servicios me notifique en cualquier momento de la semana
      host_notification_period 24x7 # indico que ante caída del host me notifique en cualquier momento de la semana
      service_notification_options c,r # solo notificarme servicios en estados críticos (c) y recoveries (r)
      host_notification_options d,r # solo notificarme host caído (d) y recoveries (r)
      service_notification_commands notify-service-by-email # notificarme cambios en los servicios por mail
      host_notification_commands notify-host-by-email # notificarme cambios en el host por mail
      email Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo. # mi dirección de mail
      contactgroups admins # me agrego al grupo de contacto admins.
    }

Con esto terminamos la definición. Un restart del servicio Nagios para que tome la nueva configuración y ya estamos:

  # /etc/init.d/nagios3 restart

En caso que algo haya quedado mal definido, Nagios lo indicará con un error y el servicio no iniciará.

Fue difícil? bueno, hasta que aprendemos la terminología, la estructura de objetos y la forma de definir todo, puede que si. Luego es tan simple como agregar definiciones. Por suerte es bastante intuitivo =)

Anterior: Explicación de los componentes de configuración de Nagios

Referencias

- Nagios Core Documentation
- about NSClient++
- Using NSClient++ from nagios with check_nrpe
- Installing Nagios On Debian Lenny And Monitoring A Debian Lenny Server