3 Supervisión de archivos de registro

Resumen

Zabbix se puede usar para la supervisión y el análisis centralizados de archivos de registro con o sin compatibilidad con la rotación de registros.

Las notificaciones se pueden usar para advertir a los usuarios cuando un archivo de registro contiene ciertas cadenas o patrones de cadenas.

Para supervisar un archivo de registro, debe tener:

• Zabbix agent en ejecución en el host
• item de supervisión de registros configurado

Configuración

Verificar los parámetros del agent

Asegúrese de que en el archivo de configuración del agent:

• El parámetro Hostname coincida con el nombre del host en el frontend.
• Los servers en el parámetro ServerActive estén especificados para el procesamiento de comprobaciones activas.

Configuración del item

Configure un item de monitorización de logs.

Todos los campos de entrada obligatorios están marcados con un asterisco rojo.

Específicamente para los items de monitorización de logs, introduzca:

Notas importantes

• El server y el agent mantienen el seguimiento del tamaño de un log monitorizado y de la hora de la última modificación (para logrt) en dos contadores. Además:
  • El agent también usa internamente números de inode (en UNIX/GNU/Linux), índices de archivo (en Microsoft Windows) y sumas MD5 de los primeros 512 bytes del archivo de log para mejorar las decisiones cuando los archivos de log se truncan y se rotan.
  • En sistemas UNIX/GNU/Linux se asume que los sistemas de archivos donde se almacenan los archivos de log informan números de inode, que pueden usarse para rastrear archivos.
  • En Microsoft Windows Zabbix agent determina el tipo de sistema de archivos en el que residen los archivos de log y usa:
    • En sistemas de archivos NTFS, índices de archivo de 64 bits.
    • En sistemas de archivos ReFS (solo desde Microsoft Windows Server 2012), identificadores de archivo de 128 bits.
    • En sistemas de archivos donde los índices de archivo cambian (por ejemplo, FAT32, exFAT) se usa un algoritmo alternativo para adoptar un enfoque razonable en condiciones inciertas cuando la rotación de archivos de log da como resultado varios archivos de log con la misma hora de última modificación.
  • Los números de inode, los índices de archivo y las sumas MD5 son recopilados internamente por Zabbix agent. No se transmiten a Zabbix server y se pierden cuando Zabbix agent se detiene.
  • No modifique la hora de última modificación de un archivo de log (por ejemplo, con touch), y no reemplace un archivo de log monitorizado copiando un archivo de vuelta a su nombre original (esto crea un nuevo inode). En cualquiera de los dos casos Zabbix puede tratar el archivo como un archivo diferente y volver a leerlo desde el principio, lo que puede producir alertas duplicadas.
  • Si hay varios archivos de log coincidentes para el item logrt[] y Zabbix agent está siguiendo el más reciente de ellos y este archivo de log más reciente se elimina, se registra un mensaje de advertencia "there are no files matching "<regexp mask>" in "<directory>". Zabbix agent ignora los archivos de log con una hora de modificación menor que la hora de modificación más reciente vista por el agent para el item logrt[] que se está comprobando.
