2 Détails du prétraitement

Aperçu

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

Le prétraitement est géré par un processus de gestionnaire de prétraitement, qui a été ajouté dans Zabbix 3.4, ainsi que par des agents de prétraitement qui exécutent les étapes de prétraitement. Toutes les valeurs (avec ou sans prétraitement) des différents collecteurs de données passent par le gestionnaire de prétraitement avant d'être ajoutées au cache de l'historique. La communication IPC basée sur les 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) effectue des étapes de prétraitement.

Traitement de la valeur de l'élément

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

Le diagramme ci-dessus montre uniquement les processus, les objets et les actions liés au traitement de la valeur de l'élément sous une forme simplifiée. Le diagramme ne montre pas les changements de direction conditionnels, la gestion des erreurs ou les boucles. Le cache de données local du gestionnaire de prétraitement n'est pas affiché non plus car il n'affecte pas directement le flux de données. L'objectif de ce diagramme est de montrer les processus impliqués dans le traitement de la valeur des éléments et la façon dont ils interagissent.

• La collecte de 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é, l'idée est la même pour les vérifications actives ou passives, pour les éléments de trappeur, etc., car cela ne modifie que le format des données et le démarreur de communication (soit le collecteur de données attend une connexion et des données, ou le collecteur de données initie la communication et demande les données). Les données brutes sont validées, la configuration des éléments est extraite du cache de configuration (les données sont enrichies avec les données de configuration).
• Le mécanisme IPC basé sur les 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 de collecter des données sans attendre la réponse du gestionnaire de prétraitement.
• Un 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 de données local 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 de l'historique (lorsque le processus de synchronisation de l'historique effectue la synchronisation des données).
• Le processus de synchronisation commence par la normalisation des données en stockant les données 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 en fonction des tailles prédéfinies autorisées pour ces types (HISTORY_STR_VALUE_LEN pour la chaîne, HISTORY_TEXT_VALUE_LEN pour le texte et HISTORY_LOG_VALUE_LEN pour les valeurs de journal). Les données sont envoyées à la base de données Zabbix après la normalisation.

• Les données collectées sont en cours de traitement - les déclencheurs sont vérifiés, la configuration de l'élément est mise à jour si l'élément devient NON SUPPORTÉ, etc.
• Ceci est considéré comme la fin du flux de données du point de vue du traitement de la valeur de l'élément.

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

Pour visualiser le processus de prétraitement des données, nous pouvons utiliser le schéma simplifié suivant :

Le diagramme ci-dessus montre uniquement les processus, les objets et les actions principales liés au prétraitement de la valeur de l'élément sous une forme simplifiée. Le diagramme ne montre pas les changements de direction conditionnels, la gestion des erreurs ou les boucles. Un seul agent de prétraitement est affiché sur ce diagramme (plusieurs agents de prétraitement peuvent être utilisés dans des scénarios réels), une seule valeur d'élément est en cours de traitement et nous supposons que cet élément nécessite l'exécution d'au moins une étape de prétraitement. Le but de ce diagramme est de montrer l'idée derrière le pipeline de prétraitement de la valeur de l'élément.

• Les données d'élément et la valeur de l'élément sont transmises au gestionnaire de prétraitement à l'aide du mécanisme IPC basé sur les sockets.
• L'élément est placé dans la file d'attente de prétraitement.

