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 en dos contadores el seguimiento del tamaño del registro monitoreado y la hora de la última modificación (para logrt). Además:
  • El agente también utiliza internamente números de inodo (en UNIX/GNU/Linux), índices de archivos (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 supone que los sistemas de archivos donde se almacenan los archivos de registro informan de los números de inodo, que pueden ser usados 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 archivos 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 múltiples archivos de registro con el mismo último tiempo de modificación.
  • Los números de inodo, índices de archivos y sumas MD5 son recogidos 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 la última modificación de los archivos de registro con la utilidad 'touch', no copie un archivo de registro para su posterior restauración del nombre original (esto cambiará el número de inodo del archivo). En ambos casos el archivo se considerará como diferente y será analizado desde el principio, lo que puede dar lugar a alertas duplicadas.
  • Si hay varios archivos de registro coincidentes para la métrica logrt[] y el agente de Zabbix está siguiendo el más reciente de ellos y este archivo de registro más reciente se elimina, aparecerá un mensaje de advertencia. "no hay archivos que coincidan con "<máscara de expresión regular>" en "<directorio>" El agente Zabbix ignora los archivos de registro con hora de modificación menor que la hora de modificación más reciente vista por el agente para la métrica logrt[] que se está verificando.
• 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 almacena en la base de datos Zabbix y se envían al agente para asegurarse de que el agente empiece a leer el archivo de registro desde este punto en los casos en que el agente recién esté iniciado o haya recibido métricas que previamente 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 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 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ándose el tiempo contador en cuenta.
• 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 presentan múltiples registros archivos con la misma hora de última modificación, el agente procesará ellos en orden lexicográfico descendente. Así, para algunos esquemas de rotación, los archivos de registro serán analizados e informados en su orden original. Para otros esquemas de rotación, el registro original No se respetará el orden de los archivos, lo que puede dar lugar a que se informen coincidencias. registros del archivo de registro en 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 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 sobrepasa el valor predeterminado proporcionado por el parámetro MaxLinesPerSecond en la el archivo de configuración del agente.
• Para encontrar la cadena requerida, Zabbix procesará 10 veces más nuevas líneas que las establecidas en MaxLinesPerSecond. Así, por ejemplo, si la métrica log[] o logrt[] tiene un intervalo de actualización de 1 segundo, de forma predeterminada el agente analizará no más de 200 registros de archivos de registro y enviará no más de 20 registros coincidentes en el servidor Zabbix en una sola verificación, aumentando MaxLinesPerSecond en el archivo de configuración del agente o configurando el parámetro maxlines en la clave de la métrica, el límite puede ser aumentado hasta 10000 registros de archivos de registro analizados y 1000 registros de coincidencias enviados al servidor Zabbix en una sola verificación. Si el intervalo de actualización se establece en 2 segundos, los límites para una verificación se establecerían 2 veces más que con Intervalo de actualización de 1 segundo.
• Además, los valores log y log.count siempre están limitados al 50% del tamaño del búfer de envío del agente, incluso si no hay valores que no sean de registro en él. Entonces, para que los valores maxlines se envíen en una conexión (y no en varias conexiones), el parámetro BufferSize del agente debe ser al menos maxlines x 2. El agente de Zabbix puede cargar datos durante la recopilación de registros y así liberar el búfer, mientras que el agente 2 de Zabbix dejará de recopilar registros hasta que se carguen los datos y se libera el búfer, lo cual se realiza de forma asincrónica.
• En ausencia de métricas de registro, se utiliza todo el tamaño del búfer del agente. valores no-log. Cuando entran los valores de registro, reemplazan a los anteriores valores no-log según sea necesario, hasta el 50% designado.
• Para registros de archivos de registro de más de 256 kB, solo se incluyen los primeros 256 kB. para la coincidencia con la expresión regular y el resto del registro es ignorado. Sin embargo, si se detiene al agente Zabbix mientras está tratando con un registro largo el estado interno del agente se pierde y el registro largo puede ser analizado nuevamente y de manera diferente después de que el agente haya comenzado de nuevo.
• Nota especial para los separadores de ruta "\": si file_format es "file\.log", entonces no debería haber un directorio "file", ya que no es posible definir inequívocamente si "." se ha 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 de directorios.
• En plataformas UNIX, un elemento logrt[] pasa a ser NOTSUPPORTED si el directorio donde se espera que se encuentren los archivos de registro no existe.
• En Microsoft Windows, si no existe un directorio, la métrica no se convierte a NOTSUPPORTED (por ejemplo, si el directorio está mal escrito en la clave de la métrica).
• La ausencia de archivos de registro para la métrica logrt[] no la convierte en NO SOPORTADA. Los errores de lectura de archivos de registro para la métrica logrt[] son registrados como advertencias en el archivo de registro del agente Zabbix, pero no convierte la métrica en NO SOPORTADA.
• El archivo de registro del agente Zabbix puede ser útil para descubrir por qué una métrica log[] o logrt[] pasó a ser NOTSUPPORTED. Zabbix puede monitorear el archivo de registro de su agente, 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 se reemplazan 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*[]

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.

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.