• El agent comienza a leer el archivo de log desde el punto en que se detuvo la vez anterior.
• El número de bytes ya analizados (el contador de tamaño) y la hora de última modificación (el contador de tiempo) se almacenan en la base de datos de Zabbix y se envían al agent para asegurarse de que el agent comience a leer el archivo de log desde este punto en los casos en que el agent acaba de iniciarse o ha recibido items que anteriormente estaban deshabilitados o no eran compatibles. Sin embargo, si el agent ha recibido un contador de tamaño distinto de cero desde server, pero el item logrt[] o logrt.count[] no puede encontrar archivos coincidentes, el contador de tamaño se restablece a 0 para analizar desde el principio si los archivos aparecen más tarde.
• Siempre que el archivo de log se vuelva más pequeño que el contador de tamaño de log conocido por el agent, el contador se restablece a cero y el agent comienza a leer el archivo de log desde el principio teniendo en cuenta el contador de tiempo.
• Si hay varios archivos coincidentes con la misma hora de última modificación en el directorio, entonces el agent intenta analizar correctamente todos los archivos de log con la misma hora de modificación y evitar omitir datos o analizar los mismos datos dos veces, aunque no puede garantizarse en todas las situaciones. El agent no asume ningún esquema particular de rotación de archivos de log ni determina uno. Cuando se presentan varios archivos de log con la misma hora de última modificación, el agent los procesará en orden lexicográfico descendente. Así, para algunos esquemas de rotación los archivos de log se analizarán y se notificarán en su orden original. Para otros esquemas de rotación no se respetará el orden original de los archivos de log, lo que puede provocar que los registros de archivos de log coincidentes se notifiquen en un orden alterado (el problema no ocurre si los archivos de log tienen diferentes horas de última modificación).
• Zabbix agent procesa nuevos registros de un archivo de log una vez cada Update interval segundos.
• Zabbix agent no envía más de maxlines de un archivo de log por segundo. El límite evita la sobrecarga de los recursos de red y CPU y anula el valor predeterminado proporcionado por el parámetro MaxLinesPerSecond en el archivo de configuración del agent.
• Para encontrar la cadena requerida, Zabbix procesará 10 veces más líneas nuevas que las establecidas en MaxLinesPerSecond. Así, por ejemplo, si un item log[] o logrt[] tiene un Update interval de 1 segundo, de forma predeterminada el agent analizará no más de 200 registros de archivo de log y enviará no más de 20 registros coincidentes a Zabbix server en una sola comprobación. Al aumentar MaxLinesPerSecond en el archivo de configuración del agent o establecer el parámetro maxlines en la clave del item, el límite puede incrementarse hasta 10000 registros de archivo de log analizados y 1000 registros coincidentes enviados a Zabbix server en una sola comprobación. Si el Update interval se establece en 2 segundos, los límites para una comprobación serían 2 veces mayores que con un Update interval de 1 segundo.
• Además, los valores de log y log.count siempre están limitados al 50% del tamaño del búfer de envío del agent, incluso si no hay valores que no sean de log en él. Por lo tanto, para que los valores de maxlines se envíen en una sola conexión (y no en varias), el parámetro BufferSize del agent debe ser al menos maxlines x 2. Zabbix agent puede cargar datos durante la recopilación de log y así liberar el búfer, mientras que Zabbix agent 2 detendrá la recopilación de log hasta que los datos se carguen y el búfer se libere, lo cual se realiza de forma asíncrona.
• En ausencia de items de log, todo el tamaño del búfer del agent se usa para valores que no son de log. Cuando llegan valores de log, reemplazan los valores anteriores que no son de log según sea necesario, hasta el 50% designado.
• Para registros de archivo de log de más de 256 kB, solo los primeros 256 kB se comparan con la expresión regular y el resto del registro se ignora. Sin embargo, si Zabbix agent se detiene mientras está procesando un registro largo, el estado interno del agent se pierde y el registro largo puede analizarse de nuevo y de forma diferente después de que el agent se inicie otra vez.
• Nota especial para separadores de ruta "\": si file_format es "file\.log", entonces no debe existir un directorio "file", ya que no es posible definir de forma inequívoca si "." está escapado o si es el primer símbolo del nombre del archivo.
• Las expresiones regulares para logrt solo se admiten en el nombre de archivo; no se admite la coincidencia mediante expresión regular en el directorio.
• En plataformas UNIX un item logrt[] pasa a NOTSUPPORTED si no existe un directorio donde se espera encontrar los archivos de log.
• En Microsoft Windows, si un directorio no existe, el item no pasará a NOTSUPPORTED (por ejemplo, si el directorio está mal escrito en la clave del item).
• La ausencia de archivos de log para el item logrt[] no lo convierte en NOTSUPPORTED. Los errores de lectura de archivos de log para el item logrt[] se registran como advertencias en el archivo de log de Zabbix agent, pero no hacen que el item pase a NOTSUPPORTED.
• El archivo de log de Zabbix agent puede ser útil para averiguar por qué un item log[] o logrt[] pasó a NOTSUPPORTED. Zabbix puede monitorizar el archivo de log de su agent, excepto cuando está en DebugLevel=4 o DebugLevel=5.
• Buscar un signo de interrogación mediante una expresión regular, por ejemplo \?, puede dar falsos positivos si el archivo de texto contiene símbolos NUL, ya que Zabbix los reemplaza por "?" para continuar procesando la línea hasta el carácter de nueva línea.

