6 Monitoreo de archivos de registro

Visión general

Zabbix se puede usar para el monitoreo y análisis centralizados de archivos de registro con/sin soporte de rotación de registros.

Las notificaciones se pueden utilizar para advertir a los usuarios cuando un archivo de registro contiene ciertos cuerdas o patrones de cuerdas.

Para monitorear un archivo de registro debe tener:

• Agente Zabbix ejecutándose en el host
• configuración del elemento de monitoreo de registro

Configuración

Verificar los parámetros del agente

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

• El parámetro 'Hostname' coincide con el nombre de host en la interfaz
• Los servidores en el parámetro 'ServerActive' se especifican para el procesamiento de cheques activos

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 monitoreado y el tiempo de última 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 el mismo tiempo 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 el tiempo de última modificación de los archivos de registro con la utilidad 'touch', no copie un archivo de registro con posterior restauración del nombre original (esto cambiará el número de inodo del archivo). En ambos casos, el archivo se contará como diferente y se analizará desde el principio, lo que puede resultar en 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 un tiempo de modificación menor que el tiempo de modificación más reciente visto 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 el tiempo de última 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 el mismo tiempo de última modificación en el directorio, entonces el agente intenta analizar correctamente todos los archivos de registro con el mismo tiempo 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 el mismo tiempo de última modificación, el agente los procesará en orden lexicográfico descendente. Por lo tanto, 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 tiempos 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 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 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 de archivo, no se admite la coincidencia de expresiones regulares de directorio.
• En plataformas UNIX, un elemento logrt[] se convierte en NO SOPORTADO 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 NO SOPORTADO (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 NO SOPORTADO. 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 NO SOPORTADO.
• El archivo de registro del agente Zabbix puede ser útil para averiguar por qué un elemento log[] o logrt[] se volvió NO SOPORTADO. 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 la expresión regular

A veces es posible que queramos extraer sólo el valor interesante de un archivo de destino en lugar de devolver la línea completa cuando un normal Se encuentra una coincidencia de expresión.

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

El uso del parámetro 'salida' permite indicar el "grupo de captura" de el partido que nos puede interesar.

Así por ejemplo

log[/ruta/al/archivo,"asignación de búfer de resultados grandes.*Entradas: ([0-9]+)",,,,\1]

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

Viernes 07 de febrero de 2014 11:07:36.6690 */ ID de hilo 1400 (GLEWF) resultado grande
       asignación de búfer - /Longitud: 437136/Entradas: 5948/Versión del cliente: >=10/RPC
       ID: 41726453/Usuario: AUser/Formulario: CFG:ServiceLevelAgreement

Sólo se devolverá el número porque \1 se refiere al primero y solo capturando grupo: ([0-9]+).

Y, con la capacidad de extraer y devolver un número, el valor puede ser Se utiliza para definir desencadenantes.

Usando el parámetro maxdelay

El parámetro 'maxdelay' en las métricas de registro permite ignorar algunas líneas más antiguas de los archivos de registro para obtener las líneas más recientes analizadas dentro del número de segundos de 'maxdelay'.

De forma predeterminada, las métricas para la supervisión de registros siguen todas las líneas nuevas 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á disponible, dichas aplicaciones inundan sus 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 líneas diligentemente analizadas y coincidentes enviadas al servidor según lo configurado en las métricas log y logrt.

La protección incorporada contra sobrecarga consiste en un parámetro configurable 'maxlines' (protege el servidor de demasiadas líneas de registro entrantes con coincidencias ) y un límite de 10*'maxlines' (protege la CPU del equipo y la E/S de sobrecarga por el agente en una única comprobación). Aún así, hay 2 problemas con la protección incorporada. En primer lugar, un gran número de posibles mensajes no tan informativos se envían al servidor y consumen espacio en la base de datos. En segundo lugar, debido al número limitado de líneas analizadas por segundo, el agente puede retrasarse con respecto a los registros más recientes durante horas. Es probable que prefiera estar informado antes sobre la situación actual en los archivos de registro en lugar de rastrear registros antiguos durante horas.

La solución a ambos problemas es utilizar el parámetro 'maxdelay'. Si se especifica 'maxdelay' > 0, durante cada verificació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 todas las líneas restantes en un archivo de registro?.

Si el retraso no excede 'maxdelay' entonces el agente continúa analizando el archivo de registro como de costumbre.

Si el retraso es mayor que 'maxdelay' entonces el agente ignora una porción de un archivo de registro "saltando" sobre él a una nueva posición estimada para que las líneas restantes podrían analizarse en los segundos indicados por 'maxdelay'.

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

El hecho de omitir líneas del archivo de registro se registra en el archivo de registro del agente de esta forma:

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 "a 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 en el archivo o antes.

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

No se recomienda configurar 'maxdelay' < 'intervalo de actualización' (puede resultar en pequeños "saltos" frecuentes).

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

logrt con la opción copytruncate asume que diferentes archivos de registro tienen registros diferentes (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 diferente. Dos archivos con las mismas sumas MD5 de bloques iniciales significa que uno de ellos es el original, otro - una copia.

logrt con la opción copytruncate se esfuerza por procesar correctamente registrar copias de archivos sin reportar duplicados. Sin embargo, cosas como producir múltiples copias de archivos de registro con la misma marca de tiempo, archivo de registro rotación con más frecuencia que logrt[] intervalo de actualización del elemento, frecuente no se recomienda reiniciar el agente. El agente trata de manejar todo 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 cheques activos de Zabbix servidor o proxy. Para las métricas log*[], recibe el tamaño del registro procesado y el tiempo de modificación para encontrar desde dónde iniciar la supervisión del archivo de registro. Según el tamaño real del archivo de registro y el tiempo de modificación informado por el archivo sistema, el agente decide continuar con la supervisión del archivo de registro desde el tamaño del registro procesado o vuelva a analizar el archivo de registro desde el principio.

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

El nuevo parámetro opcional persistent_dir especifica un directorio para almacenar este estado del elemento 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 la Se reinicia el agente Zabbix.

El caso de uso principal es la supervisión del archivo de registro ubicado en un archivo reflejado sistema. Hasta algún momento en el tiempo, el archivo de registro se escribe en ambos espejos. Después los espejos estan partidos. En la copia activa, el archivo de registro sigue creciendo, obteniendo nuevos registros El agente de Zabbix lo analiza y envía el tamaño de los registros procesados y tiempo 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 son reiniciado desde la copia pasiva. El tamaño del registro procesado y el tiempo de modificación. el agente Zabbix recibe del servidor puede no ser válido para la situación en el copia pasiva. Para continuar con la supervisión del archivo de registro desde el lugar que dejó el agente apagado en el momento de la división del espejo del sistema de archivos, el agente restaura su estado desde el archivo persistente.

Operación del agente con archivo persistente

En el inicio, el agente Zabbix no sabe nada acerca de los archivos persistentes. Solo después Al recibir una lista de cheques activos del servidor Zabbix (proxy), el agente ve que algunos registros los elementos deben estar respaldados por archivos persistentes en directorios específicos.

Durante la operación del agente, los archivos persistentes se abren para escritura (con fopen (nombre de archivo, "w")) y sobrescrito con los datos más recientes. la oportunidad de perder datos de archivos persistentes si la sobrescritura y el espejo del sistema de archivos se dividen suceder al mismo tiempo es muy pequeño, no hay un manejo especial para ello. Escritura en un archivo persistente NO va seguido de una sincronización forzada con el almacenamiento media (fsync() no se llama).

La sobrescritura con los datos más recientes se realiza después de informar con éxito la coincidencia registro de archivo de registro o metadatos (tamaño de registro procesado y tiempo de modificación) a Servidor Zabbix. Eso puede suceder tan a menudo como cada elemento verifica si el archivo de registro se mantiene. cambiando.

Sin acciones especiales durante el apagado del agente.

Después de recibir una lista de cheques activos, el agente marca obsoletos persistentes archivos para su eliminación. Un archivo persistente se vuelve obsoleto si: 1) el correspondiente el elemento de registro ya no se supervisa, 2) un elemento de registro se reconfigura con un elemento diferente persistent_dir ubicación que antes.

