MONITOREO DE REDES LINUX · Capítulo 05

Monitoreo: Capítulo 5

Nagios y NRPE

blog.carreralinux.com.ar 1
MONITOREO DE REDES LINUX · Capítulo 05

Capítulo 05 - NAGIOS Y NRPE

ÍNDICE

Nagios 3
Objetivos y necesidades 4
Descripción 5
Instalación 6
Creando directivas 7
Agregando grupo de contactos 8
Agregando contactos 10
Agregando comandos 11
Agregando servicios 14
Grupos de servicios 16
Creando el host-template 17
Agregando un nuevo check 22
Utilizando el agente de Nagios 23

blog.carreralinux.com.ar 2
 MONITOREO DE REDES LINUX · Capítulo 05

Capítulo 05 - NAGIOS Y NRPE

Nagios

Nagios es un sistema de monitorización de

equipos y de servicios de red, escrito en C
y bajo la GNU General Public License.

Al estar hecho en “C” nos asegura una rápida ejecución y su

licencia que lo determina como software libre, nos asegura
que siempre vamos a tener actualizaciones disponibles y que
hay una gran comunidad de desarrolladores soportándolo.

Nagios, como diferentes tipos de software libre, tendrá su versión community (que
es con la que vamos a trabajar ahora) y su versión paga.

Creado para ayudar a los administradores a tener el control de qué está pasando en
la red que administran y conocer los problemas que ocurren en la infraestructura que
manejan antes de que los usuarios y gerente, para de esta manera como comenta-
mos anteriormente, se pueda tomar la iniciativa o asumir la responsabilidad de hacer
que las cosas sucedan; decidir en cada momento lo que queremos hacer y cómo lo
vamos a hacer, debido a que este software nos permite obtener datos, interpretarlos
y tomar decisiones en base a ello como:
· Conservar y almacenar datos de la red para manejar reportes y tendencias.
· Ver y analizar la red, así como el tráfico de la red a través del tiempo.
· Monitorear el estado de la red en comparación a los reportes de análisis.
· Generar reportes sustentados para justificar actualizaciones de la red.

blog.carreralinux.com.ar 3
 MONITOREO DE REDES LINUX · Capítulo 05

Para facilitar tareas de explotación de data mining hay diferentes aditivos como un
visor de reportes integrados en el cual se puede ver el histórico de actividad y perfor-
mance de servicios, y además un visor de diagramas de red con el estado actual de
cada equipo.

Nagios tiene un núcleo que construye la in-

terfaz de usuario y plugins, los cuales re-
presentan los ojos y oídos de Nagios que
se encargan de recopilar información (bajo
demanda).

Los mismos pueden estar programados en diversos lenguajes como C, C++, Python,
Perl, PHP, Java, Bash etc., ya que aunque Nagios esté desarrollado en su mayoría en
c, de los plugins solo procesa los datos recibidos, para la posterior elaboración y en-
vío de notificaciones a los encargados de la administración del sistema en cuestión.

Objetivos y necesidades

Conocer el estado tanto de los hosts y servicios brindados por equipos

1° como servidores corriendo diferentes sistemas operativos, routers de los

cuales dependen varios equipos.

Obtener información de los mismos como estado en red, tiempo arriba,

2° puertos abiertos, servicios y procesos corriendo, carga de CPU, carga de

memoria física, carga de memoria virtual, espacio en disco, interfaces de
red activas.

blog.carreralinux.com.ar 4
 MONITOREO DE REDES LINUX · Capítulo 05

También es posible conocer los estados y datos de estos diferentes equi-

3° pos para una elaboración de reportes etc., por medio de testeo de paque-
tes de red, o haciendo uso de diferentes funciones que provee el protocolo
SNMP (Simple Network Management Protocol) que nos permite gestionar
y/o supervisar datos de diferentes elementos y componentes de la red
como routers, switches, servidores etc. y al ser un protocolo standard es
posible monitorizar una amplia variedad de casos en escenarios con siste-
mas ó equipos diferentes.

Con lo cual podremos concluir si el sistema:

· Lleva a cabo eficazmente su finalidad
· Utiliza eficientemente los recursos.

Entonces, de esta manera vamos a poder verificar SLA, cumplimiento de normas,

proyección a futuro.

Descripción

