6 Monitoreo de archivos de registro

Descripción general

Zabbix puede utilizarse para la monitorización y el análisis centralizados de archivos de registro con o sin soporte para rotación de registros.

Se pueden utilizar notificaciones para advertir a los usuarios cuando un archivo de registro contiene ciertas cadenas o patrones de cadenas.

Para monitorizar un archivo de registro debe tener:

• El agente de Zabbix ejecutándose en el equipo
• Un elemento de monitorización de registros configurado

Configuración

Verificar los parámetros del agente

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

• El parámetro Hostname coincida con el nombre del equipo en la interfaz web.
• Los servidores en el parámetro ServerActive estén especificados para el procesamiento de comprobaciones activas.

Configuración de la métrica

Configure una métrica de monitoreo de registro.

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

Específicamente para las métricas de monitoreo de registros, introduzca:

Notas importantes

• El servidor y el agente mantienen el seguimiento del tamaño de un registro monitorizado y la última hora de modificación (para logrt) en dos contadores. Adicionalmente:
  • El agente también utiliza internamente números de inodo (en UNIX/GNU/Linux), índices de archivo (en Microsoft Windows) y sumas MD5 de los primeros 512 bytes del archivo de registro para mejorar las decisiones cuando los archivos de registro se truncan y rotan.
  • En sistemas UNIX/GNU/Linux se asume que los sistemas de archivos donde se almacenan los archivos de registro informan números de inodo, que pueden usarse para rastrear archivos.
  • En Microsoft Windows, el agente Zabbix determina el tipo de sistema de archivos en el que residen los archivos de registro y utiliza:
    • 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 utiliza un algoritmo alternativo para tomar un enfoque sensato en condiciones inciertas cuando la rotación de archivos de registro da como resultado varios archivos de registro con la misma hora de última modificación.
  • Los números de inodo, los índices de archivo y las sumas MD5 son recopilados internamente por el agente Zabbix. No se transmiten al servidor Zabbix y se pierden cuando se detiene el agente Zabbix.
  • No modifique la hora de última modificación de un archivo de registro (por ejemplo, con touch), y no reemplace un archivo de registro monitorizado copiando un archivo de nuevo a su nombre original (esto crea un nuevo inodo). En cualquier caso, 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 registro coincidentes para el elemento logrt[] y el agente Zabbix está siguiendo el más reciente de ellos y este archivo de registro más reciente se elimina, se registra un mensaje de advertencia "no hay archivos que coincidan con "<regexp mask>" en "<directory>". El agente Zabbix ignora los archivos de registro con una hora de modificación menor que la última hora de modificación vista por el agente para el elemento logrt[] que se está comprobando.