Extracción de la parte coincidente de una expresión regular

A veces puede que queramos extraer solo el valor de interés de un archivo de destino en lugar de devolver toda la línea cuando se encuentra una coincidencia de expresión regular.

Los items de log tienen la capacidad de extraer los valores deseados de las líneas coincidentes. Esto se consigue mediante el parámetro adicional output en los items log y logrt.

El uso del parámetro 'output' permite indicar el "grupo de captura" de la coincidencia que nos puede interesar.

Así, por ejemplo

log[/path/to/the/file,"large result buffer allocation.*Entries: ([0-9]+)",,,,\1]

debería permitir devolver el recuento de entradas tal como se encuentra en el contenido de:

Fr Feb 07 2014 11:07:36.6690 */ Thread Id 1400 (GLEWF) large result
buffer allocation - /Length: 437136/Entries: 5948/Client Ver: >=10/RPC
ID: 41726453/User: AUser/Form: CFG:ServiceLevelAgreement

Solo se devolverá el número porque \1 hace referencia al primer y único grupo de captura: ([0-9]+).

Y, con la capacidad de extraer y devolver un número, el valor puede utilizarse para definir triggers.

Uso del parámetro maxdelay

El parámetro maxdelay en los items de log permite ignorar algunas líneas más antiguas de los archivos de log para analizar las líneas más recientes dentro de los maxdelay segundos.

De forma predeterminada, los items para la supervisión de logs siguen todas las nuevas líneas que aparecen en los archivos de log. Sin embargo, hay aplicaciones que en algunas situaciones comienzan a escribir una enorme cantidad de mensajes en sus archivos de log. Por ejemplo, si una base de datos o un servidor DNS no está disponible, estas aplicaciones inundan los archivos de log con miles de mensajes de error casi idénticos hasta que se restablece el funcionamiento normal. De forma predeterminada, todos esos mensajes se analizarán diligentemente y las líneas coincidentes se enviarán al server según la configuración de los items log y logrt.

La protección integrada contra sobrecarga consiste en un parámetro configurable maxlines (protege al server de demasiadas líneas de log coincidentes entrantes) y un límite de 10*'maxlines' (protege la CPU y la E/S del host frente a la sobrecarga causada por el agent en una sola comprobación). Aun así, existen 2 problemas con la protección integrada. En primer lugar, se informa al server de una gran cantidad de mensajes potencialmente poco informativos, que consumen espacio en la base de datos. En segundo lugar, debido al número limitado de líneas analizadas por segundo, el agent puede quedarse rezagado respecto a los registros de log más recientes durante horas. Es muy probable que prefiera recibir antes información sobre la situación actual en los archivos de log en lugar de revisar registros antiguos durante horas.

La solución a ambos problemas es usar el parámetro maxdelay. Si se especifica maxdelay > 0, durante cada comprobación se mide el número de bytes procesados, el número de bytes restantes y el tiempo de procesamiento. A partir de estos números, el agent calcula un retraso estimado: cuántos segundos tardaría en analizar todos los registros restantes de un archivo de log.

Si el retraso no supera maxdelay, el agent continúa analizando el archivo de log con normalidad.