Con Nagios se puede monitorear de todo. Monitorizar servicios de red, a través de

túneles cifrados, notificaciones por SMS, manejador de eventos para soluciones re-
activas, interfaz web.

Esto es posible ya que los chequeos los realizan los plugins.

Entonces, todo chequeo que se pueda pasar a un script o apli-
cación se puede usar en Nagios.

blog.carreralinux.com.ar 5
 MONITOREO DE REDES LINUX · Capítulo 05

Nagios puede ser utilizado tanto por los administradores de

red como por los operadores, ya que podremos crear diferentes
perfiles.

Equipos de desarrollo impactando en:

· Mejora de productividad.
· Antelación de problemas.
· Reporte y aviso de incidentes.
· Agilidad en su tratamiento.
· Mejor y mayor relación e integración de sectores adjunto.

Instalación

Hechas las presentaciones vamos a instalar Nagios. En este caso vamos a utilizar los
repositorios y ciertos paquetes adicionales que nos van a ayudar al correcto funcio-
namiento de Nagios:
# apt-get -y install perl rrdtool freetype2-demos graphviz ndou-
tils-common nagios3 nagios-plugins nagios-snmp-plugins nagios-nr-
pe-plugin

Nos pedirá el password de administrador de Nagios.

Recordémoslo ya que lo utilizaremos más adelante con el usua-
rio nagiosadmin.

blog.carreralinux.com.ar 6
 MONITOREO DE REDES LINUX · Capítulo 05

Creando directivas

Debemos crear algunas entradas de configuración para especificar donde encontra-

mos los servicios, grupos, contactos etc., las mismas debemos incluirlas en nuestro
archivo de configuración /etc/nagios3/nagios.cfg

Este es el archivo que va a leer cuando se inicie el servicio.

Este archivo, aparte de setear ciertos parámetros, llama a
leer el contenido de otras carpetas, o dicho de otra manera,
incluye a otros archivos de configuración.

Las diferentes carpetas y/o archivos que incluye podremos obtenerlos de las senten-
cias cfg_file y cfg_dir.

# Commands definitions
cfg_file=/etc/nagios3/commands.cfg

#Donde estan los plugins

cfg_dir=/etc/nagios-plugins/config

#Donde hay archivos de configuración

cfg_dir=/etc/nagios3/conf.d

O sea, cuando inicie Nagios, va a ingresar a cada una de esas carpetas.

blog.carreralinux.com.ar 7
 MONITOREO DE REDES LINUX · Capítulo 05

Agregando grupo de contactos

Antes de empezar a trabajar debemos entender el funcionamiento de Nagios. Este

trabaja con templates y objetos. Por ejemplo, si vamos a agregar un grupo de con-
tactos previamente tendremos que tener contactos. Si vamos a chequear un servicio,
tendremos que tener un template de ese servicio, o sea, algo que nos defina como se
comporta ese servicio, por ejemplo si le va a mandar mail 7 x 24. Pero... ¿a quién?, a
el grupo de contactos definido por los contactos.

¿Qué queremos decir con esto? Muchas veces archivos de confi-

guración llaman a cosas definidas en otros archivos de confi-
guración.

Cuando revisemos si los archivos de configuración están OK, el error puede hacer
referencia a que un archivo de configuración no puede cargar porque otro archivo de
configuración, al que hace referencia, está mal.

Para que el Nagios envíe notificaciones sobre el estado de los

servicios es necesario definir los grupos a los cuales se los
envía.

Esos grupos están conformados por contactos, y dichos contactos son a los que le
definimos las direcciones de correo:
# cat /etc/nagios3/nagios.cfg | grep conf.d | grep -v \#
cfg_dir=/etc/nagios3/conf.d

Aquí podemos ver que incluye todo un directorio llamado conf.d. Si observamos que
hay dentro de ese directorio:
# ls /etc/nagios3/conf.d

blog.carreralinux.com.ar 8
 MONITOREO DE REDES LINUX · Capítulo 05

Existen varios archivos de configuración que iremos viendo. Primero abriremos el

archivo de contactos para edición:
# vi /etc/nagios3/conf.d/contacts_nagios2.cfg

Aquí está definido de donde toma el contactgroup:

· contactgroup_name: nombre que se le asignara al grupo de contacto.
· alias: descripción corta para identificar al grupo.
· members: miembros del grupo separados por comas. Estos los toma del archivo de
contactos definido más adelante.

