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 del elemento

Configure un registro de monitoreo elemento.

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

Específicamente para los elementos de monitoreo de registro que ingresa:

Notas importantes

• El servidor y el agente mantienen el rastro del tamaño y el tamaño de un registro monitoreado. última hora de modificación (para logrt) en dos contadores. Además:
  • El agente también utiliza internamente números de inodo (en UNIX/GNU/Linux), índices de archivos (en Microsoft Windows) y MD5 sumas de los primeros 512 bytes del archivo de registro para mejorar las decisiones cuando los archivos de registro se truncan y rotan.
  • En los sistemas UNIX/GNU/Linux se supone que los sistemas de archivos donde se almacenan los archivos de registro informan los números de inodo, que se pueden utilizado para rastrear archivos.
  • En Microsoft Windows, el agente Zabbix determina el tipo de sistema de archivos en los que residen los archivos de registro y utiliza:
    • En sistemas de archivos NTFS, índices de archivos de 64 bits.
    • En sistemas de archivos ReFS (solo desde Microsoft Windows Server 2012) ID de archivo de 128 bits.
    • En sistemas de archivos donde los índices de archivos cambian (por ejemplo, FAT32, exFAT) se utiliza un algoritmo alternativo para tomar una decisión sensata en condiciones inciertas cuando la rotación del archivo de registro da como resultado varios archivos de registro con el mismo último tiempo de modificación.
  • Los números de inodo, los índices de archivo y las sumas MD5 son recogidas internamente por el agente de 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 los archivos de registro con Utilidad 'toque', no copie un archivo de registro con restauración posterior del nombre original (esto cambiará el número de inodo del archivo). En ambos casos el expediente se contará como diferente y será analizadas desde el principio, lo que puede resultar en alertas duplicadas.
  • Si hay varios archivos de registro coincidentes para el elemento logrt[] y el agente de Zabbix está siguiendo el más reciente de ellos y este es el más el archivo de registro reciente se elimina, un mensaje de advertencia "no hay archivos que coincidan con "<regexp mask>" en "<directorio>" está registrado. El agente de Zabbix ignora los archivos de registro con el tiempo de modificación menos 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 en el momento anterior.
• El número de bytes ya analizados (el contador de tamaño) y el último tiempo de modificación (el contador de tiempo) se almacenan en la base de datos Zabbix y se envían al agente para asegurarse de que el agente se inicia leyendo el archivo de registro desde este punto en los casos en que el agente acaba de iniciarse o ha recibido métricas que anteriormente estaban deshabilitadas o no soportadas. Sin embargo, si el agente ha recibido un tamaño distinto de cero en el contador del servidor, pero la métrica logrt[] o logrt.count[] no es capaz de 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 sea más pequeño que el contador de tamaño de registro conocido por el agente, el contador se pone a cero y el agente comienza a leer el archivo de registro desde el principio tomándo en consideración el contador de tiempo.
• Si hay varios archivos coincidentes con la misma última modificación tiempo en el directorio, entonces el agente intenta analizar correctamente todos registrar archivos con el mismo tiempo de modificación y evitar omitir datos o analizando los mismos datos dos veces, aunque no se puede garantizar en todas las situaciones El agente no asume ningún archivo de registro en particular. esquema de rotación ni determina uno. Cuando se presenta registro múltiple archivos con la misma hora de última modificación, el agente procesará en orden lexicográficamente 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, el registro original no se respetará el orden de los archivos, lo que puede provocar que los informes coincidan registros del archivo de registro en orden alterado (el problema no ocurre si los archivos de registro tienen tiempos de última modificación diferentes).
• El agente Zabbix procesa nuevos registros de un archivo de registro una vez por Actualización intervalo segundos.
• El agente de Zabbix no envía más de líneas máximas 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 MaxLinesPerSecond parámetro en la configuración del agente archivo.
• Para encontrar la cadena requerida, Zabbix procesará 10 veces más nuevos líneas que las establecidas en MaxLinesPerSecond. Así, por ejemplo, si un log[] o el elemento logrt[] tiene Intervalo de actualización de 1 segundo, por defecto el el agente analizará no más de 200 registros del archivo de registro y enviará no más de 20 registros coincidentes con el servidor Zabbix en una sola verificación. Por aumentando MaxLinesPerSecond en el archivo de configuración del agente o configurando el parámetro maxlines en la clave del elemento, el límite puede ser aumentó hasta 10000 registros de archivos de registro analizados y 1000 coincidencias registros enviados al servidor Zabbix en un solo cheque. Si el Intervalo de actualización se establece en 2 segundos, los límites para una verificación se establecerían 2 veces mayor que con Intervalo de actualización de 1 segundo.
• Además, los valores log y log.count siempre están limitados al 50% de el tamaño del búfer de envío del agente, incluso si no hay valores que no sean de registro en eso. Entonces, para que los valores maxlines se envíen en una conexión (y no en varias conexiones), el agente El parámetro BufferSize debe ser al menos maxlines x 2.
• En ausencia de métricas de registro, se utiliza todo el tamaño del búfer del agente para valores no logarítmicos. Cuando los valores de registro entran, reemplazan a los valores más antiguos no logarítmicos según sea necesario, hasta el 50 % designado.
• Para los registros de archivos de registro de más de 256 kB, solo los primeros 256 kB son comparado con la expresión regular y el resto del registro es ignorado Sin embargo, si el agente de Zabbix se detiene mientras está tratando con un registro largo se pierde el estado interno del agente y el largo registro puede ser analizado de nuevo y de manera diferente después de que el agente es empezó de nuevo
• Nota especial para los separadores de ruta "\": si file_format es "archivo\.log", entonces no debería haber un directorio "archivo", ya que no es posible definir sin ambigüedades si "." se escapó o está 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 las plataformas UNIX, un elemento logrt[] se convierte en NO SOPORTADO si un directorio donde se espera que se encuentren los archivos de registro no existir.
• En Microsoft Windows, si no existe un directorio, el elemento se no se convierte en NOTSUPPORTED (por ejemplo, si el directorio está mal escrito en clave de 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[] son registrado como advertencias en el archivo de registro del agente de Zabbix, pero no haga el artículo NO SOPORTADO.
• El archivo de registro del agente de Zabbix puede ser útil para averiguar por qué un log[] o El elemento logrt[] pasó a ser NO COMPATIBLE. Zabbix puede monitorear su registro de agentes archivo excepto cuando está en DebugLevel=4 o DebugLevel=5.
• Buscar un signo de interrogación usando una expresión regular, p.e. \? puede generar 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 la expresión regular

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

Desde Zabbix 2.2.0, los elementos de registro tienen la capacidad de extraer los valores deseados de líneas emparejadas. 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/el/archivo,"asignación de búfer de resultados grandes.*Entradas: ([0-9]+)",,,,\1]

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

