2 Détails du prétraitement

Aperçu

Cette section fournit des détails sur le prétraitement des valeurs d’élément. Le prétraitement des valeurs d’élément permet de définir et d’exécuter des règles de transformation pour les valeurs d’élément reçues.

Le prétraitement est géré par le processus de gestion du prétraitement, ainsi que par des workers de prétraitement qui exécutent les étapes de prétraitement. Toutes les valeurs avec prétraitement, reçues de différents collecteurs de données, passent par le gestionnaire de prétraitement avant d’être ajoutées au cache d’historique. Une communication IPC basée sur des sockets est utilisée entre les collecteurs de données (pollers, trappers, etc.) et le processus de prétraitement. Le serveur Zabbix ou le proxy Zabbix (pour les éléments surveillés par le proxy) exécute les étapes de prétraitement.

Traitement des valeurs d’élément

Pour visualiser le flux de données depuis la source de données jusqu’à la base de données Zabbix, nous pouvons utiliser le schéma simplifié suivant :

Le schéma ci-dessus montre uniquement les processus, objets et actions liés au traitement des valeurs d’élément sous une forme simplifiée. Le schéma ne montre pas les changements de direction conditionnels, la gestion des erreurs ni les boucles. Le cache local de données du gestionnaire de prétraitement n’est pas non plus affiché, car il n’affecte pas directement le flux de données. L’objectif de ce schéma est de montrer les processus impliqués dans le traitement des valeurs d’élément et la manière dont ils interagissent.

• La collecte des données commence par des données brutes provenant d’une source de données. À ce stade, les données ne contiennent que l’ID, l’horodatage et la valeur (il peut également s’agir de plusieurs valeurs).
• Quel que soit le type de collecteur de données utilisé, le principe reste le même pour les contrôles actifs ou passifs, pour les éléments trapper, etc., car cela ne modifie que le format des données et l’initiateur de la communication (soit le collecteur de données attend une connexion et des données, soit le collecteur de données initie la communication et demande les données). Les données brutes sont validées, la configuration de l’élément est récupérée depuis le cache de configuration (les données sont enrichies avec les données de configuration).
• Un mécanisme IPC basé sur des sockets est utilisé pour transmettre les données des collecteurs de données au gestionnaire de prétraitement. À ce stade, le collecteur de données continue à collecter des données sans attendre la réponse du gestionnaire de prétraitement.
• Le prétraitement des données est effectué. Cela inclut l’exécution des étapes de prétraitement et le traitement des éléments dépendants.

• Les données d’historique du cache local de données du gestionnaire de prétraitement sont vidées dans le cache d’historique.
• À ce stade, le flux de données s’arrête jusqu’à la prochaine synchronisation du cache d’historique (lorsque le processus history syncer effectue la synchronisation des données).
• Le processus de synchronisation commence par la normalisation des données avant leur stockage dans la base de données Zabbix. La normalisation des données effectue des conversions vers le type d’élément souhaité (type défini dans la configuration de l’élément), y compris la troncature des données textuelles selon les tailles prédéfinies autorisées pour ces types (HISTORY_STR_VALUE_LEN pour string, HISTORY_TEXT_VALUE_LEN pour text et HISTORY_LOG_VALUE_LEN pour les valeurs log). Les données sont envoyées à la base de données Zabbix une fois la normalisation terminée.

• Les données collectées sont traitées : les déclencheurs sont vérifiés, la configuration de l’élément est mise à jour si l’élément devient NOT SUPPORTED, etc.
• Ceci est considéré comme la fin du flux de données du point de vue du traitement des valeurs d’élément.

Prétraitement de la valeur de l'élément

Le prétraitement des données est effectué selon les étapes suivantes :