Vamos a crear un grupo llamado carreralinux en donde colocaremos los contactos

pgrillo y admin por lo que al final agregamos:
define contactgroup{
contactgroup_name carreralinux
alias CLA Administrators
members pgrillo,clatutor
}

Estos contactos los definiremos más adelante. De nuevo, apa-

rece el comportamiento que un archivo incluye cosas de otro
archivo.

blog.carreralinux.com.ar 9
 MONITOREO DE REDES LINUX · Capítulo 05

Agregando contactos

Aquí es donde se crean los miembros del grupo. Vamos a crear un par de contactos.
Los archivos para que sean leídos tienen que terminar en .cfg. La totalidad del direc-
torio será leída ya que:
# vi /etc/nagios3/conf.d/contacts-CLA.cfg

define contact{
contact_name clatutor
alias Administrador Nagios
contactgroups carreralinux
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-service-by-email
host_notification_commands notify-host-by-email
email alejandro.drabenche@carre-
ralinux.com.ar
}

define contact{
contact_name pgrillo
alias La voz de la oncienca
contactgroups carreralinux
service_notification_period 24x7
host_notification_period 24x7
service_notification_options w,u,c,r
host_notification_options d,u,r
service_notification_commands notify-service-by-email
host_notification_commands notify-host-by-email
email [email protected]
}

blog.carreralinux.com.ar 10
 MONITOREO DE REDES LINUX · Capítulo 05

· contact_name: nombre literal a asignarle al contacto.

· alias: alias descriptivo del contacto, ej. administrador de routers.
· contactgroups: grupos de contactos a los cuales pertenece.
· service_notification_period: período de tiempo en el cual recibir notificaciones sobre
el estado de los servicios.
· host_notification_period: período de tiempo en el cual recibir notificaciones sobre
el estado de los hosts. Estos períodos se encuentran definidos en /etc/nagios3/
conf.d/timeperiods_nagios2.cfg
· service_notification_options: opciones de cuando realizar una notificación sobre el
estado de un servicio.
· host_notification_options: opciones de cuando realizar una notificación sobre el es-
tado de un host.
· service_notification_commands: comando para realizar la notificación del estado del
servicio.
· host_notification_commands: comando para realizar la notificación del estado del host.
· email: email perteneciente al contacto en el cual recibirá las notificaciones por email.
Para que esto funcione se debe tener correctamente configurado el mail delivery local.

Agregando comandos

En Nagios los encargados de recabar toda la

información respecto de alertas, servicios,
hosts son los comandos.

Esto es una de las grandes virtudes de Nagios. Nagios no precisa un script hecho
en un lenguaje específico. Simplemente necesita un script que devuelva 0 para OK,
1 para WARNING y 2 para CRITICAL. O sea, cualquier cosa que sea chequeable
mediante un script Nagios lo podrá revisar.

blog.carreralinux.com.ar 11
 MONITOREO DE REDES LINUX · Capítulo 05

Podemos hacer una división entre los comandos de performance y los comandos de
chequeo, nosotros vamos a utilizar mayormente los de chequeo. Estos últimos traen
datos de los equipos a monitorear, como CPU, memoria:
# cat /etc/nagios3/nagios.cfg | grep cfg_dir | grep config | grep -v \#
cfg_dir=/etc/nagios-plugins/config

Luego vamos a ver que hay adentro del primer directorio:

# ls /etc/nagios-plugins/config

Cada uno de estos archivos corresponde a los servicios que

podemos llegar a chequear. Cuando definamos lo que queremos
revisar, no vamos a llamar directamente a un script.

Vamos a llamar al check por un nombre, enviándole o no parámetros, y ese check

estará asociado a un comando. Ese comando está definido en uno de los archivos.

Si queremos chequear por ejemplo el LOAD:

# cat /etc/nagios-plugins/config/load.cfg

El contenReferencia DGido es:

# ‘check_load’ command definition
define command{
command_name check_load
command_line /usr/lib/nagios/plugins/check_load --warnin-
g=’$ARG1$,$ARG2$,$ARG3$’ --critical=’$ARG4$,$ARG5$,$ARG6$’
}

blog.carreralinux.com.ar 12
 MONITOREO DE REDES LINUX · Capítulo 05