Vie 07 de febrero de 2014 11:07:36.6690 */ Id. de subproceso 1400 (GLEWF) resultado grande
       asignación de búfer - /Longitud: 437136/Entradas: 5948/Ver cliente: >=10/RPC
       ID: 41726453/Usuario: AUser/Formulario: CFG:Acuerdo de nivel de servicio

Solo se devolverá el número porque \1 se refiere al primero y solo grupo de captura: ([0-9]+).

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

Uso del parámetro maxdelay

El parámetro 'maxdelay' en los elementos del 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 'maxdelay'.

Por defecto, las métricas para el monitoreo de registros siguen todos los saltos de linea 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, tales aplicaciones inundan 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 debidamente analizados y las líneas coincidentes enviadas al servidor según lo configurado en las métricas log y logrt.

La protección integrada contra sobrecarga consiste en un parámetro 'maxlines' configurable (protege al servidor de demasiadas coincidencias en las líneas de registro entrantes) y un límite de 4*'maxlines' (protege la CPU del equipo y la E/S de sobrecarga por agente en una comprobación). Aún así, hay 2 problemas con la protección incorporada. En primer lugar, un gran número de mensajes potencialmente 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 en segundo lugar, el agente puede retrasarse durante horas con respecto a los registros de registro más recientes. Es bastante probable, que prefiera estar informado con prontitud 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 usar el parámetro 'maxdelay'. Si se especifica 'maxdelay' > 0, durante cada verificación el número de bytes procesados, el número de bytes restantes y el tiempo de procesamiento son medidos. 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 analizando el archivo de registro como de costumbre.

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

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

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

14287:20160602:174344.206 elemento:"logrt["/home/zabbix32/test[0-9].log",ERROR,,1000,,,120.0]"
       logfile:"/home/zabbix32/test1.log" omitiendo 679858 bytes
       (del byte 75653115 al byte 76332973) para cumplir con 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 en el archivo o antes.

Dependiendo de cómo la velocidad de crecimiento se compara con la velocidad de análisis del archivo de registro, es posible que no vea "saltos", "saltos" raros o frecuentes, grandes o pequeños "saltos", 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 al cálculo de la demora y, por lo tanto, "saltar" adelante para mantenerse al día con el parámetro "maxdelay".

No se recomienda configurar 'maxdelay' < 'update interval' (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*[]

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 las métrica log[], logrt[], log.count[] o logrt.count[] no puede ser compilada por la biblioteca PCRE o PCRE2, entonces la métrica pasa al estado NOTSUPPORTED con un mensaje de error. Para continuar monitoreando la métrica 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 la métrica de registro sigue siendo compatible y la supervisión 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).

Tenga en cuenta que el registro de errores en tiempo de ejecución de expresiones regulares se admite desde Zabbix 6.0.21.

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 de la métrica en caso de un error de tiempo de ejecución, zabbix_agent2 registra el ID de la métrica para ayudar a identificar qué métrica 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.

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.