Bien, ¿continuamos donde lo dejamos? Tenemos nuestro nagios recien instalado y ahora toca configurarlo, plasmar la topología de nuestra red y monitorizar algunos servicios básicos.
El primer archivo que tenemos que tocar es /usr/local/nagios/etc/nagios.cfg. En el, entre otras cosas, se dicen los archivos de configuración que nagios tendrá en cuenta. En el apartado correspondiente a los objetos, que es lo único que vamos a tocar, localizamos la entrada correspondiente al fichero activo como ejemplo (linux.cfg). Comentamos la línea correspondiente a este fichero e introducimos una nueva con el archivo cfg que usaremos y que se llamará, por ejemplo, mired.cfg. Editamos el archivo nagios.cfg e introducimos los siguientes cambios (en negritas):
# Definitions for monitoring the local (Linux) host
# cfg_file=/usr/local/nagios/etc/objects/linux.cfg# Definición de nuestra pequeña red local de ejemplo
cfg_file=/usr/local/nagios/etc/objects/mired.cfg
La red que vamos a definir como ejemplo constará de dos servidores windows, dos linux (uno de ellos el propio que alberga a Nagios), un router que nos da salida a Internet y un switch al que están conectados todos ellos. Vamos a crear el archivo mired.cfg en el directorio especificado y en el incluiremos la definición de estos objetos:
define host{
use linux-server
host_name nagios
alias Nagios Server
address 127.0.0.1
}define host{
use generic-switch
host_name switch#1
alias Switch
address 192.168.0.2
parents nagios
}define host{
use generic-switch
host_name router#1
alias Router ADSL
address 192.168.0.1
parents switch#1
}define host{
use linux-server
host_name intranet
alias Servidor Linux
address 192.168.0.3
parents switch#1
}define host{
use windows-server
host_name windows#1
alias Servidor principal del dominio
address 192.168.0.4
parents switch#1
}define host{
use windows-server
host_name windows#2
alias Servidor secundario del dominio
address 192.168.0.5
parents switch#1
}
Como podeis ver las definiciones son bien sencillas. Esta simpleza deriva de que Nagios usa una estructura jerárquica en la que cada objeto hereda las características definidas previamente en las plantillas que está usando. La declaración de estas plantillas se hace en el archivo templates.cfg. Allí podemos ver, por ejemplo, el contenido del objeto linux-server que, a su vez, se deriva de otro denominado generic-host. Por el momento os digo esto sólo por culturilla porque no nos va a hacer falta. Nos basta con saber que tenemos disponibles las siguientes plantillas para empezar a trabajar con ellas:
- linux-server
- windows-server
- generic-printer
- generic-switch
Otra cosa interesante es la clausula parents mediante la que especificamos las conexiones entre los diferentes hosts. Como veis la única máquina a la que no le hemos asignado un padre es a la que tiene Nagios instalado. Pensad que esa máquina será el corazón de nuestra red de monitorización porque es desde ella desde donde se ejecutaran todos los comandos.
Aunque aquí no aparece ninguna, una máquina puede tener más de un host como padre (imaginaos una estructura de switches con conexiones redundantes entre ellos). Para ello basta con especificar los nombres de todos los padres que consideremos necesarios separados por comas.
A continuación y en el mismo fichero añadiremos las definiciones necesarias para crear grupos y organizar nuestros objetos y para monitorizar un primer servicio común a todos ellos: el PING
define hostgroup{
hostgroup_name linux-servers
alias Servidores Linux
members nagios, intranet
}define hostgroup{
hostgroup_name windows-servers
alias Servidores Windows
members windows#1, windows#2
}define hostgroup{
hostgroup_name switches
alias Electrónica de red
members switch#1, router#1
}define service{
use generic-service
host_name nagios, intranet, switch#1, router#1, windows#1, windows#2
service_description PING
check_command check_ping!200.0,20%!600.0,60%
normal_check_interval 5
retry_check_interval 1
}
La definición de los grupos es autoexplicativa ¿verdad? Luego nos serviran para organizar las vistas adecuadamente. Y desde luego que esta clasificación no es obligatoria. Podeis crear grupos en función del entorno donde estén las máquinas (desarrollo, preproducción, producción), la localización geográfica, el color de la carcasa… a vuestro rollo, vamos.
Para los servicios quizás sea necesario contar algunas cosas más. Como podemos ver el servicio que hemos definido también deriva de un objeto denomimado generic-service y que también se encuentra en el archivo templates.cfg. Podemos echarle allí un vistazo a esa definición pero por el momento no conviene que os despisteis y lo más interesante es la linea etiquetada como check_command que es donde realmente invocamos al comando que se va a encargar de monitorizar el servicio con una curiosa estructura de argumentos separados mediante signos de exclamación. Para comprender lo que estamos haciendo realmente tenemos que echar mano del fichero commands.cfg. Alli buscamos la definición del comando check_ping:
# ‘check_ping’ command definition
define command{
command_name check_ping
command_line $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -p 5
}
$USER1$ es una variable que apunta al directorio donde se encuentran los plugins (/usr/lib/nagios/plugins/) y $HOSTADDRESS$ es la IP del host que estamos monitorizando. Los argumentos que invocamos separados por signos de exclamación se sustituyen aquí por los $ARG1$ y $ARG2$. Es decir, cuando Nagios lanza esta comprobación para, por ejemplo, la máquina que aloja nuestra intranet está ejecutando lo siguiente:
/usr/lib/nagios/plugins/check_ping -H 192.168.0.3 -w 200.0,20% -c 600.0,60% -p 5
No creo que por el momento merezca la pena meterse en muchas interioridades pero básicamente lo que hacemos (y esto es común para casi todos los scripts que monitorizan servicios en Nagios) es pasar un umbral que consideraremos como warning y otro como critical (-w y -c respectivamente). Si te interesa saber más sobre lo que realmente estás haciendo basta con que ejecutes el comando con un -h.
Conocer como funcionan realmente los comandos de nagios es muy importante porque cuando empecemos a desarrollar nuestros propios scripts o queramos modificar los que vienen por defecto lo mejor es ejecutarlos directamente desde línea de comando y comprobar la salida que dan hasta que estemos satisfechos.
Y, si os parece, lo dejamos aquí por el momento. En la próxima entrega añadiremos algunos servicios más y adornaremos con iconos apropiados el mapa de nuestro sistema.
