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 de 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 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), IDs 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 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 la ú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 antes 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. Por lo tanto, para algunos esquemas de rotación los archivos de log se analizarán y 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 coincidentes de los archivos de log 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 los 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 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 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 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 256kB, solo los primeros 256kB 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 con expresiones regulares en el directorio.
• En plataformas UNIX, un item logrt[] pasa a ser 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 ser 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 sea NOTSUPPORTED.
• El archivo de log de Zabbix agent puede ser útil para averiguar por qué un item log[] o logrt[] pasó a ser 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 lugar a 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.

Por ejemplo:

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

debería permitir devolver el recuento de entradas encontrado 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 que las líneas más recientes se analicen 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 DNS server no está disponible, esas 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 tal como se configuró en 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 y estos 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, entonces el agent continúa analizando el archivo de log como de costumbre.

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, es posible que no vea ningún "jump", "jumps" poco frecuentes 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 red también afectan al cálculo del retraso y, por tanto, al "jumping" 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 con '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 por procesar correctamente las copias de archivos de registro sin informar duplicados. Sin embargo, no se recomiendan cosas 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 agent con frecuencia. El agent intenta manejar todas estas situaciones de forma razonable, 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 la supervisión del 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 de 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 espejado. 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 el tamaño del log procesado y la hora de modificación a server. En la copia pasiva, el archivo de log permanece igual, bastante 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 de 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, Zabbix agent no sabe nada acerca de los archivos persistentes. Solo después de recibir una lista de comprobaciones activas desde Zabbix server (proxy), el agent detecta 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.

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 a Zabbix server sobre el registro del archivo de log coincidente o los metadatos (tamaño del log procesado y hora de modificación). Esto 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 correspondiente item de log ya no se supervisa.
2. Un item de log 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 log 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.

Denominación 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 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 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 mantendrá 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 una ranura 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 las ranuras del búfer vuelven a quedar libres.

Mientras haya ranuras 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 la 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, todas las ranuras de logs se ocupan y se toman las siguientes acciones:

• Las comprobaciones de log[] y logrt[] se detienen. Cuando se restablece la comunicación y hay ranuras libres disponibles en el búfer, las comprobaciones se reanudan desde la posición anterior. No se pierden líneas coincidentes; simplemente 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 anteriormente. 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 ranuras 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 ningún "salto" durante la comprobación, el comportamiento es similar al descrito anteriormente. Si se produjo un "salto" sobre líneas del archivo de log, se conserva la posición después del "salto" y el resultado contado se descarta. 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.