Nagios: monitoreo remoto de dispositivos + agentes Linux + agentes Windows

Desde hace un par de semanas vengo trabajando con Nagios para tener, al instante, el estado de los
servicios de la red (i.e. monitoreo).
Existen varias herramientas para este tipo de trabajo, estando entre las mejores (según he leído y por recomendaciones) Cacti y Zabbix. Mi elección de Nagios se debe a su integración con OSSIM, y a que ya había trabajado con ella en otra ocasión y me resultó muy buena. Esto no implica que Nagios sea la mejor herramienta, pero sí una excelente. Una comparación interesante que encontré sobre herramientas de monitoreo libres es Tired of Nagios and Cacti? Try Zabbix, la cual, obviamente se enfoca en Zabbix, pero nombra los pro y los contra de cada herramienta.

Las características que encuentro más importantes en Nagios, son:
- Compatibilidad. Existen agentes tanto para Linux como para Windows que permiten monitorear una gran variedad de recursos.
- Flexibilidad. Se pueden definir comandos nuevos para chequeos que no estén incluidos, o para mejorar alguno existente.
- Extendibilidad. El protocolo de comunicación entre agentes y servidor es abierto y está documentado para que cualquiera pueda desarrollar sus propios agentes. Además, como veremos, es posible utilizar varios protocolos.
- Configuración a través de archivos de texto. Si bien algunos no les gusta, para mi es mucho más rápido definir hosts y servicios a chequear mediante simples archivos de texto, que haciendo muchos clicks en una interfaz web.
- Visualización del estado de la red en una sola pantalla. Es fácil y rápido detectar cuando algo anda mal.
- Intervalos para chequear un host/servicio configurables.
- Reporte de alertas por mail y SMSs.
- Sistema de detección de cambios de estado (flapping). Si un host se detecta caído, al minuto normal, al minuto caído, no está bueno recibir 300 alertas, dado que el host está en un estado inestable. Nagios detecta esto y previene futuras alertas hasta que se estabilice.
- Variedad de plugins predefinidos.
- Hay una gran comunidad detrás, así como mucha documentación.


What's all about?

La idea de este artículo no es hablar de las bondades o puntos bajos de Nagios, sino explicar la forma de armar una configuración básica que permita chequear el estado de hosts y servicios remotamente, así como chequear recursos mediante agentes tanto en Windows como en Linux.
Información de Nagios hay mucha, este artículo pretende aportar una explicación resumida del funcionamiento básico y una configuración que abarca la mayoría de los chequeos típicos. Añadir chequeos no debería ser mayor problema una vez conocida las bases.
Para completar esta información, recomiendo leer la documentación oficial en Nagios Core Documentation.


Definición de objetos

Nagios se configura mediante archivos de texto, los cuales deben tener la extensión .cfg. La configuración se basa en objetos, que son los elementos involucrados en la logística de monitoreo y notificación.
Los objetos básicos son:
  - comandos: definen qué programas ejecutar.
  - servicios: son los recursos a testear (CPU, disco, protocolos de red, etc)
  - hosts: definen los hosts que se van a monitorear.
  - contactos: son las personas a las que se va a notificar cuando ocurre una alerta.
  - tiemeperiods: definen en qué horarios se puede chequear un host y en qué horarios se puede notificar a un contacto.
Estos objetos se pueden agrupar mediante los siguientes objetos:
  - hostgroups: permiten agrupar hosts.
  - servicegroups: agrupan servicios.
  - contactgroups: agrupan contactos.

