12.4. Monitorización

La monitorización es un término genérico, y las muchas actividades involucradas tiene varias objetivos: por un lado, seguir el uso de recursos provistos por una máquina permite anticipar saturación y la actualización necesaria que le seguirá; por el otro, alertar a los administradores tan pronto como un servicio no esté disponible o no fucione correctamente significa que se podrán solucionar más rápidamente aquellos problemas que sucedan.

Munin cubre la primera área mostrando gráficos de los valores históricos de una cantidad de parámetros (RAM utilizada, espacio ocupado en disco, carga en el procesador, tráfico de red, carga de Apache/MySQL, etc.). Nagios cubre la segunda área, revisando regularmente que los servicios estén funcionando y disponibles, enviando alertas a través de los canales apropiados (correo, mensajes de texto, etc.). Ambos tienen un diseño modular, lo que permite crear nuevos plugins para monitorizar parámetros o servicios específicos.

ALTERNATIVA Zabbix, una herramienta de monitorización integrada

Si bien Munin y Nagios son comunes, no son los únicos jugadores en el campo de la monitorización, y cada uno de ellos gestiona la mitad de la tarea (gráficos por un lado, alertas por otro). Zabbix, por su parte, integra ambas partes de la monitorización; también tiene una interfaz web para configurar los aspectos más comunes. Creció enormemente en los últimos años y ahora se le puede considerar un contendiente viable. En el servidor de monitorización se instalaría zabbix-server-pgsql (o zabbix-server-mysql), y probablemente también zabbix-frontend-php para disponer de una interfaz web. En las máquinas a monitorizar se instalaría zabbix-agent que enviaría los datos al servidor.

→ https://zabbix.com/

12.4.1. Configuración de Munin

El propósito de Munin es monitorizar muchas máquinas; por lo tanto, naturalmente utiliza una arquitectura cliente/servidor. El equipo central — el graficador — recolecta datos de todos los equipos monitorizados y genera gráficos históricos.

12.4.1.1. Configuración de los equipos a monitorizar

El primer paso es instalar el paquete munin-node. El demonio que instala este paquete escucha en el puerto 4949 y envía los datos recolectados por todos los plugins activos. Cada plugin es un programa simple que devuelve una descripción de los datos recolectados y el último valor medido. Los plugins se almacenan en /usr/share/munin/plugins/, pero realmente sólo se utilizan aquellos con un enlace simbólico en /etc/munin/plugins/.

Cuando se instala el paquete, se determina un conjunto de complementos activos en función del software disponible y la configuración actual del host. Sin embargo, esta configuración automática depende de una característica que cada complemento debe proporcionar, y generalmente es una buena idea revisar y ajustar los resultados a mano. Navegar por la Galería de complementos puede ser interesante, aunque no todos los complementos tienen documentación completa.

→ https://gallery.munin-monitoring.org

Sin embargo, todos los complementos son scripts y la mayoría son bastante simples y bien comentados. Navegar por /etc/munin/plugins/ es, por lo tanto, una buena manera de hacerse una idea de qué trata cada complemento y determinar cuál debe eliminarse. De manera similar, habilitar un complemento interesante que se encuentra en /usr/share/munin/plugins/ es una simple cuestión de configurar un enlace simbólico con ln -sf /usr/share/munin/plugins/plugin /etc/munin/plugins/. Tenga en cuenta que cuando el nombre de un complemento termina con un guión bajo "_", el complemento requiere un parámetro. Este parámetro debe almacenarse en el nombre del enlace simbólico; por ejemplo, el complemento " if_ " debe estar habilitado con un enlace simbólico if_eth0, y supervisará el tráfico de red en la interfaz eth0.

Una vez que configuró correctamente los plugins, debe actualizar el demonio de configuración para describir el control de acceso de los datos recolectados. Esto involucra directivas allow en el archivo /etc/munin/munin-node.conf. La configuración predeterminada es allow^127\.0\.0\.1$, lo que sólo permite el acceso al equipo local. Un administrador usualmente agregará una línea similar que contenga la dirección IP del equipo graficador y luego reiniciará el demonio con systemctl restart munin-node.

YENDO MÁS ALLÁ Creación de plugins locales

Munin incluye documentación detallada sobre cómo se deben comportar los plugins y cómo desarrollar plugins nuevos.

→ https://guide.munin-monitoring.org/en/latest/plugin/writing.html

La mejor forma de probar un plugin es ejecutarlo en las mismas condiciones que lo haría munin-node; puede simularlo ejecutando munin-run plugin como root. Puede proveer un posible segundo parámetro a este programa (como config) que será provisto como parámetro al plugin.

Cuando ejecuta un plugin con el parámetro config, debe describirse a sí mismo devolviendo un conjunto de campos:

# munin-run load config
graph_title Load average
graph_args --base 1000 -l 0
graph_vlabel load
graph_scale no
graph_category system
load.label load
graph_info The load average of the machine describes how many processes are in the run-queue (scheduled to run "immediately").
load.info 5 minute load average