Si el retraso es mayor que maxdelay, entonces el agent ignora un fragmento de un archivo de log "saltándolo" a una nueva posición estimada para que las líneas restantes puedan analizarse dentro de maxdelay segundos.

Tenga en cuenta que el agent ni siquiera lee las líneas ignoradas en el búfer, sino que calcula una posición aproximada a la que saltar en un archivo.

El hecho de omitir líneas del archivo de log se registra en el archivo de log del agent de la siguiente manera:

14287:20160602:174344.206 item:"logrt["/home/zabbix32/test[0-9].log",ERROR,,1000,,,120.0]"
logfile:"/home/zabbix32/test1.log" skipping 679858 bytes
(from byte 75653115 to byte 76332973) to meet maxdelay

El número "to byte" es aproximado porque, después del "jump", el agent ajusta la posición en el archivo al comienzo de una línea de log, que puede estar más adelante en el archivo o más atrás.

Dependiendo de cómo se compare la velocidad de crecimiento con la velocidad de análisis del archivo de log, puede que no vea ningún "jump", "jumps" raros o frecuentes, "jumps" grandes o pequeños, o incluso un "jump" pequeño en cada comprobación. Las fluctuaciones en la carga del sistema y la latencia de la red también afectan al cálculo del retraso y, por tanto, al "jump" hacia adelante para mantenerse al día con el parámetro maxdelay.

No se recomienda establecer maxdelay < update interval (puede dar lugar a "jumps" pequeños y frecuentes).

Notas sobre el manejo de la rotación de archivos de registro 'copytruncate'

logrt con la opción copytruncate asume que los distintos archivos de registro tienen registros diferentes (al menos, sus marcas de tiempo son distintas), por lo tanto, las sumas MD5 de los bloques iniciales (hasta los primeros 512 bytes) serán diferentes. Dos archivos con las mismas sumas MD5 de los bloques iniciales significan que uno de ellos es el original y el otro, una copia.

logrt con la opción copytruncate hace un esfuerzo para procesar correctamente las copias de archivos de registro sin informar duplicados. Sin embargo, no se recomiendan situaciones como generar varias copias del archivo de registro con la misma marca de tiempo, rotar el archivo de registro con más frecuencia que el intervalo de actualización del item logrt[], o reiniciar con frecuencia el agent. El agent intenta gestionar todas estas situaciones de forma razonablemente correcta, pero no se pueden garantizar buenos resultados en todas las circunstancias.

Notas sobre archivos persistentes para items log*[]

Propósito de los archivos persistentes

Cuando se inicia Zabbix agent, recibe una lista de comprobaciones activas desde Zabbix server o proxy.
Para las métricas log*[], recibe el tamaño del log procesado y la hora de modificación para determinar desde dónde empezar a supervisar el archivo de log.
Según el tamaño real del archivo de log y la hora de modificación informados por el sistema de archivos, el agent decide si continuar la supervisión del archivo de log desde el tamaño de log procesado o volver a analizar el archivo de log desde el principio.

Un agent en ejecución mantiene un conjunto más amplio de atributos para hacer seguimiento de todos los archivos de log supervisados entre comprobaciones.
Este estado en memoria se pierde cuando el agent se detiene.

El nuevo parámetro opcional persistent_dir especifica un directorio para almacenar este estado del item log[], log.count[], logrt[] o logrt.count[] en un archivo.
El estado del item log se restaura desde el archivo persistente después de reiniciar Zabbix agent.

El caso de uso principal es la supervisión de un archivo de log ubicado en un sistema de archivos reflejado.
Hasta cierto momento, el archivo de log se escribe en ambos espejos.
Luego, los espejos se separan.
En la copia activa, el archivo de log sigue creciendo y recibe nuevos registros.
Zabbix agent lo analiza y envía al server el tamaño del log procesado y la hora de modificación.
En la copia pasiva, el archivo de log permanece igual, muy por detrás de la copia activa.
Más tarde, el sistema operativo y Zabbix agent se reinician desde la copia pasiva.
El tamaño del log procesado y la hora de modificación que Zabbix agent recibe desde el server pueden no ser válidos para la situación en la copia pasiva.
Para continuar la supervisión del archivo de log desde el punto en que el agent se quedó en el momento de la separación del espejo del sistema de archivos, el agent restaura su estado desde el archivo persistente.

