6 Monitorización de archivos de registro

Descripción general

Zabbix puede utilizarse para la monitorización centralizada y el análisis 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 monitorización de logs.

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

Específicamente para las métricas de monitorización de logs debe introducir:

Notas importantes

• El servidor y el agente mantienen el seguimiento del tamaño de un registro monitoreado 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), identificadores 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 del archivo 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 monitoreado copiando un archivo de nuevo a su nombre original (esto crea un nuevo inodo). 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 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 previamente 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 de 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 Zabbix agent 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 más antiguos 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 del archivo, no se admite la coincidencia de expresiones regulares en el directorio.
• En plataformas UNIX, un elemento logrt[] se convierte en 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 convertirá en 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 convierte en 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 convirtió en NOTSUPPORTED. Zabbix puede monitorear 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 sobrecargas 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 que consumen espacio en la base de datos. Segundo, debido al número limitado de líneas analizadas por segundo, el agente puede quedarse rezagado 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 procede a analizar 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 a 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 se compare la velocidad de crecimiento 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, los valores MD5 de los bloques iniciales (hasta los primeros 512 bytes) serán diferentes. Dos archivos con los mismos valores 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 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 métricas 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 del registro procesado 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 lugar donde 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(nombre_archivo, "w")) y se sobrescriben con los datos más recientes. La posibilidad de perder datos del archivo persistente si la sobrescritura y la separació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 el 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 con tanta frecuencia 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 agente marca los archivos persistentes obsoletos para su eliminación. Un archivo persistente se vuelve obsoleto si: 1) el elemento de registro correspondiente ya no se monitoriza, 2) un elemento de registro 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 ser SUPPORTED más adelante y sus archivos persistentes serán útiles.

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

Nomenclatura y ubicación de archivos persistentes

El agente de 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 ser creado o no existe, o los derechos de acceso para el agente de Zabbix no permiten crear/escribir/leer/eliminar archivos, el elemento de registro se convierte en 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 registros en el búfer de envío del agente y falle la comunicación entre el agente y el servidor (o proxy), los resultados de la monitorización de registros 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 registro 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 de 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 a los resultados de log.count[] y logrt.count[]: por ejemplo, una comprobación cuenta 100 líneas coincidentes en un archivo de registro, 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 de 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 registro, 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 registro 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 monitoreando el elemento 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 elemento de log permanece soportado y el monitoreo 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 verificación para permitir que el agente Zabbix monitoree 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 y el intervalo de actualización=1 (solo se permite analizar 1 registro por verificación), entonces los errores de ejecución de expresiones regulares no se registran.

zabbix_agentd registra la clave del elemento en caso de un 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.