La eliminación se realiza con un retraso de 24 horas porque los archivos de registro se encuentran en un estado NO COMPATIBLE no están incluidos en la lista de cheques activos, pero pueden convertirse en COMPATIBLES más tarde y sus archivos persistentes serán útiles.

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

::: nota de advertencia Reconfigurar el persistent_dir de un elemento de registro de nuevo al antiguo persistent_dir ubicación mientras el agente está detenido, sin eliminar el antiguo archivo persistente por usuario: hará que se restablezca el estado del agente del antiguo archivo persistente que genera mensajes perdidos o alertas falsas. :::

Denominación y ubicación de archivos persistentes

El agente de Zabbix distingue los cheques activos por sus claves. Por ejemplo, logrt[/home/zabbix/test.log] y logrt[/home/zabbix/test.log,] son artículos diferentes Modificando el ítem logrt[/home/zabbix/test.log,,,10] en frontend a logrt[/home/zabbix/test.log,,,20] resultará en la eliminación del item logrt[/home/zabbix/test.log,,,10] de la lista de cheques activos del agente y creando logrt[/home/zabbix/test.log,,,20] elemento (algunos atributos son realizado a través de 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 adjunta para reducir la posibilidad de colisiones. Por ejemplo, el estado de logrt[/home/zabbix50/test.log,,,,,,,,/home/zabbix50/agent_private] elemento mantenerse en el archivo persistente c963ade4008054813bbc0a650bb8e09266.

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

persistent_dir se especifica teniendo en cuenta el sistema de archivos específico diseños, puntos de montaje y opciones de montaje y configuración de duplicación de almacenamiento - el archivo persistente debe estar en el mismo sistema de archivos reflejado que el monitoreado archivo de registro.

Si el directorio persistent_dir no se puede crear o no existe, o acceda derechos para el agente de Zabbix no permite crear/escribir/leer/eliminar archivos el elemento de registro pasa a ser NO COMPATIBLE.

Si se eliminan los derechos de acceso a los archivos de almacenamiento persistente durante la operación del agente o se producen otros errores (por ejemplo, disco lleno), los errores se registran en el registro del agente pero el elemento de registro no pasa a ser NOTSUPPORTED.

Carga en E/S

El archivo persistente del artículo se actualiza después del envío exitoso de cada lote de datos (que contienen los datos del elemento) al servidor. Por ejemplo, predeterminado 'BufferSize' es 100. Si un elemento de registro ha encontrado 70 registros coincidentes, los primeros 50 registros se enviará en un lote, el archivo persistente se actualizará y luego quedarán 20 los registros se enviarán (quizás con algo de retraso cuando se acumulen más datos) 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 un resultado de cada La comprobación de elementos log.count[] y logrt.count[] requiere un espacio libre en el 50% del área designada en el búfer de envío del agente. Los elementos amortiguadores son se envía regularmente al servidor (o proxy) y las ranuras de búfer vuelven a estar libres.

Mientras haya ranuras libres en el área de registro designada en el envío del agente búfer y falla la comunicación entre el agente y el servidor (o proxy), el Los resultados de la supervisión de registros se acumulan en el búfer de envío. Esto ayuda a mitigar fallas breves de comunicación.

Durante fallas de comunicación más prolongadas, todas las ranuras de registro se ocupan y el se toman las siguientes acciones:

• Se detienen las comprobaciones de los elementos log[] y logrt[]. Cuando la comunicación es ranuras restauradas y libres en el búfer están disponibles los cheques son reanudado desde la posición anterior. No se pierden líneas coincidentes, se solo se informan más tarde.
• Las comprobaciones log.count[] y logrt.count[] se detienen si maxdelay = 0 (predeterminado). El comportamiento es similar a log[] y logrt[] elementos como se describe arriba. Tenga en cuenta que esto puede afectar Resultados log.count[] y logrt.count[]: por ejemplo, una comprobación cuenta 100 líneas coincidentes en un archivo de registro, pero como no hay ranuras en el búfer, la verificación se detiene. Cuando la comunicación es restaurado 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 fueran encontrado en un cheque.
• log.count[] y logrt.count[] verifica con maxdelay > 0: si no hubo "salto" durante la verificación, entonces el comportamiento es similar a descrito arriba. Si se produjo un "salto" sobre las líneas del archivo de registro, el se mantiene la posición después de "saltar" 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 que de falla de comunicación.

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

Si una expresión regular utilizada en el elemento log[], logrt[], log.count[] o logrt.count[] no puede ser compilada por la biblioteca PCRE o PCRE2, entonces el elemento entra en Estado NOTSUPPORTED con un mensaje de error. Para continuar monitoreando el elemento de registro, 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), entonces el elemento de registro sigue siendo compatible y el seguimiento continúa. El error de tiempo de ejecución se registra en el archivo de registro del agente Zabbix (sin el registro del archivo de registro).

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

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

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