Un lugar en el mundo…

La semana pasada dejamos nuestro nagios funcionando pero un tanto soso. El mapa de estado (tal vez la pantalla más vistosa de la herramienta) queda bastante pobre sin logos identificativos para cada máquina y tan sólo comprobábamos que las máquinas respondieran a un ping sin monitorizar servicio alguno.

Hoy vamos a empezar por ponerlo bonito. Lo primero que necesitamos son logotipos. En el apartado correspondiente de Nagios Exchange tenemos varias colecciones para elegir. Yo uso habitualmente dos de ellas: Base Images para los ordenadores y Cook Images para la electrónica de red. Los descargamos, los descomprimimos y los copiamos en el directorio /usr/local/nagios/share/images/logos. Cada icono suele venir en cuatro formatos diferentes: gif, jpg, png y gd2.

Ahora tenemos que indicar en las definiciones de nuestros hosts los iconos que queremos usar para representarlos. Como ya os he dicho en otras ocasiones soy un poco torpe para los formatos así que suelo hacer caso a las recomendaciones que leí en algún momento (no recuerdo donde) y escojo el .gif como icono general y el .gd2 para el mapa de estado. No voy a poneros de nuevo la definición de todos los hosts con las líneas que hay que incluir para ello. La sintaxis es tan simple que, creo, basta con uno como ejemplo (lo añadido en negrita):

define host{
     use linux-server
     host_name nagios
     alias Nagios Server
     icon_image debian.gif
     statusmap_image debian.gd2
     address 127.0.0.1
     }

Los iconos elegidos para el resto de los hosts han sido network_switch.gif, router.gif, linux40.gif, win40.gif y sus respectivos .gd2 para el mapa de estado. Reiniciamos el servicio y ahora ya se ve mejor ¿verdad?

Añadamos ahora algunos sevicios adicionales. Para ello vamos a volver a echarle un vistazo al fichero /usr/local/nagios/etc/objects/commands.cfg. En el apartado SAMPLE SERVICE CHECK COMMANDS tenemos los que vienen preconfigurados y listos para usar pero ojo con algunos de ellos: los que comienzan con check_local sólo sirven para monitorizar servicios en la propia máquina en la que está instalado nagios. Advertido esto, vamos a añadir los siguientes servicios:

• Número de usuarios, número de procesos y carga de cpu para la máquina que alberga a nagios.
• Servicios SSH y HTTP en ambas máquinas con Linux.
• Servicios SMTP y POP3 en la máquina que alberga la intranet y que, para este ejemplo, también hace las veces de servidor de correo.
• Servicio DHCP en el servidor secundario de dominio de windows.

Para ello añadimos lo siguiente al final de nuestro fichero mired.cfg y volvemos a reiniciar el servicio que ejecuta nagios:

define service{
     use generic-service
     host_name nagios
     service_description Current Users
     check_command check_local_users!20!50
     }

define service{
     use generic-service
     host_name nagios
     service_description Total Processes
     check_command check_local_procs!250!400!RSZDT
     }

define service{
     use generic-service
     host_name nagios
     service_description Current Load
     check_command check_local_load!5.0,4.0,3.0!10.0,6.0,4.0
     }

define service{
     use generic-service
     host_name nagios, intranet
     service_description SSH
     check_command check_ssh
     }

define service{
     use generic-service
     host_name nagios, intranet
     service_description HTTP
     check_command check_http
     }

define service{
     use generic-service
     host_name intranet
     service_description SMTP Response Check
     check_command check_smtp!-t 5 -e «midominio.es»
     }

define service{
     use generic-service
     host_name intranet
     service_description POP3 Response Check
     check_command check_pop!-t 5 -e «midominio.es»
     }

define service{
     use generic-service
     host_name windows#2
     service_description DHCP
     check_command check_dhcp
     }

La única personalización que requiere para adecuarlo a vuestra red es cambiar «midominio.es» en los servicios SMTP y POP3 por los que maneje vuestro servidor de correo.

Ahora la vista del grid de servicios de nuestra red queda bastante mejor (notad que he bajado a propósito el servicio POP3 de la máquina correspondiente para que no todo parezca tan idílico):

¿Sigue diciendo alguien por ahí que la configuración de nagios es complicada?

Y aquí lo dejamos por hoy. En la próxima entrega veremos como añadir nuevos servicios a los que vienen por defecto en el fichero commands.cfg

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.