Donde:
· command_name: el nombre que el comando tendrá para nuestra configuración per-
sonal de Nagios. Dicho de otra manera, este es el nombre con el que invocaremos al
comando y en este caso precisaremos pasarle 6 parámetros.
· command_line: modo del cual Nagios ejecutará el comando en cuestión, con su ruta
física y argumentos Lo que vemos en entre signos $ son variables internas de Nagios
o lo mismo que decir variables de entorno, llamadas macros, las más comunes son:
· $USER1$: contiene datos del path de ejecución de los plugins de Nagios
· $HOSTADDRESS$: tiene la IP de hosts desde el cual se está corriendo el ser-
vicio
· $ARG1$ $ARG2$ $ARG3$ $ARG4$: son los números en orden de argumentos
que recibe el comando a ejecutar. Estos argumentos son enviados cuando invo-
camos al comando.

El hecho de separar los check (antes venían todos los chequeos

en el mismo archivo) se decidió así en Debian. De esta forma
queda muchísimo mas prolijo.

Es por eso que si quisiéramos agregar nuevos servicios, con sus respectivos coman-
dos para chequearlo, simplemente agregaríamos aquí el .cfg correspondiente. Eso
sí, no es que cada cosa que chequeamos esté en un archivo separado, sino que los
chequeos de http, por ejemplo, están en el mismo archivo:
# cat /etc/nagios-plugins/config/http.cfg

Para que quede un poco más claro el concepto, veamos uno de los checks de http:
# ‘check_http_hostname’ command definition
define command{
command_name check_httpname
command_line /usr/lib/nagios/plugins/check_http -H
‘$HOSTNAME$’ -I ‘$HOSTADDRESS$’ ‘$ARG1$’
}

blog.carreralinux.com.ar 13
 MONITOREO DE REDES LINUX · Capítulo 05

El comando que ven, es el comando que ejecuta Nagios siendo usuario Nagios, por
lo que podremos ejecutarlo de manera manual siendo Nagios:
# su -s /bin/bash nagios
$ / usr/lib/nagios/plugins/check_http

Vemos que nos devuelve el help. Ahora, guiándonos con lo anterior, ejecutemos el
comando con los parámetros correctos:
$ /usr/lib/nagios/plugins/check_http -H www.institutolinux.com

Veamos primero el string de respuesta, que es lo que se imprimirá en pantalla:

HTTP OK: HTTP/1.1 200 OK - 24971 bytes in 8.073 second response
time |time=8.073377s;;;0.000000 size=24971B;;;0

Y el valor de salida:
$ echo $?
0

Agregando servicios

Nagios separa lo que son los servicios o

elementos a chequear del host, del host mis-
mo. O sea, para Nagios una cosa es un ser-
vicio y otra cosa es el host.

blog.carreralinux.com.ar 14
 MONITOREO DE REDES LINUX · Capítulo 05

Primero veamos el archivo de template del servicio. Este archivo define el compor-
tamiento y las propiedades del servicio por lo que cualquier servicio asociado a este
template se comportará de la misma manera, que es la siguiente:
# vi /etc/nagios3/conf.d/cla_services.cfg
# definición servicio SNMP
define service{
name cla-service
service_description Chequeo servicios criticos
active_checks_enabled 1
servicegroups criticos
passive_checks_enabled 1
parallelize_check 1
obsess_over_service 1
check_freshness 0
notifications_enabled 1
event_handler_enabled 1
flap_detection_enabled 1
failure_prediction_enabled 1
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
notification_interval 0
is_volatile 0
check_period 24x7
normal_check_interval 2
retry_check_interval 1
max_check_attempts 4
notification_period 24x7
notification_options w,u,c,r
contact_groups carreralinux
register 0
}

blog.carreralinux.com.ar 15
 MONITOREO DE REDES LINUX · Capítulo 05

· notification_interval: esta directiva se utiliza para definir el número de las “unidades

del tiempo” para esperar antes de re-notificar a un contacto que este servidor todavía
está abajo o inalcanzable. A menos que se haya cambiado la directiva interval_length
del valor prefijado de 60, este número significará minutos. Si este valor se establece a
0, Nagios re-no notificará contactos sobre los problemas para este host - solamente
una notificación del problema será enviada.
· notification_period: período de tiempo en el cual se envía notificación y notificación
· notification_options: esta directiva indica a Nagios ante que eventos debe enviar una
notificación:
· w: warning
· u: unknown
· c: critical
· r: recupera
· f: flapping

