2 Detalles del preprocesamiento

Descripción general

Esta sección proporciona detalles sobre el preprocesamiento de valores de item. El preprocesamiento de valores de item permite definir y ejecutar reglas de transformación para los valores de item recibidos.

El preprocesamiento es gestionado por el proceso de administrador de preprocesamiento junto con los workers de preprocesamiento que realizan los pasos de preprocesamiento. Todos los valores con preprocesamiento (antes de Zabbix 7.4.1, todos los valores), recibidos de distintos recolectores de datos, pasan por el administrador de preprocesamiento antes de ser añadidos a la caché de historial. Se utiliza comunicación IPC basada en sockets entre los recolectores de datos (pollers, trappers, etc.) y el proceso de preprocesamiento. Tanto Zabbix server como Zabbix proxy (para los items monitorizados por el proxy) realizan los pasos de preprocesamiento.

Procesamiento del valor del item

Para visualizar el flujo de datos desde la fuente de datos hasta la base de datos de Zabbix, podemos usar el siguiente diagrama simplificado:

El diagrama anterior muestra solo procesos, objetos y acciones relacionados con el procesamiento del valor del item en una forma simplificada. El diagrama no muestra cambios de dirección condicionales, manejo de errores ni bucles. Tampoco se muestra la caché de datos local del gestor de preprocesamiento, porque no afecta directamente al flujo de datos. El objetivo de este diagrama es mostrar los procesos involucrados en el procesamiento del valor del item y la forma en que interactúan.

• La recopilación de datos comienza con datos sin procesar procedentes de una fuente de datos. En este punto, los datos contienen solo ID, marca de tiempo y valor (también pueden ser varios valores).
• Independientemente del tipo de recolector de datos que se utilice, la idea es la misma para comprobaciones activas o pasivas, para items trapper, etc., ya que solo cambia el formato de los datos y quién inicia la comunicación (o bien el recolector de datos espera una conexión y los datos, o bien el recolector de datos inicia la comunicación y solicita los datos). Los datos sin procesar se validan, la configuración del item se recupera de la caché de configuración (los datos se enriquecen con los datos de configuración).
• Se utiliza un mecanismo IPC basado en sockets para pasar los datos desde los recolectores de datos al gestor de preprocesamiento. En este punto, el recolector de datos continúa recopilando datos sin esperar la respuesta del gestor de preprocesamiento.
• Se realiza el preprocesamiento de datos. Esto incluye la ejecución de pasos de preprocesamiento y el procesamiento de items dependientes.

• Los datos históricos de la caché de datos local del gestor de preprocesamiento se vacían en la caché de historial.
• En este punto, el flujo de datos se detiene hasta la siguiente sincronización de la caché de historial (cuando el proceso history syncer realiza la sincronización de datos).
• El proceso de sincronización comienza con la normalización de datos antes de almacenarlos en la base de datos de Zabbix. La normalización de datos realiza conversiones al tipo de item deseado (tipo definido en la configuración del item), incluida la truncación de datos textuales según los tamaños predefinidos permitidos para esos tipos (HISTORY_STR_VALUE_LEN para string, HISTORY_TEXT_VALUE_LEN para text y HISTORY_LOG_VALUE_LEN para valores log). Los datos se envían a la base de datos de Zabbix una vez finalizada la normalización.

• Los datos recopilados se procesan: se comprueban los triggers, se actualiza la configuración del item si el item pasa a NOT SUPPORTED, etc.
• Esto se considera el final del flujo de datos desde el punto de vista del procesamiento del valor del item.

Preprocesamiento del valor del item

El preprocesamiento de datos se realiza en los siguientes pasos:

• Si el item no tiene ni preprocesamiento ni items dependientes, su valor se agrega a la caché de historial o se envía al gestor LLD. De lo contrario, el valor del item se pasa al gestor de preprocesamiento mediante un mecanismo IPC basado en socket UNIX (antes de Zabbix 7.4.1, todos los valores se pasaban por el gestor de preprocesamiento antes de agregarse a la caché de historial o enviarse al gestor LLD).
• Se crea una tarea de preprocesamiento y se agrega a la cola, y se notifica a los workers de preprocesamiento sobre la nueva tarea.
• En este punto, el flujo de datos se detiene hasta que haya al menos un worker de preprocesamiento libre (es decir, que no esté ejecutando ninguna tarea).
• Cuando hay un worker de preprocesamiento disponible, toma la siguiente tarea de la cola.
• Después de que finaliza el preprocesamiento (tanto si la ejecución de los pasos de preprocesamiento falla como si tiene éxito), el valor preprocesado se agrega a la cola de tareas finalizadas y se notifica al manager sobre una nueva tarea finalizada.
• El gestor de preprocesamiento convierte el resultado al formato deseado (definido por el tipo de valor del item) y lo agrega a la caché de historial o lo envía al gestor LLD.
• Si hay items dependientes para el item procesado, entonces los items dependientes se agregan a la cola de preprocesamiento con el valor preprocesado del item maestro. Los items dependientes se encolan omitiendo las solicitudes normales de preprocesamiento de valores, pero solo para items maestro con el valor establecido y que no estén en estado NOT SUPPORTED.