La especificación de la guía de referencia de plugins, disponible como parte de la guía de Munin, describe los varios campos disponibles.

→ https://munin.readthedocs.org/en/latest/reference/plugin.html

Cuando lo ejecuta sin parámetros, un plugin simplemente devuelve el último valor medido; por ejemplo, ejecutar sudo munin-run load podría devolver load.value 0.12.

Finalmente, cuando ejecute un plugin con el parámetro autoconf, debería devolver «yes» (y un código de salida 0) o «no» (con un código de salida 1) según si el plugin debería estar activado en este equipo o no.

12.4.1.2. Configuración del graficador

El «graficador» es simplemente el equipo que agrupa los datos y genera los gráficos correspondientes. El software necesario se encuentra en el paquete munin. La configuración estándar ejecuta munin-cron (una vez cada 5 minutos), mediante el que obtiene datos de todos los equipos enumerados en /etc/munin/munin.conf (de forma predeterminada sólo incluye al equipo local), guarda los datos históricos en archivos RRD (base de datos Round Robin: «Round Robin Database», un formato de archivo diseñado para almacenar datos que varían en el tiempo) almacenados en /var/lib/munin/ y genera una página HTML con los gráficos en /var/cache/munin/www/.

Por lo tanto, debe enumerar todas las máquinas monitorizadas en el archivo de configuración /etc/munin/munin.conf. Cada máquina es enumerada como una sección completa con el nombre que coincide con el equipo y al menos un elemento address que provee la dirección IP correspondiente.

[ftp.falcot.com]
    address 192.168.0.12
    use_node_name yes

Las secciones pueden ser más complejas y describir gráficos adicionales que puede crear combinando datos de varias máquinas. Los ejemplos que provee el archivo de configuración son buenos puntos de partida para personalizar.

El último paso es publicar las páginas generadas; esto involucra configurar un servidor web para que el contenido de /var/cache/munin/www/ esté disponible en un sitio web. Generalmente restringirá el acceso a este sitio web, ya sea con un mecanismo de autenticación o un control de acceso basado en IP. Revise la Sección 11.2, “Servidor web (HTTP)” para los detalles relevantes.

12.4.2. Configuración de Nagios

A diferencia de Munin, Nagios no necesita instalar algo en los equipos monitorizados; la mayoría de las veces, se utiliza Nagios para revisar la disponibilidad de servicios de red. Por ejemplo, Nagios puede conectarse a un servidor web y revisar si puede obtener una página web dada en un tiempo especificado.

12.4.2.1. Instalación

El primer paso para configurar Nagios es instalar los paquetes nagios4 y monitoring-plugins. Al instalar los paquetes se configura la interfaz web y el servidor Apache. Los módulos de Apache authz_groupfile y auth_digest deben estar habilitados, para ello ejecute:

# a2enmod authz_groupfile
Considering dependency authz_core for authz_groupfile:
Module authz_core already enabled
Module authz_core already enabled
Enabling module authz_groupfile.
To activate the new configuration, you need to run:
  systemctl restart apache2
# a2enmod auth_digest
Considering dependency authn_core for auth_digest:
Module authn_core already enabled
Enabling module auth_digest.
To activate the new configuration, you need to run:
  systemctl restart apache2
# systemctl restart apache2

Añadir otros usuarios es tan fácil como incluirlos en el archivo /etc/nagios4/hdigest.users.

Apuntar un navegador a http://servidor/nagios4/ mostrará la interfaz web; en particular verá que Nagios ya monitoriza algunos parámetros de la máquina en la que ejecuta. Sin embargo, algunas características interactivas como agregar comentarios a los equipos no funcionarán. Estas características están desactivadas en la configuración predeterminada de Nagios, la cual es muy restrictiva por cuestiones de seguridad.

Para activar algunas funcionalidades deberemos editar el archivo /etc/nagios4/nagios.cfg. También necesitaremos configurar permisos de escritura al directorio que utiliza Nagios, ejecutando algo similar a:

# systemctl stop nagios4
# dpkg-statoverride --update --add nagios www-data 2710 /var/lib/nagios4/rw
# dpkg-statoverride --update --add nagios nagios 751 /var/lib/nagios4
# systemctl start nagios4

12.4.2.2. Configuración

La interfaz web de Nagios es bastante agradable, pero no permite configuración ni puede utilizarla para agregar equipos o servicios a monitorizar. Se administra toda la configuración a través de archivos referenciados en el archivo de configuración central, /etc/nagios4/nagios.cfg.

No debe adentrarse en estos archivos sin entender algunos conceptos de Nagios. La configuración enumera objetos de los siguientes tipos:

a «host» es una máquina a monitorizar;
un «hostgroup» es un conjunto de equipos que deben ser agrupados para visualización o para abstraer algunos elementos de configuración en común;
un «service» es un elemento a probar relacionado a un equipo o grupo. La mayoría de las veces será un chequeo de un servicio de red, pero también puede incluir revisar que algunos parámetros están dentro de un rango aceptable (por ejemplo, espacio libre en el disco o carga del procesador);
un «servicegroup» es un conjunto de servicios que deben ser agrupados para visualización;
un «contact» es una persona que puede recibir alertas;
un «contactgroup» es un conjunto de contactos;
un «timeperiod» es un rango de tiempo durante el que se deben revisar algunos servicios;
un «command» es la línea de órdenes ejecutada para revisar un servicio dado.