Operación del agent con archivo persistente

Al iniciarse, el agent de Zabbix no sabe nada sobre los archivos persistentes. Solo después de recibir una lista de comprobaciones activas desde el server de Zabbix (proxy), el agent ve que algunos items de log deben respaldarse con archivos persistentes en directorios especificados.

Durante la operación del agent, los archivos persistentes se abren para escritura (con fopen(filename, "w")) y se sobrescriben con los datos más recientes. La probabilidad de perder datos del archivo persistente si la sobrescritura y la división del espejo del sistema de archivos ocurren al mismo tiempo es muy pequeña; no se requiere un tratamiento especial para ello. La escritura en el archivo persistente NO va seguida de una sincronización forzada con el medio de almacenamiento (fsync() no se llama).

La sobrescritura con los datos más recientes se realiza después de informar correctamente al server de Zabbix sobre el registro del archivo de log coincidente o los metadatos (tamaño de log procesado y tiempo de modificación). Eso puede ocurrir tan a menudo como en cada comprobación del item si el archivo de log sigue cambiando.

No se realizan acciones especiales durante el apagado del agent.

Después de recibir una lista de comprobaciones activas, el agent marca los archivos persistentes obsoletos para su eliminación. Un archivo persistente se vuelve obsoleto si:

1. El log item correspondiente ya no se supervisa.
2. Un log item se reconfigura con una ubicación persistent_dir diferente a la anterior.

La eliminación se realiza con un retraso de 24 horas porque los archivos de registro en estado NOTSUPPORTED no se incluyen en la lista de comprobaciones activas, pero pueden pasar a SUPPORTED más adelante y sus archivos persistentes serán útiles.

Si el agent se detiene antes de que transcurran 24 horas, entonces los archivos obsoletos no se eliminarán, ya que Zabbix agent ya no recibe información sobre su ubicación desde Zabbix server.

Nomenclatura y ubicación de los archivos persistentes

Zabbix agent distingue las comprobaciones activas por sus claves. Por ejemplo, logrt[/home/zabbix/test.log] y logrt[/home/zabbix/test.log,] son items diferentes. Modificar el item logrt[/home/zabbix/test.log,,,10] en el frontend a logrt[/home/zabbix/test.log,,,20] dará como resultado la eliminación del item logrt[/home/zabbix/test.log,,,10] de la lista de comprobaciones activas del agent y la creación del item logrt[/home/zabbix/test.log,,,20] (algunos atributos se conservan durante la modificación en el frontend/server, pero no en el agent).

El nombre del archivo se compone de la suma MD5 de la clave del item con la longitud de la clave del item añadida al final para reducir la posibilidad de colisiones. Por ejemplo, el estado del item logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] se conservará en el archivo persistente c963ade4008054813bbc0a650bb8e09266.

Varios items de log pueden usar el mismo valor de persistent_dir.

persistent_dir se especifica teniendo en cuenta diseños concretos del sistema de archivos, puntos de montaje y opciones de montaje, así como la configuración de espejado del almacenamiento: el archivo persistente debe estar en el mismo sistema de archivos espejado que el archivo de log monitorizado.

Si el directorio persistent_dir no puede crearse o no existe, o si los permisos de acceso para Zabbix agent no permiten crear/escribir/leer/eliminar archivos, el item de log pasa a ser NOTSUPPORTED.

Si se eliminan los permisos de acceso a los archivos de almacenamiento persistente durante el funcionamiento del agent o se producen otros errores (por ejemplo, disco lleno), los errores se registran en el archivo de registro del agent, pero el item de registro no pasa a NOTSUPPORTED.

Carga en I/O