Tenga en cuenta que en el diagrama el preprocesamiento del item maestro está ligeramente simplificado al omitir el almacenamiento en caché del preprocesamiento.

Cola de preprocesamiento

La cola de preprocesamiento se organiza como:

• la lista de tareas pendientes:

  • tareas creadas directamente a partir de solicitudes de preprocesamiento de valores en el orden en que se recibieron

• la lista de tareas inmediatas (procesadas antes que las tareas pendientes):

  • tareas de prueba (creadas en respuesta a solicitudes de prueba de métrica/preprocesamiento por la interfaz web)
  • tareas de métricas dependientes
  • tareas de secuencia (tareas que deben ejecutarse en un orden estricto):
    • que tienen pasos de preprocesamiento usando el último valor:
      • cambio
      • limitación de frecuencia
      • JavaScript (caché de bytecode)
    • caché de preprocesamiento de métricas dependientes

• la lista de tareas finalizadas

Caché de preprocesamiento

Se introdujo la caché de preprocesamiento para mejorar el rendimiento del preprocesamiento en múltiples métricas dependientes que tienen pasos de preprocesamiento similares (lo cual es un resultado común de LLD).

La caché se realiza preprocesando una métrica dependiente y reutilizando algunos de los datos internos de preprocesamiento para el resto de las métricas dependientes. La caché de preprocesamiento solo es compatible con el primer paso de preprocesamiento de los siguientes tipos:

• Patrón Prometheus (indexa la entrada por métricas)
• JSONPath (analiza los datos en un árbol de objetos e indexa la primera expresión [?(@.path == "value")])

Workers de preprocesamiento

El archivo de configuración de Zabbix server permite a los usuarios establecer la cantidad de hilos de workers de preprocesamiento. El parámetro de configuración StartPreprocessors debe utilizarse para definir el número de instancias de workers de preprocesamiento iniciadas previamente, que como mínimo debe coincidir con el número de núcleos de CPU disponibles.

Si las tareas de preprocesamiento no están limitadas por la CPU e implican solicitudes de red frecuentes, se recomienda configurar workers adicionales. El número óptimo de workers de preprocesamiento puede determinarse por muchos factores, incluido el número de items "preprocesables" (items que requieren ejecutar cualquier paso de preprocesamiento), el número de procesos de recopilación de datos, el número promedio de pasos para el preprocesamiento de items, etc. Un número insuficiente de workers puede provocar un alto uso de memoria. Para solucionar problemas de uso excesivo de memoria en su instalación de Zabbix, consulte Profiling excessive memory usage with tcmalloc.

Pero suponiendo que no haya operaciones de preprocesamiento intensivas, como el análisis de grandes fragmentos XML/JSON, el número de workers de preprocesamiento puede coincidir con el número total de recolectores de datos. De este modo, en la mayoría de los casos (excepto cuando los datos del recolector llegan en bloque) habrá al menos un worker de preprocesamiento libre para los datos recopilados.

Canalización de procesamiento de valores

El procesamiento de valores de métricas se ejecuta en múltiples pasos (o fases) por múltiples procesos. Esto puede causar:

• Una métrica dependiente puede recibir valores, mientras que la métrica principal no puede. Esto se puede lograr utilizando el siguiente caso de uso:
  • La métrica principal tiene tipo de valor UINT (se puede usar una métrica trapper), la métrica dependiente tiene tipo de valor TEXT.
  • No se requieren pasos de preprocesamiento para ambas métricas, principal y dependiente.
  • Se debe pasar un valor textual (por ejemplo, "abc") a la métrica principal.
  • Como no hay pasos de preprocesamiento que ejecutar, el gestor de preprocesamiento verifica si la métrica principal no está en estado NO SOPORTADO y si el valor está establecido (ambos son verdaderos) y pone en cola la métrica dependiente con el mismo valor que la métrica principal (ya que no hay pasos de preprocesamiento).
  • Cuando tanto la métrica principal como la dependiente alcanzan la fase de sincronización del historial, la métrica principal pasa a estar en estado NO SOPORTADO debido al error de conversión de valor (los datos textuales no se pueden convertir a un entero sin signo).

Como resultado, la métrica dependiente recibe un valor, mientras que la métrica principal cambia su estado a NO SOPORTADO.

• Una métrica dependiente recibe un valor que no está presente en el historial de la métrica principal. El caso de uso es muy similar al anterior, excepto por el tipo de la métrica principal. Por ejemplo, si se utiliza el tipo CHAR para la métrica principal, entonces el valor de la métrica principal se truncará en la fase de sincronización del historial, mientras que las métricas dependientes recibirán sus valores a partir del valor inicial (no truncado) de la métrica principal.