Según su tipo, cada objeto tiene una cantidad de propiedades que podemos personalizar. Una lista completa sería demasiado extensa, pero las propiedades más importantes son las relaciones entre objetos.

Un «service» utiliza un «command» para revisar el estado de una característica en un «host» (o «hostgroup») durante un «timeperiod». En caso de un problema, Nagios envía una alerta a todos los miembros de un «contactgroup» relacionado con el servicio. Se envía la alerta a cada miembro según el canal descripto en el objeto «contact» asociado.

Un sistema de herencia permite compartir fácilmente un conjunto de propiedades entre varios objetos sin duplicar información. Lo que es más, la configuración inicial incluye algunos objetos estándar; en muchos casos, definir nuevos equipos, servicios y contactos es tan simple como derivar de los objetos genéricos proporcionados. Los archivos en /etc/nagios4/conf.d/ son una buena fuente de información sobre cómo funcionan.

Los administradores de Falcot Corp utilizan la siguiente configuración:

Ejemplo 12.5. Archivo /etc/nagios4/conf.d/falcot.cfg

define contact{
    name                            generic-contact
    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
    register                        0 ; Template only
}
define contact{
    use             generic-contact
    contact_name    rhertzog
    alias           Raphael Hertzog
    email           hertzog@debian.org
}
define contact{
    use             generic-contact
    contact_name    rmas
    alias           Roland Mas
    email           lolando@debian.org
}

define contactgroup{
    contactgroup_name     falcot-admins
    alias                 Falcot Administrators
    members               rhertzog,rmas
}

define host{
    use                   generic-host ; Name of host template to use
    host_name             www-host
    alias                 www.falcot.com
    address               192.168.0.5
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}
define host{
    use                   generic-host ; Name of host template to use
    host_name             ftp-host
    alias                 ftp.falcot.com
    address               192.168.0.12
    contact_groups        falcot-admins
    hostgroups            debian-servers,ssh-servers
}

# 'check_ftp' command with custom parameters
define command{
    command_name          check_ftp2
    command_line          /usr/lib/nagios/plugins/check_ftp -H $HOSTADDRESS$ -w 20 -c 30 -t 35
}

# Generic Falcot service
define service{
    name                  falcot-service
    use                   generic-service
    contact_groups        falcot-admins
    register              0
}

# Services to check on www-host
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTP
    check_command         check_http
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   HTTPS
    check_command         check_https
}
define service{
    use                   falcot-service
    host_name             www-host
    service_description   SMTP
    check_command         check_smtp
}

# Services to check on ftp-host
define service{
    use                   falcot-service
    host_name             ftp-host
    service_description   FTP
    check_command         check_ftp2
}

Este archivo de configuración describe dos equipos monitorizados. El primero es el servidor web, y se realizan chequeos en los puertos HTTP (80) y HTTP seguro (443). Nagios también revisa que el servidor SMTP ejecute en el puerto 25. El segundo equipo es el servidor FTP y el chequeo incluye asegurarse que responda en menos de 20 segundos. Más allá de esta demora, se generará un «warning» («precaución»); más de 30 segundos generará una alerta crítica. La interfaz web también muestra que se monitoriza el servicio SSH: esto proviene de los equipos que pertenecen al «hostgroup» ssh-servers. El servicio estándar asociado está definido en /etc/nagios4/conf.d/services_nagios2.cfg.

Verá cómo utilizamos herencia: un objeto hereda de otro objeto con la propiedad «use nombre-padre». Debemos poder identificar al objeto padre, lo que requiere incluir en él una propiedad «name identificador». Si no deseamos que el objeto padre sea un objeto real, sino que sólo sirva como padre, agregar una propiedad «register 0» le indica a Nagios que no lo considere y, por lo tanto, ignore la falta de algunos parámetros que serían obligatorios.

YENDO MÁS ALLÁ Pruebas remotas con NRPE

Muchos plugins de Nagios permiten chequear parámetros locales de un equipo; si muchas máquinas necesitan estos chequeos para que los recolecte una instalación central, necesita desplegar el plugin NRPE (ejecución remota de plugins de Nagios: «Nagios Remote Plugin Executor»). Necesitará instalar el paquete nagios-nrpe-plugin en el servidor Nagios y el paquete nagios-nrpe-server en los equipos sobre los que ejecutará los tests locales. Este último obtendrá su configuración del archivo /etc/nagios/nrpe.cfg. Este archivo debe enumerar las pruebas que puede iniciarse remotamente y las direcciones IP de las máquinas que puede ejecutarlas. Del lado de Nagios, activar estas pruebas remotas es tan simple como agregar los servicios apropiados utilizando el nuevo comando check_nrpe.