El archivo persistente del item se actualiza después del envío correcto de cada lote de datos (que contiene los datos del item) al server. Por ejemplo, el valor predeterminado de BufferSize es 100. Si un item de log ha encontrado 70 registros coincidentes, entonces los primeros 50 registros se enviarán en un lote, el archivo persistente se actualizará, luego los 20 registros restantes se enviarán (tal vez con algún retraso cuando se acumule más datos) en el segundo lote, y el archivo persistente se actualizará nuevamente.

Acciones si falla la comunicación entre agent y server

Cada línea coincidente de log[] y logrt[] y el resultado de cada comprobación de log.count[] y logrt.count[] requiere un espacio libre en el área designada del 50% en el búfer de envío del agent. Los elementos del búfer se envían regularmente al server (o proxy) y los espacios del búfer vuelven a quedar libres.

Mientras haya espacios libres en el área designada de logs en el búfer de envío del agent y falle la comunicación entre agent y server (o proxy), los resultados de monitorización de logs se acumulan en el búfer de envío. Esto ayuda a mitigar fallos de comunicación breves.

Durante fallos de comunicación más prolongados, todos los espacios de logs se ocupan y se toman las siguientes acciones:

• Las comprobaciones de los items log[] y logrt[] se detienen. Cuando se restablece la comunicación y hay espacios libres disponibles en el búfer, las comprobaciones se reanudan desde la posición anterior. No se pierden líneas coincidentes, solo se informan más tarde.
• Las comprobaciones de log.count[] y logrt.count[] se detienen si maxdelay = 0 (valor predeterminado). El comportamiento es similar al de los items log[] y logrt[] descritos arriba. Tenga en cuenta que esto puede afectar a los resultados de log.count[] y logrt.count[]: por ejemplo, una comprobación cuenta 100 líneas coincidentes en un archivo de log, pero como no hay espacios libres en el búfer, la comprobación se detiene. Cuando se restablece la comunicación, el agent cuenta las mismas 100 líneas coincidentes y también 70 nuevas líneas coincidentes. Ahora el agent envía count = 170 como si se hubieran encontrado en una sola comprobación.
• Las comprobaciones de log.count[] y logrt.count[] con maxdelay > 0: si no hubo un "salto" durante la comprobación, el comportamiento es similar al descrito arriba. Si se produjo un "salto" sobre líneas del archivo de log, se conserva la posición después del "salto" y se descarta el resultado contado. Así, el agent intenta mantenerse al día con un archivo de log en crecimiento incluso en caso de fallo de comunicación.

Manejo de errores de compilación y de ejecución de expresiones regulares

Si una expresión regular utilizada en un item log[], logrt[], log.count[] o logrt.count[] no puede ser compilada por la biblioteca PCRE o PCRE2, entonces el item pasa al estado NOTSUPPORTED con un mensaje de error. Para continuar supervisando el item de log, se debe corregir la expresión regular.

Si la expresión regular se compila correctamente, pero falla en tiempo de ejecución (en algunos o en todos los registros de log), entonces el item de log permanece soportado y la supervisión continúa. El error en tiempo de ejecución se registra en el archivo de log del agent de Zabbix (sin el registro del archivo de log).

La tasa de registro está limitada a un error en tiempo de ejecución por comprobación para permitir que el agent de Zabbix supervise su propio archivo de log. Por ejemplo, si se analizan 10 registros y 3 registros fallan con un error de ejecución de regexp, se genera un registro en el log del agent.

Excepción: si MaxLinesPerSecond=1 y el intervalo de actualización=1 (solo se permite analizar 1 registro por comprobación), entonces los errores de ejecución de regexp no se registran.

zabbix_agentd registra la clave del item en caso de un error en tiempo de ejecución, zabbix_agent2 registra el ID del item para ayudar a identificar qué item de log tiene errores en tiempo de ejecución. Se recomienda rediseñar la expresión regular en caso de errores en tiempo de ejecución.