Cada uno de estos esta asociado a la salida del comando de

check. O sea, un exit 2 será c, por lo que será un critical.

Grupos de servicios

Los grupos de servicios se utilizan para de-

notar un variedad de servicios sobre otros,
debemos tener asignado aunque sea un servi-
cio a ese grupo (o sea, no se pueden tener
grupos vacíos) porque si no de lo contrario
Nagios mostrará un error al arranque.

Esto sería de la siguiente manera:

# vi /etc/nagios3/conf.d/cla_servicegroups.cfg
define servicegroup{
servicegroup_name criticos
alias Servicio criticos.
}

blog.carreralinux.com.ar 16
 MONITOREO DE REDES LINUX · Capítulo 05

Noten que el servicegroup_name coincide con el parámetro ser-

vicegroups del template anterior. Nuevamente, los archivos de
configuración de Nagios se relacionan unos con otros.

Creando el host-template

Ahora vamos a crear el template para el host ya que como les comenté anteriormen-
te, para Nagios una cosa son los servicios y otra es el host:
# vi /etc/nagios3/conf.d/cla_hosts.cfg
define host{
name cla-critical-host
hostgroups critical-hosts
notifications_enabled 1
event_handler_enabled 1
flap_detection_enabled 1
failure_prediction_enabled 1
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
check_command check-host-alive
max_check_attempts 3
notification_interval 0
notification_period 24x7
notification_options d,u,r
contact_groups carreralinux
register 0
}

blog.carreralinux.com.ar 17
 MONITOREO DE REDES LINUX · Capítulo 05

define host{
name cla-noncritical-host
hostgroups noncritical-hosts
notifications_enabled 1
event_handler_enabled 1
flap_detection_enabled 1
failure_prediction_enabled 1
process_perf_data 1
retain_status_information 1
retain_nonstatus_information 1
check_command check-host-alive
max_check_attempts 3
notification_interval 0
notification_period never
notification_options d,u,r
contact_groups carreralinux
register
}

Como pueden ver, aquí definí dos templates de hosts, el primero

para los críticos y el segundo para los no críticos.

Se observa que la diferencia está en el notification_period. Estos se encuentran de-

finidos en el archivo /etc/nagios3/conf.d/timeperiods_nagios2.cfg

blog.carreralinux.com.ar 18
 MONITOREO DE REDES LINUX · Capítulo 05

Y por último, el hostgroup al que pertenece:

# vi /etc/nagios3/conf.d/cla_hostgroups.cfg
define hostgroup {
hostgroup_name critical-hosts
alias critical-hosts
}

define hostgroup {
hostgroup_name noncritical-hosts
alias noncritical-hosts
}

Ahora es donde todo lo anterior empieza a tener sentido, ya que vamos a definir los
hosts y los servicios que vamos a chequear dentro de los mismos. Voy a crear dentro
de Nagios, una carpeta que sea servers:
# mkdir -p /etc/nagios3/servers/

Y ahí dentro voy a crear un archivo por cada equipo a che-

quear. Y dentro del archivo voy a setear que host chequeo y
que servicios chequeo.

blog.carreralinux.com.ar 19
 MONITOREO DE REDES LINUX · Capítulo 05

Primero definamos que solo vamos a hacer un check del servicio de SSH al cliente:
# vi /etc/nagios3/servers/monitoreo-cliente.cfg
define host{
use cla-noncritical-host
host_name monitoreo-cliente
alias monitoreo-cliente
address 192.168.1.113
icon_image base/debian.png
vrml_image debian.png
statusmap_image base/debian.gd2
}

#Los servicios que chequeo

define service{
use cla-service
host_name monitoreo-cliente
service_description SSH
check_command check_ssh
}

Observen dos bloques:

Un primer bloque que define el host y ahí indicamos que estamos hacien-

1° do uso del template cla-noncritical-host. Aparte, vean que seteamos la

dirección IP del cliente. Esto se cargará en la variable de entorno $HOSTA-
DDRESS$ que le pasará al script.

2° Y en el segundo bloque indico que template usar.

