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:
El límite de tamaño de un archivo de registro supervisado depende de archivo grande soporte.
Asegúrese de que en la configuración del agente archivo:
Configure una métrica de monitoreo de registros.
Todos los campos de entrada obligatorios están marcados con un asterisco rojo.
Específicamente para las métricas de monitoreo de registros, ingrese:
Tipo | Seleccione Agente Zabbix (activo) aquí. |
Clave | Use una de las siguientes claves de métrica: log[] o logrt[]: Estas dos claves de métrica permiten monitorear registros y filtrar entradas de registro por la expresión regular de contenido, si está presente. Por ejemplo: log[/var/log/syslog,error] . Asegúrese de que el archivo tenga permisos de lectura para el usuario 'zabbix', de lo contrario, el estado de la métrica se establecerá en 'no compatible'.log.count[] o logrt.count[]: Estas dos claves de métrica permiten devolver solo la cantidad de líneas coincidentes. Consulte la sección de claves de métrica de agente Zabbix compatibles para obtener detalles sobre el uso de estas claves de métrica y sus parámetros. |
Tipo de información | Se rellena automáticamente: Para elementos log[] o logrt[]: Log ;Para las métricas log.count[] o logrt.count[]: Numeric (unsigned) .Si utiliza opcionalmente el parámetro output , puede seleccionar manualmente el tipo de información adecuado que no sea Log .Tenga en cuenta que elegir un tipo de información que no sea Log provocará la pérdida de la marca de tiempo local. |
Intervalo de actualización (en segundos) | El parámetro define la frecuencia con la que el agente Zabbix comprobará si hay cambios en el archivo de registro. Si lo configura en 1 segundo, se asegurará de obtener los nuevos registros lo antes posible. |
Formato de hora de registro | En este campo, puede especificar opcionalmente el patrón para analizar la marca de tiempo de la línea de registro. Marcadores de posición admitidos: * y: Año (1970-2038) * M: Mes (01-12) * d: Día (01-31) * h: Hora (00-23) * m: Minuto (00-59) * s: Segundo (00-59) Si se deja en blanco, la marca de tiempo se establecerá en 0 en horario Unix, lo que representa el 1 de enero de 1970. Por ejemplo, considere la siguiente línea del archivo de registro del agente Zabbix: " 23480:20100328:154718.045 Agente Zabbix iniciado. Zabbix 1.8.2 (revisión 11211)." Es comienza con seis posiciones de caracteres para PID, seguido de la fecha, la hora y el resto del mensaje. El formato de tiempo de registro para esta línea sería "pppppp:aaaaMMdd:hhmmss". Tenga en cuenta que los caracteres "p" y ":" son marcadores de posición y pueden ser cualquier carácter excepto "yMdhms". |
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.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.logrt
solo se admiten en el nombre de archivo, No se admite la coincidencia de expresiones regulares de directorio.logrt[]
se convierte en NO SOPORTADO si un directorio donde se espera que se encuentren los archivos de registro no existir.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.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.\?
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.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
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.
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'.
Especificar 'maxdelay' > 0 puede conducir a ** ignorar registros importantes del archivo de registro y perder alertas**. Úselo con cuidado en su propio riesgo sólo cuando sea necesario.
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).
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.
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.
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:
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.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.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.
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.
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. :::
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.