Como se puede observar en la sección de definición de objetos del manual de Nagios, cada objeto puede tener definidos varios atributos, aunque sólo unos pocos (sobre todo si utilizamos la herencia) son obligatorios. Los objetos se definen mediante la cláusula "define" y sus atributos se encierran entre llaves.
Los atributos que utilizaremos para cada tipo de objeto, y que les servirán para la gran mayoría de los casos, son los siguientes:
  comandos:
    - command_name: nombre del comando (por ej check_http)
    - command_line: la línea de comando que se ejecutará para el chequeo (ejemplo: /usr/lib/nagios/plugins/check_http -I $HOSTADDRESS$ -p $ARG1$)

    Como se puede observar en el ejemplo, existen variables predefinidas que se pueden utilizar como argumentos pasados al programa en la línea de comandos (Nagios las denomina macros). La lista completa de macros se encuentra aquí. En el ejemplo $HOSTADDRESS$ es la dirección del host que se está chequeando. También es posible utilizar variables cuyo valor será reemplazado cuando se llame el comando desde la definición de un servicio (o host), las cuales se denominan a partir de $ARG1$ hasta $ARGN$.
 
  servicios:
    - use: directiva que permite heredar atributos de servicios definidos previamente. Es posible definir un servicio base y luego extenderlo mediante esta directiva. En las definiciones de servicios, se suele heredar de "generic-service".
    - service_description: una breve descripción del servicio.
    - hostgroup_name/host_name: asigna el servicio a un grupo de hosts o a hosts específicos. No es mandatorio utilizar este parámetro, dado que se pueden asignar servicios a hosts desde la misma definición de los hosts. Es posible asignar más de un hostgroup o host separándolos con comas.
    - check_command: el nombre del comando, previamente definido, que se utilizará para chequear el servicio. Algo a tener en cuenta es que cuando se llama al comando, los parámetros se pasan separados con signos de admiración. Estos luego se reemplazarán en $ARG1$... $ARGN$, según se definió en el comando.
    Por ejemplo, en la definición de check_tcp encontramos que el comando ejecutado es el siguiente:
      /usr/lib/nagios/plugins/check_tcp -H $HOSTADDRESS$ -p '$ARG1$' -4
    donde $ARG1$ se reemplazará por el puerto TCP que se desea chequear cuando se llame el comando.
    La forma de llamar el comando es la siguiente:
      check_command check_tcp!50000
    donde 50000 es el parámetro utilizado para el puerto.

    NOTA: si no se hereda la definición de generic-service, deberán definirse otros atributos adicionales que son mandatorios (max_check_attempts, check_interval, retry_interval, check_period, notification_interval, notification_period, contacts, contact_groups).

  hosts:
    - use: al igual que en los servicios, esta directiva permite heredar los atributos de un host previamente definido. El caso más común es heredar la definición de "generic-host"
    - host_name: es lo que el nombre indica, el hostname del host.
    - address: dirección IP del host.
    - alias: una breve descripción de la funcionalidad del host.
    - hostgroups: listado de hostgroups a los que el host pertenece. Este atributo no es mandatorio, además es posible asignar los hosts a un hostgroup desde la misma definición del hostgroup.
    - check_command: tiene la misma utilidad que cuando se define un servicio, con la diferencia que se utiliza para chequear si un host está online. Por defecto se utiliza ping (definido en generic-host) como chequeo, pero se puede reemplazar por otro si es que el host no admite pings.
 
    NOTA: si no se hereda la definición de generic-host, deberán definirse otros atributos adicionales que son mandatorios (max_check_attempts, check_period, notification_interval, notification_period, contacts, contact_groups).
 
  hostgroups:
    - hostgroup_name: el nombre del hostgroup que estamos definiendo.
    - alias: una breve descripción de la funcionalidad del hostgroup.
    - members: listado de hosts, separados por coma, que pertenecen a este hostgroup. Este atributo es opcional.

  contactos:
    - contact_name: nombre del contacto.
    - alias: un alias para el mismo.
    - service_notification_period: indica en qué horarios se puede contactar en caso de caída de servicios.
    - host_notification_period: indica en qué horarios se puede contactar en caso de caída del host.
    - service_notification_options: listado de estados de servicio que deben reportarse. Los estados se definen con letras y se separan con comas: u (UNKNOWN), c (CRITICAL), r (RECOVERY - OK), f (FLAPPING), y n (NONE).
    - host_notification_options: listado de estados de host que deben reportarse. También se definen con letras separadas por coma: d (DOWN), u (UNREACHABLE), r (RECOVERY - UP), f (FLAPPING), s (comienza el downtime programado), n (NONE).
    - service_notification_commands: cómo notificar al contacto en caso de servicio caído (email, sms, etc).
    host_notification_commands: cómo notificar al contacto en caso de host caído (email, sms, etc).
    - email: dirección de email del contacto.
    - contactgroups: grupo al que pertenece el contacto.

 