blog.carreralinux.com.ar 20
 MONITOREO DE REDES LINUX · Capítulo 05

Finalmente llegó el momento de probar todo.

Algo útil que tienen Nagios es la capacidad de probar la con-

figuración antes de reiniciar Nagios.

Para esto ejecutamos el siguiente comando:

# nagios3 -v /etc/nagios3/nagios.cfg
…
Total Warnings: 0
Total Errors: 0

Ahora si, iniciaremos el servicio e ingresaremos:

http://ip_del_server/nagios3

El usuario es nagiosadmin y la contraseña es la anterior. Por defecto cuando ingrese-

mos, si hacemos click en services, veremos la totalidad de los servicios que estamos
chequeando. Pero... falta el último host que agregamos (ya que localhost viene por
defecto precargado).

Esto es porque no incluimos la carpeta /etc/nagios3/servers en nuestro archivo de

configuración general. Para esto haremos abrimos el archivo:
# vi /etc/nagios3/nagios.cfg

Y agregamos o descomentamos la siguiente línea:

cfg_dir=/etc/nagios3/servers

Guardamos y hacemos el check:

# nagios3 -v /etc/nagios3/nagios.cfg

Y reiniciamos el servicio:
# /etc/init.d/nagios3 restart

Y al momento de acceder podremos observar que se encuentra corriendo.

blog.carreralinux.com.ar 21
 MONITOREO DE REDES LINUX · Capítulo 05

Agregando un nuevo check

Si deseamos agregar un nuevo check, simplemente lo debemos agregar en el archivo

/etc/nagios3/servers/monitoreo-cliente.cfg, debajo de todo lo siguiente:
#Los servicios que chequeo
define service{
use cla-service
host_name monitoreo-cliente
service_description HTTP-8080
check_command check_http!-p 8080
}

Que es el ejemplo de ejemplo el http que habíamos visto antes; pero vamos a hacerlo
fallar a propósito pasándole como parámetro el puerto 8080. Por lo que si el coman-
do era:
/usr/lib/nagios/plugins/check_http -H ‘$HOSTNAME$’ -I ‘$HOSTAD-
DRESS$’ ‘$ARG1$’

Y $ARG1$ le estoy pasando como parametro -p 8080. El comando que ejecutará

será:
/usr/lib/nagios/plugins/check_http -H 192.168.1.113 -I
192.168.1.113 -p 8080

Solo resta chequear:

# nagios3 -v /etc/nagios3/nagios.cfg

Y reiniciar:
# /etc/init.d/nagios3 restart

blog.carreralinux.com.ar 22
 MONITOREO DE REDES LINUX · Capítulo 05

Utilizando el agente de Nagios

Nagios a su vez tiene un agente llamado NRPE.

Este agente me permite ejecutar scripts de
chequeo en servidores remotos, obteniendo
la salida (el exit) y el string.

Por ejemplo, el script de chequeo de especio en disco en el cual le pido que me avise
si el filesystem / warning cuando tenga menos de 2GB y critical si tiene menos de
1GB. Manualmente, ejecutaríamos:
/usr/lib/nagios/plugins/check_disk -w 2000 -c 1000 -p /

Bien, esto lo está haciendo en el equipo local; pero yo quiero que esto mismo lo
ejecute el equipo remoto, para que me devuelva la información del equipo remoto.
Entonces Nagios le solicitará al agente NRPE que está corriendo en el equipo remoto
que, como usuario Nagios, ejecute este scritpt.

NRPE lo ejecutará y le devolverá la información; pero del

equipo remoto. De más está decir que este script tiene que
existir en el equipo remoto.

Bien, dentro del equipo remoto, que es monitoreo-cliente ejecutamos el siguiente

comando para instalar el agente junto con todos los plugins que son los scripts de
chequeo:
# apt-get update && apt-get -y install nagios-nrpe-plugin na-
gios-nrpe-server nagios-plugins-contrib nagios-snmp-plugins gcc
make libssl-dev

blog.carreralinux.com.ar 23
 MONITOREO DE REDES LINUX · Capítulo 05

Luego debemos compilarlo desde el source para activar una opción que no viene por
defecto:
# cd /tmp
# wget --no-check-certificate https://github.com/NagiosEnterpri-
ses/nrpe/releases/download/3.0.1/
# tar-zxvf nrpe-3.0.1.tar.gz
# cd nrpe-3.0.1
# ./configure --enable-command-args --enable-ssl
# make all
# make install