• Si l'élément n'a ni prétraitement ni éléments dépendants, sa valeur est soit ajoutée au cache d'historique, soit envoyée au gestionnaire LLD. Sinon, la valeur de l'élément est transmise au gestionnaire de prétraitement à l'aide d'un mécanisme IPC basé sur des sockets UNIX.
• Une tâche de prétraitement est créée, ajoutée à la file d'attente, et les workers de prétraitement sont informés de la nouvelle tâche.
• À ce stade, le flux de données s'arrête jusqu'à ce qu'il y ait au moins un worker de prétraitement inoccupé (c'est-à-dire n'exécutant aucune tâche).
• Lorsqu'un worker de prétraitement est disponible, il prend la tâche suivante dans la file d'attente.
• Une fois le prétraitement terminé (que l'exécution des étapes de prétraitement ait échoué ou réussi), la valeur prétraitée est ajoutée à la file d'attente des tâches terminées et le gestionnaire est informé qu'une nouvelle tâche est terminée.
• Le gestionnaire de prétraitement convertit le résultat au format souhaité (défini par le type de valeur de l'élément), puis l'ajoute soit au cache d'historique, soit l'envoie au gestionnaire LLD.
• S'il existe des éléments dépendants pour l'élément traité, ceux-ci sont alors ajoutés à la file d'attente de prétraitement avec la valeur prétraitée de l'élément maître. Les éléments dépendants sont mis en file d'attente en contournant les requêtes normales de prétraitement des valeurs, mais uniquement pour les éléments maîtres dont la valeur est définie et qui ne sont pas dans l'état NOT SUPPORTED.

Notez que, dans le diagramme, le prétraitement de l'élément maître est légèrement simplifié, car la mise en cache du prétraitement n'y est pas représentée.

File d’attente de prétraitement

La file d’attente de prétraitement est organisée comme suit :

• la liste des tâches en attente :

  • tâches créées directement à partir des demandes de prétraitement des valeurs, dans l’ordre de leur réception

• la liste des tâches immédiates (traitées avant les tâches en attente) :

  • tâches de test (créées en réponse aux demandes de test d’élément/de prétraitement par le frontend)
  • tâches des éléments dépendants
  • tâches de séquence (tâches devant être exécutées dans un ordre strict) :
    • comportant des étapes de prétraitement utilisant la dernière valeur :
      • changement
      • limitation du débit
      • JavaScript (mise en cache du bytecode)
    • mise en cache du prétraitement des éléments dépendants

• la liste des tâches terminées

Mise en cache du prétraitement

La mise en cache du prétraitement a été introduite pour améliorer les performances du prétraitement pour plusieurs éléments dépendants ayant des étapes de prétraitement similaires (ce qui est un résultat courant de la LLD).

La mise en cache consiste à prétraiter un élément dépendant et à réutiliser une partie des données internes de prétraitement pour le reste des éléments dépendants. Le cache de prétraitement n'est pris en charge que pour la première étape de prétraitement des types suivants :

• Motif Prometheus (indexe l'entrée par métriques)
• JSONPath (analyse les données en arbre d'objets et indexe la première expression [?(@.path == "value")])

Workers de prétraitement

Le fichier de configuration du serveur Zabbix permet aux utilisateurs de définir le nombre de threads workers de prétraitement. Le paramètre de configuration StartPreprocessors doit être utilisé pour définir le nombre d’instances de workers de prétraitement démarrées à l’avance, qui doit au minimum correspondre au nombre de cœurs CPU disponibles.

Si les tâches de prétraitement ne sont pas limitées par le CPU et impliquent des requêtes réseau fréquentes, il est recommandé de configurer des workers supplémentaires. Le nombre optimal de workers de prétraitement peut être déterminé par de nombreux facteurs, notamment le nombre d’éléments « prétraitables » (éléments pour lesquels il est nécessaire d’exécuter des étapes de prétraitement), le nombre de processus de collecte de données, le nombre moyen d’étapes de prétraitement par élément, etc. Un nombre insuffisant de workers peut entraîner une utilisation élevée de la mémoire. Pour résoudre les problèmes d’utilisation excessive de la mémoire sur votre installation Zabbix, consultez Profiling excessive memory usage with tcmalloc.

Mais en supposant qu’il n’y ait pas d’opérations de prétraitement lourdes, comme l’analyse de gros blocs XML/JSON, le nombre de workers de prétraitement peut correspondre au nombre total de collecteurs de données. De cette manière, il y aura le plus souvent (sauf dans les cas où les données du collecteur arrivent en masse) au moins un worker de prétraitement inoccupé pour les données collectées.

Pipeline de traitement des valeurs

Le traitement des valeurs des éléments est exécuté en plusieurs étapes (ou phases) par plusieurs processus. Cela peut entraîner :

• Un élément dépendant peut recevoir des valeurs, alors que la valeur maître, elle, ne le peut pas. Cela peut être obtenu en utilisant le cas d’usage suivant :
  • L’élément maître a pour type de valeur UINT (un élément trapper peut être utilisé), l’élément dépendant a pour type de valeur TEXT.
  • Aucune étape de prétraitement n’est requise ni pour l’élément maître ni pour l’élément dépendant.
  • Une valeur textuelle (par exemple, "abc") doit être transmise à l’élément maître.
  • Comme il n’y a aucune étape de prétraitement à exécuter, le gestionnaire de prétraitement vérifie que l’élément maître n’est pas dans l’état NOT SUPPORTED et qu’une valeur est définie (les deux conditions sont vraies), puis met en file d’attente l’élément dépendant avec la même valeur que l’élément maître (puisqu’il n’y a pas d’étapes de prétraitement).
  • Lorsque l’élément maître et l’élément dépendant atteignent tous deux la phase de synchronisation de l’historique, l’élément maître devient NOT SUPPORTED en raison d’une erreur de conversion de valeur (les données textuelles ne peuvent pas être converties en entier non signé).

Par conséquent, l’élément dépendant reçoit une valeur, tandis que l’élément maître change son état en NOT SUPPORTED.

• Un élément dépendant reçoit une valeur qui n’est pas présente dans l’historique de l’élément maître. Le cas d’usage est très similaire au précédent, à l’exception du type de l’élément maître. Par exemple, si le type CHAR est utilisé pour l’élément maître, alors la valeur de l’élément maître sera tronquée lors de la phase de synchronisation de l’historique, tandis que les éléments dépendants recevront leurs valeurs à partir de la valeur initiale (non tronquée) de l’élément maître.