• El agente comienza a leer el archivo de registro desde el punto en que se detuvo la vez anterior.
• El número de bytes ya analizados (el contador de tamaño) y la última hora de modificación (el contador de tiempo) se almacenan en la base de datos de Zabbix y se envían al agente para asegurarse de que el agente comience a leer el archivo de registro desde este punto en los casos en que el agente acaba de iniciarse o ha recibido elementos que anteriormente estaban deshabilitados o no eran compatibles. Sin embargo, si el agente ha recibido un contador de tamaño distinto de cero del servidor, pero el elemento 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 registro se vuelva más pequeño que el contador de tamaño conocido por el agente, el contador se restablece a cero y el agente comienza a leer el archivo de registro 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 agente intenta analizar correctamente todos los archivos de registro con la misma hora de modificación y evitar omitir datos o analizar los mismos datos dos veces, aunque no se puede garantizar en todas las situaciones. El agente no asume ningún esquema particular de rotación de archivos de registro ni determina uno. Cuando se presentan varios archivos de registro con la misma hora de última modificación, el agente los procesará en orden lexicográfico descendente. Así, para algunos esquemas de rotación, los archivos de registro se analizarán e informarán en su orden original. Para otros esquemas de rotación, no se respetará el orden original de los archivos de registro, lo que puede llevar a informar registros de archivos de registro coincidentes en un orden alterado (el problema no ocurre si los archivos de registro tienen diferentes horas de última modificación).
• El agente Zabbix procesa nuevos registros de un archivo de registro una vez por cada intervalo de actualización de segundos.
• El agente Zabbix no envía más de maxlines de un archivo de registro por segundo. El límite evita la sobrecarga de recursos de red y CPU y anula el valor predeterminado proporcionado por el parámetro MaxLinesPerSecond en el archivo de configuración del agente.
• Para encontrar la cadena requerida, Zabbix procesará 10 veces más líneas nuevas que las establecidas en MaxLinesPerSecond. Así, por ejemplo, si un elemento log[] o logrt[] tiene un intervalo de actualización de 1 segundo, por defecto el agente analizará no más de 200 registros de archivos de registro y enviará no más de 20 registros coincidentes al servidor Zabbix en una comprobación. Al aumentar MaxLinesPerSecond en el archivo de configuración del agente o establecer el parámetro maxlines en la clave del elemento, el límite puede aumentarse hasta 10000 registros de archivos de registro analizados y 1000 registros coincidentes enviados al servidor Zabbix en una comprobación. Si el intervalo de actualización se establece en 2 segundos, los límites para una comprobación se establecerán 2 veces más altos que con un intervalo de actualización 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 agente, incluso si no hay valores que no sean de registro en él. Por lo tanto, para que los valores maxlines se envíen en una sola conexión (y no en varias conexiones), el parámetro BufferSize del agente debe ser al menos maxlines x 2. El agente Zabbix puede cargar datos durante la recopilación de registros y así liberar el búfer, mientras que el agente Zabbix 2 detendrá la recopilación de registros hasta que los datos se carguen y el búfer se libere, lo que se realiza de forma asíncrona.
• En ausencia de elementos de registro, todo el tamaño del búfer del agente se utiliza para valores que no son de registro. Cuando llegan valores de registro, reemplazan los valores anteriores que no son de registro según sea necesario, hasta el 50% designado.
• Para los registros de archivos de registro 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 el agente Zabbix se detiene mientras está tratando con un registro largo, el estado interno del agente se pierde y el registro largo puede analizarse nuevamente y de manera diferente después de que el agente se inicie nuevamente.
• Nota especial para los separadores de ruta "\": si file_format es "file\.log", entonces no debe haber un directorio "file", ya que no es posible definir de manera inequívoca si "." está escapado o 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 de expresiones regulares en el directorio.
• En plataformas UNIX, un elemento logrt[] se vuelve NOTSUPPORTED si no existe un directorio donde se espera encontrar los archivos de registro.
• En Microsoft Windows, si un directorio no existe, el elemento no se volverá NOTSUPPORTED (por ejemplo, si el directorio está mal escrito en la clave del elemento).
• La ausencia de archivos de registro para el elemento logrt[] no lo hace NOTSUPPORTED. Los errores de lectura de archivos de registro para el elemento logrt[] se registran como advertencias en el archivo de registro del agente Zabbix, pero no hacen que el elemento sea NOTSUPPORTED.
• El archivo de registro del agente Zabbix puede ser útil para averiguar por qué un elemento log[] o logrt[] se volvió NOTSUPPORTED. Zabbix puede monitorizar su archivo de registro de agente, excepto cuando está en DebugLevel=4 o DebugLevel=5.
• Buscar un signo de interrogación usando una expresión regular, por ejemplo, \? puede resultar en falsos positivos si el archivo de texto contiene símbolos NUL, ya que estos son reemplazados por "?" por Zabbix para continuar procesando la línea hasta el carácter de nueva línea.

Extrayendo la parte coincidente de una expresión regular

A veces podemos querer extraer solo el valor interesante de un archivo de destino en lugar de devolver toda la línea cuando se encuentra una coincidencia de expresión regular.

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

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

Así, por ejemplo

