Monitorización remota de logs con Zabbix

Otra de las muchas posibilidades que nos ofrece Zabbix de cara a la monitorización remota de una máquina, es la posibilidad de controlar también los logs (o cualquier tipo de fichero de texto) de esta última.

El único requerimiento es tener un agente de Zabbix instalado y funcionando en modo activo (comportamiento por defecto del cliente) en el equipo que se desee monitorizar. En el modo pasivo, el cliente lo único que hace es escuchar las peticiones del servidor. Por lo tanto, si queremos que el agente monitorice un log e informe al servidor cuando haya encontrado alguna determinada cadena de texto, el único requisito consistirá en estar en modo activo.

Para desactivar el modo activo (pasar a modo pasivo), lo único que hay que hacer es añadir la siguiente línea al fichero de configuración del cliente:

[root@server ~]# cat /etc/zabbix/zabbix_agentd.conf
...
DisableActive=1

Otra cosa que también conviene tener en cuenta para que esto funcione correctamente es que el nombre definido en el parámetro Hostname (dentro del fichero de configuración del cliente), debe coincidir con el nombre dado al equipo a la hora de configurarlo desde el frontal web de Zabbix (campo Name de la pantalla CONFIGURATION OF HOSTS).

[root@server ~]# cat /etc/zabbix/zabbix_agentd.conf
...
Hostname=server

A continuación vamos a mostrar un ejemplo de monitorización remota de un fichero: vamos a controlar el archivo /var/log/messages del propio servidor de Zabbix, con el objetivo de que nos envíe las líneas de texto que contengan la palabra "error".

Recordar que tendremos que asegurarnos que el usuario zabbix puede leer ese fichero...

[root@server ~]# ls -l /var/log/messages
-rw----r-- 1 root root 160 abr 22 16:48 /var/log/messages

Lo primero que vamos a hacer es crear un item de tipo Zabbix agent (active), el cual retornará un valor de tipo Log. La frecuencia de muestreo (Update interval) la estableceremos en 30 sg.



A continuación vamos a definir un trigger asociado a este item, el cual se encargará de generar una alarma de severidad alta en caso de recibir una línea de error correspondiente al fichero messages.

Dentro del trigger utilizaremos la función nodata(sec), la cual recibirá como argumento un número entero que se corresponderá con un valor en segundos, y donde devolverá un '1' en caso de no haber recibido ninguna línea monitorizada (en nuestro caso, una línea que contenga la palabra "error") durante los últimos segundos definidos en el parámetro sec, o un '0' en caso contrario.

Por lo tanto, nuestro trigger generará una alarma si durante los últimos 30 últimos segundos le ha llegado alguna línea de error.



Otra posibilidad hubiese consistido en enviar todo el fichero messages desde el cliente al servidor. Para ello tendríamos que haber empleado un item con la siguiente clave: log["/var/log/messages"].

La única diferencia con respecto al item anterior es que ahora no le estamos indicando al cliente de Zabbix que envíe al servidor sólo las líneas que contengan la palabra "error", por lo tanto el cliente enviará todo el contenido del fichero a medida que se vaya escribiendo sobre él.

Para esta segunda posibilidad tendríamos que haber empleado en vez de la función nodata, la función regexp, pasándole como argumento la cadena de texto "error". De esta forma generaríamos una alarma cuando dentro de todo el contenido del fichero enviado, se detectara exclusivamente la palabra "error". La expresión del trigger hubiese quedado de la siguiente forma: {server:log["/var/log/messages","error"].regexp(error)}=1.

Este segundo métodos tiene un inconveniente muy grave: estamos enviando todo el fichero a través de la red, con lo que la estamos sobrecargando mandando información no necesaria.

Además para este segundo caso, tendríamos que seleccionar la opción Normal + Multiple TRUE events dentro del campo Event generation, con el objetivo de permitir que se pudieran lanzar múltiples alarmas para el mismo trigger, ya que por ejemplo se podría generar una alarma, pasar una hora y que no se recibiera ningún tipo de información a través del item, y que al cabo de esa hora volviese a llegar otra cadena de texto que se correspondiera con el error. Para este último caso no se generaría la alarma al tener seleccionada una generación de eventos de tipo Normal.

Para el primer ejemplo nos vale con la opción Normal, ya que aunque se generase una alarma, al cabo de 30 sg desaparecería, con lo que a partir de ese tiempo podría llegar otra alarma de la misma clase (cadena "error").

Y ya por último, decir también que si queremos monitorizar un fichero cuyo nombre varía (por ejemplo un log que rota de nombre), podemos emplear en lugar de la función log, la función logrt, la cual sí que acepta la inclusión de expresiones regulares dentro de su primer argumento (nombre del fichero).

Si tuviéramos por ejemplo un fichero (dentro del directorio /var/log) que rotase de la siguiente forma: file_001.log, file_002.log, ..., la clave del item quedaría de la siguiente forma: logrt["/var/log/file_.*.log","error"].