• À ce stade, le flux de données s'arrête jusqu'à ce qu'il y ait au moins un agent de prétraitement inoccupé (qui n'exécute aucune tâche).
• Lorsque le worker de prétraitement est disponible, la tâche de prétraitement lui est envoyée.
• Une fois le prétraitement terminé (échec et exécution réussie des étapes de prétraitement), la valeur prétraitée est renvoyée au gestionnaire de prétraitement.
• Le gestionnaire de prétraitement convertit le résultat au format souhaité (défini par le type de valeur d'élément) et place le résultat dans la file d'attente de prétraitement. S'il existe des éléments dépendants pour l'élément actuel, les éléments dépendants sont également ajoutés à la file d'attente de prétraitement. Les éléments dépendants sont mis en file d'attente dans la file d'attente de prétraitement juste après l'élément principal, mais uniquement pour les éléments principaux avec une valeur définie et non dans l'état NON SUPPORTÉ.

Pipeline de traitement de la valeur

Le traitement de la valeur de l'élément est exécuté en plusieurs étapes (ou phases) par plusieurs processus. Cela peut entraîner :

• L'élément dépendant peut recevoir des valeurs, contrairement à LA valeur principale. Ceci peut être réalisé en utilisant le cas d'usage suivant :
  • L'élément principal a le type de valeur UINT (l'élément trappeur peut être utilisé), l'élément dépendant a le type de valeur TEXT.
  • Aucune étape de prétraitement n'est requise pour les éléments principaux et dépendants.
  • La valeur textuelle (comme "abc") doit être transmise à l'élément principal.
  • Comme il n'y a pas d'étapes de prétraitement à exécuter, le gestionnaire de prétraitement vérifie si l'élément principal n'est pas dans l'état NON SUPPORTÉ et si la valeur est définie (les deux sont vrais) et met en file d'attente l'élément dépendant avec la même valeur que l'élément principal (car il n'y a pas d'étape de prétraitement) .
  • Lorsque les éléments principaux et dépendants atteignent la phase de synchronisation de l'historique, l'élément principal devient NON SUPPORTÉ, en raison de l'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 principal change son état en NON SUPPORTÉ.

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

File d'attente de prétraitement

La file d'attente de prétraitement est une structure de données FIFO qui stocke les valeurs en préservant l'ordre dans lequel les valeurs sont récupérées par le gestionnaire de prétraitement. Il existe plusieurs exceptions à la logique FIFO :

• Les éléments internes sont mis en file d'attente au début de la file d'attente
• Les éléments dépendants sont toujours mis en file d'attente après l'élément principal

Pour visualiser la logique de la file d'attente de prétraitement, nous pouvons utiliser le schéma suivant :

Les valeurs de la file d'attente de prétraitement sont vidées du début de la file d'attente à la première valeur non traitée. Ainsi, par exemple, le gestionnaire de prétraitement videra les valeurs 1, 2 et 3, mais ne videra pas la valeur 5 car la valeur 4 n'est pas encore traitée :

Seules deux valeurs seront laissées dans la file d'attente (4 et 5) après le vidage, les valeurs sont ajoutées au cache de données local du gestionnaire de prétraitement, puis les valeurs sont transférées du cache local au cache d'historique. Le gestionnaire de prétraitement peut vider les valeurs du cache de données local en mode élément unique ou en mode bloc (utilisé pour les éléments dépendants et les valeurs reçues en bloc).

Preprocessing caching

Preprocessing caching was introduced to improve the preprocessing performance for multiple dependent items having similar preprocessing steps (which is a common LLD outcome).

Caching is done by preprocessing one dependent item and reusing some of the internal preprocessing data for the rest of the dependent items. The preprocessing cache is supported only for the first preprocessing step of the following types:

• Prometheus pattern (indexes input by metrics)
• JSONPath (parses the data into object tree and indexes the first expression [?(@.path == "value")])

Processus de travail de prétraitement

Le fichier de configuration du serveur Zabbix permet aux utilisateurs de définir le nombre de processus de travail de prétraitement. Le paramètre de configuration StartPreprocessors doit être utilisé pour définir le nombre d'instances pré-forkées de processus de travail de prétraitement. Le nombre optimal de processus de travail de prétraitement peut être déterminé par de nombreux facteurs, y compris le nombre d'éléments "prétraitables" (éléments qui nécessitent d'exécuter des étapes de prétraitement), le nombre de processus de collecte de données, le nombre moyen d'étapes pour le prétraitement des éléments, etc.

Mais en supposant qu'il n'y a pas d'opérations de prétraitement lourdes comme l'analyse de gros morceaux XML / JSON, le nombre de processus de travail de prétraitement peut correspondre au nombre total de collecteurs de données. De cette façon, il y aura la plupart du temps (sauf dans les cas où les données du collecteur arrivent en masse) au moins un agent de prétraitement inoccupé pour les données collectées.