Agentes Nagios

Una gran parte del monitoreo se puede hacer remotamente. Todo servicio publicado en la red, se puede monitorear sin necesidad de instalar nada en el host monitoreado. Sin embargo hay recursos que no se pueden monitorear remotamente, como por ejemplo:
- espacio libre en disco
- memoria en uso
- carga de CPU
- servicios activos
- cantidad de usuarios logueados
Para ello es necesario instalar agentes. Estos agentes, mediante plugins, chequean el estado de los recursos y envían los datos al servidor Nagios. El tipo de conexión es pull, es decir, el servidor Nagios contacta cada cierto intervalo de tiempo a los agentes, les indica qué comandos ejecutar y obtiene los resultados.
Existen varios protocolos utilizados para la comunicación entre agentes y Nagios:
- NRPE - Nagios Remote plugin Executor. Es el protocolo más utilizado y recomendado por Nagios. Se accede mediante el plugin check_nrpe.
- NSCA - Nagios Service Check Acceptor.
- NSCP: protocolo nativo de NSClient++
- NRDP: reemplazo NSCA.
- Syslog: protocolo estándar para transmisión de logs en Unix.
- SNMP: Simple Network Management Protocol. Protocolo estándar para administración y monitoreo de dispositivos de red.

En este artículo se utilizará el protocolo NRPE, para lo cual se instalarán agentes en Linux y Windows que lo soporten.


Instalación del servidor

Instalar el servidor de Nagios es muy simple, está en los repositorios de la mayoría de las distribuciones.
Por ejemplo, en debian, basta con ejecutar:
  # apt-get install nagios3 nagios-nrpe-plugin

La instalación en debian solicita que se introduzca una clave de administración web (usuario nagiosadmin). Pueden elegir no ingresar clave, e ingresarla después. Lo más cómodo es asignarla en esta instancia, aunque queda a elección. La autenticación de la interfaz web la realiza Apache, así que agregar o quitar usuarios se puede realizar con la utilidad htpasswd. También instalamos aquí los plugins para comunicarnos con los agentes mediante NRPE (ver más adelante).

El servicio de Nagios se ejecutará, por defecto, a nombre del usuario nagios y grupo nagios. Esto es para limitar los privilegios, dado que el sistema no necesita permisos de root para ejecutarse, y sería muy riesgoso.


Si utilizan debian, otros datos interesantes acerca de la instalación son:
  - Los plugins default de Nagios (paquete nagios-plugins) se instalan en /usr/lib/nagios/plugins
  - Los comandos (ver más adelante que son) default están definidos en /etc/nagios-plugins/config
  - Por defecto, nagios carga toda la configuración incluida en /etc/nagios3/conf.d, así que lo más conveniente es incluir los archivos con las definiciones de hosts, servicios, comandos, etc, allí.
  - El archivo de configuración de apache para la interfaz web de Nagios se encuentra en /etc/apache2/conf.d/nagios3.conf
  - Por defecto la interfaz web se accede mediante la URL http:///nagios3. Este alias se puede cambiar en el archivo citado en el punto anterior.
  - El archivo de autenticación para la interfaz se encuentra en /etc/nagios3/htpasswd.users


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 --no-install-recommends 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 <muchos bytes...="">" ???). 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 demasiadovivo@itfreekzone.com # 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 =)


Referencias

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