Y ahora reemplazamos el binario que instaló el gestor de paquetes:

# rm /usr/sbin/nrpe
# ln -s /usr/local/nagios/bin/nrpe /usr/sbin/nrpe

El archivo de configuración del agente es /etc/nagios/nrpe.cfg y deberemos tener

ciertas cosas en cuenta. Si lo abrimos para editar debemos revisar las siguientes líneas:
allowed_hosts=127.0.0.1,192.168.1.112

Esta nos indicará de que dirección/es IP aceptará el agente solicitudes. Aquí debe
figurar la dirección IP de Nagios:
dont_blame_nrpe=1

Este parámetro nos indicará si aceptamos que nos envíen parámetros. O sea, hay
ciertos checks que requieren de parámetros. Si dejamos esto en 1 aceptarán los
mismos.

Este parámetro es el que no viene compilado a partir de la

versión 2.15 y por eso es que debimos recompilar con soporte
para esta opción.

blog.carreralinux.com.ar 24
 MONITOREO DE REDES LINUX · Capítulo 05

Los checks, como por ejemplo el de los discos, tienen la siguiente manera. Veamos
un ejemplo:
command[check_hda1]=/usr/lib/nagios/plugins/check_disk -w 20% -c
10% -p /dev/hda1

Donde:
· check_hda1: es el nombre del check. Esto recordémoslo ya que así lo llamaremos
desde el Nagios
· /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/hda1: es el comando
que ejecutará.

Por lo que si queremos nosotros crear un nuevo check, debemos respetar esa sinta-
xis. Por lo pronto nosotros modificaremos esta línea para que quede de la siguiente
manera:
command[check_sda]=/usr/lib/nagios/plugins/check_disk -w 20% -c
10% -p $ARG1$

Como podemos ver, cambiamos el nombre del check del plugin y aparte vamos a
pasarle como parámetro la partición a revisar. Guardamos y reiniciamos el agente:
# /etc/init.d/nagios-nrpe-server restart

Ahora volvamos al servidor nms. Volvámonos a transformar en el usuario Nagios:

# su -s /bin/bash nagios

Para saber si está bien configurado el agente en el cliente, primero deberemos invo-
carlo, desde el NMS, con el siguiente comando:
$ /usr/lib/nagios/plugins/check_nrpe -H 192.168.1.113
NRPE v2.15

blog.carreralinux.com.ar 25
MONITOREO DE REDES LINUX · Capítulo 05

Si todo fue bien nos habrá devuelto la versión de NRPE. Ahora, si queremos invocar
al check:
$ /usr/lib/nagios/plugins/check_nrpe -H 192.168.1.113 -c check_sda
Unknown argument
Usage:
check_disk -w limit -c limit [-W limit] [-K limit] {-p path | -x
device}
[-C] [-E] [-e] [-f] [-g group ] [-k] [-l] [-M] [-m] [-R path ]
[-r path ]
[-t timeout] [-u unit] [-v] [-X type] [-N type]

¿Por qué nos devolvió esto? Bien, esto es porque nuestro check
tenía parámetros, y la respuesta es la que da el comando cuan-
do no tiene parámetros.

O sea, esta respuesta es la respuesta por defecto ante la ejecución de ese comando,
sin parámetros; pero se ejecutó en el cliente.

Entonces, si quiero saber de /, el comando finalmente es:

$ /usr/lib/nagios/plugins/check_nrpe -H 192.168.1.113 -c check_
sda -a /

blog.carreralinux.com.ar 26
MONITOREO DE REDES LINUX · Capítulo 05

Ahora llegó el momento de cargar el check. Abrimos el archivo /etc/nagios3/ser-

vers/monitoreo-cliente.cfg dentro del NMS y agregamos lo siguiente al final:
define service{
use cla-service
host_name monitoreo-cliente
service_description /
check_command check_nrpe!check_sda!/
}

Como pueden ver, el check_commando cambió. Está invocando al comando que

mostramos anteriormente. Pero, donde está definido check_nrpe_1arg. Esto, como
comentamos anteriormente, se encuentra definido en /etc/nagios3/servers/moni-
toreo-cliente.cfg

blog.carreralinux.com.ar 27