log[/ruta/al/archivo,"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 se refiere al primer y único grupo de captura: ([0-9]+).

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

Uso del parámetro maxdelay

El parámetro maxdelay en los elementos de registro permite ignorar algunas líneas antiguas de los archivos de registro para que se analicen las líneas más recientes dentro de los segundos especificados en maxdelay.

Por defecto, los elementos para la monitorización de registros siguen todas las nuevas líneas que aparecen en los archivos de registro. Sin embargo, hay aplicaciones que en algunas situaciones comienzan a escribir una enorme cantidad de mensajes en sus archivos de registro. Por ejemplo, si una base de datos o un servidor DNS no están disponibles, dichas aplicaciones saturan los archivos de registro con miles de mensajes de error casi idénticos hasta que se restablece el funcionamiento normal. Por defecto, todos esos mensajes serán analizados y las líneas coincidentes enviadas al servidor según lo configurado en los elementos log y logrt.

La protección incorporada contra sobrecarga consiste en un parámetro configurable maxlines (protege al servidor de demasiadas líneas de registro coincidentes entrantes) y un límite de 10*'maxlines' (protege la CPU y E/S del host de sobrecarga por parte del agente en una comprobación). Aun así, existen 2 problemas con la protección incorporada. Primero, se informan al servidor una gran cantidad de mensajes potencialmente poco informativos y consumen espacio en la base de datos. Segundo, debido al número limitado de líneas analizadas por segundo, el agente puede quedarse atrás respecto a los registros más recientes durante horas. Es muy probable que prefiera ser informado antes sobre la situación actual en los archivos de registro 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 agente calcula un retraso estimado: cuántos segundos tomaría analizar todos los registros restantes en un archivo de registro.

Si el retraso no supera maxdelay, el agente continúa analizando el archivo de registro como de costumbre.

Si el retraso es mayor que maxdelay, el agente ignora una parte del archivo de registro "saltando" sobre ella hasta una nueva posición estimada para que las líneas restantes puedan analizarse dentro de los segundos especificados en maxdelay.

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

El hecho de omitir líneas del archivo de registro se registra en el archivo de registro del agente 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 "salto" el agente ajusta la posición en el archivo al comienzo de una línea de registro, que puede estar más adelante o más atrás en el archivo.

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

No se recomienda establecer maxdelay < intervalo de actualización (puede resultar en "saltos" 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 diferentes archivos de registro tienen diferentes registros (al menos sus marcas de tiempo son diferentes), 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 significa que uno de ellos es el original y el otro una copia.

logrt con la opción copytruncate se esfuerza por procesar correctamente las copias de archivos de registro sin informar duplicados. Sin embargo, no se recomienda realizar cosas como producir múltiples copias de archivos de registro con la misma marca de tiempo, rotar el archivo de registro con más frecuencia que el intervalo de actualización del elemento logrt[], o reiniciar el agente con frecuencia. El agente intenta manejar todas estas situaciones razonablemente bien, pero no se pueden garantizar buenos resultados en todas las circunstancias.

Notas sobre archivos persistentes para elementos log*[]

Propósito de los archivos persistentes

Cuando se inicia el agente Zabbix, recibe una lista de comprobaciones activas del servidor o proxy de Zabbix. Para las métricas log*[], recibe el tamaño del registro procesado y la hora de modificación para determinar desde dónde comenzar la monitorización del archivo de registro. Dependiendo del tamaño real del archivo de registro y la hora de modificación informados por el sistema de archivos, el agente decide si continúa la monitorización del archivo de registro desde el tamaño procesado o si vuelve a analizar el archivo de registro desde el principio.

Un agente en ejecución mantiene un conjunto más amplio de atributos para rastrear todos los archivos de registro monitorizados entre comprobaciones. Este estado en memoria se pierde cuando se detiene el agente.

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

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

Funcionamiento del agente con archivo persistente

Al iniciar, el agente Zabbix no sabe nada sobre archivos persistentes. Solo después de recibir una lista de comprobaciones activas del servidor Zabbix (proxy), el agente ve que algunos elementos de registro deben estar respaldados por archivos persistentes en los directorios especificados.

Durante el funcionamiento del agente, los archivos persistentes se abren para escritura (con fopen(filename, "w")) y se sobrescriben con los datos más recientes. La posibilidad 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 realiza un manejo especial para ello. La escritura en el archivo persistente NO va seguida de una sincronización forzada con el medio de almacenamiento (no se llama a fsync()).

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

No se realizan acciones especiales durante el apagado del agente.

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:

• El item de log correspondiente ya no se monitoriza;
  • 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 ser SUPPORTED más adelante y sus archivos persistentes serán útiles.

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

Nombres y ubicación de los archivos persistentes

El agente Zabbix distingue las comprobaciones activas por sus claves. Por ejemplo, logrt[/home/zabbix/test.log] y logrt[/home/zabbix/test.log,] son elementos diferentes. Modificar el elemento logrt[/home/zabbix/test.log,,,10] en la interfaz a logrt[/home/zabbix/test.log,,,20] resultará en la eliminación del elemento logrt[/home/zabbix/test.log,,,10] de la lista de comprobaciones activas del agente y la creación del elemento logrt[/home/zabbix/test.log,,,20] (algunos atributos se mantienen durante la modificación en la interfaz/servidor, no en el agente).

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

Varios elementos de registro pueden usar el mismo valor de persistent_dir.

persistent_dir se especifica teniendo en cuenta diseños específicos del sistema de archivos, puntos de montaje y opciones de montaje y la configuración de replicación de almacenamiento: el archivo persistente debe estar en el mismo sistema de archivos replicado que el archivo de registro monitorizado.

Si el directorio persistent_dir no puede crearse o no existe, o los derechos de acceso para el agente Zabbix no permiten crear/escribir/leer/eliminar archivos, el elemento de registro pasa a ser NO SOPORTADO.

Si se eliminan los derechos de acceso a los archivos de almacenamiento persistente durante el funcionamiento del agente o se producen otros errores (por ejemplo, disco lleno), los errores se registran en el archivo de registro del agente, pero el elemento de registro no pasa a ser NO SOPORTADO.

Carga en E/S

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

Acciones si falla la comunicación entre el agente y el servidor

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

Mientras haya espacios libres en el área designada de logs en el búfer de envío del agente y falle la comunicación entre el agente y el servidor (o proxy), los resultados del monitoreo 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 prolongados, todos los espacios de logs se ocupan y se toman las siguientes acciones:

• Se detienen las comprobaciones de los elementos log[] y logrt[]. Cuando se restablece la comunicación y hay espacios libres 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 log.count[] y logrt.count[] se detienen si maxdelay = 0 (por defecto). El comportamiento es similar al de los elementos log[] y logrt[] como se describe arriba. Tenga en cuenta que esto puede afectar 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 agente cuenta las mismas 100 líneas coincidentes y también 70 nuevas líneas coincidentes. El agente ahora envía count = 170 como si se hubieran encontrado en una sola comprobación.
• Comprobaciones log.count[] y logrt.count[] con maxdelay > 0: si no hubo un "salto" durante la comprobación, entonces el comportamiento es similar al descrito anteriormente. Si se produjo un "salto" sobre líneas del archivo de log, entonces se mantiene la posición después del "salto" y se descarta el resultado contado. Por lo tanto, el agente 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 los elementos log[], logrt[], log.count[] o logrt.count[] no puede ser compilada por la biblioteca PCRE o PCRE2, el elemento pasa al estado NO SOPORTADO con un mensaje de error. Para continuar monitorizando el elemento de log, la expresión regular debe corregirse.

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 elemento de log permanece soportado y la monitorización continúa. El error de ejecución se registra en el archivo de log del agente Zabbix (sin el registro del archivo de log).

La tasa de registro está limitada a un error de ejecución por comprobación para permitir que el agente Zabbix monitorice su propio archivo de log. Por ejemplo, si se analizan 10 registros y 3 registros fallan con un error de ejecución de expresión regular, se produce un registro en el log del agente.

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

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