Création d'un élément

Vue d’ensemble

Pour créer un élément dans l’interface Zabbix, procédez comme suit :

1. Accédez à Collecte de données > Hôtes.
2. Cliquez sur Éléments dans la ligne du hôte.
3. Cliquez sur Créer un élément dans le coin supérieur droit de l’écran.
4. Saisissez les paramètres de l’élément dans le formulaire.

Vous pouvez également créer un élément en ouvrant un élément existant, en cliquant sur le bouton Cloner, puis en l’enregistrant sous un autre nom.

Configuration

L’onglet Élément contient les attributs généraux de l’élément.

Tous les champs obligatoires sont signalés par un astérisque rouge.

Paramètre	Description
Nom	Nom de l’élément. Les macros utilisateur sont prises en charge.
Type	Type d’élément. Consultez les sections consacrées à chaque type d’élément.
Clé	Clé de l’élément (jusqu’à 2048 caractères). Les clés d’élément prises en charge sont indiquées dans les sections consacrées à chaque type d’élément. La clé doit être unique au sein d’un même hôte. Si le type de clé est « Zabbix agent », « Zabbix agent (active) » ou « Simple check », la valeur de la clé doit être prise en charge par Zabbix agent ou le serveur Zabbix. Voir également le format de clé correct.
Type d’information	Type de données utilisé pour valider la valeur de l’élément et la stocker dans la base de données, après toute conversion : Numérique (non signé) - entier non signé de 64 bits ; Numérique (flottant) - nombre à virgule flottante de 64 bits ; Caractère - texte court ; Journal - texte long avec ou sans propriétés de journal (horodatage, source, gravité, ID de l’événement du journal) ; Texte - texte long ; Binaire - nombre binaire (pris en charge uniquement pour les éléments dépendants) ; JSON - données JSON structurées, stockées nativement dans la base de données (non pris en charge pour les éléments calculés). Les éléments renvoyant des valeurs de type binaire ou JSON ne sont pas pris en charge dans les formules d’éléments calculés ni dans les expressions de déclencheurs. Consultez les limites des données des éléments pour connaître les limites de stockage par type de données et moteur de base de données. Pour les éléments qui renvoient des données dans un format spécifique unique, un type de données correspondant est sélectionné automatiquement. Par exemple, system.cpu.load et system.cpu.util renvoient tous deux un nombre à virgule flottante de 64 bits ; Numérique (flottant) est donc sélectionné automatiquement.
Interface de l’hôte	Sélectionnez l’interface de l’hôte. Ce champ est disponible lors de la modification d’un élément au niveau de l’hôte.
Unités	Si un symbole d’unité est défini, Zabbix applique un post-traitement à la valeur reçue de l’élément et l’affiche avec le suffixe d’unité indiqué. Symboles d’unité pris en charge avec un formatage spécial (et exemples de valeur reçue → valeur affichée) : B - octets (1024 → 1 KB) Bps - octets par seconde (1024 → 1 KBps) s - secondes, affichées avec jusqu’à trois unités de temps non nulles les plus grandes (881764 → 10d 4h 56m) uptime - durée écoulée au format hh:mm:ss ou N jours, hh:mm:ss (881764 → 10 days, 04:56:04) unixtime - horodatage Unix, formaté comme yyyy.mm.dd hh:mm:ss (881764 → 1970-01-11 04:56:04 AM) ; pour un formatage correct, la valeur reçue de l’élément doit être de type Numérique (non signé). Pour les autres unités (telles que Hz, W, etc.), si la valeur reçue dépasse 1000, elle est divisée par 1000 et affichée avec le préfixe correspondant (5000 → 5 KHz, 881764 → 881.76 KW). Si le symbole d’unité est précédé de !, la conversion d’unité et l’ajout de préfixe sont désactivés (1024 !B → 1024 B, 61 !s → 61 s). Pour plus d’exemples et de détails sur les symboles d’unité et la conversion d’unité, consultez Suffixes des valeurs des éléments.
Intervalle de mise à jour	Récupérer une nouvelle valeur pour cet élément toutes les N secondes. L’intervalle de mise à jour maximal autorisé est de 86400 secondes (1 jour). Les suffixes de temps sont pris en charge, par exemple 30s, 1m, 2h, 1d. Les macros utilisateur sont prises en charge. Une seule macro doit remplir l’intégralité du champ. Plusieurs macros dans un champ ou des macros mélangées à du texte ne sont pas pris en charge. Remarque : l’intervalle de mise à jour ne peut être défini sur « 0 » que si des intervalles personnalisés existent avec une valeur différente de zéro. S’il est défini sur « 0 » et qu’un intervalle personnalisé (flexible ou planifié) existe avec une valeur différente de zéro, l’élément sera interrogé pendant la durée de l’intervalle personnalisé. Notez que la première interrogation de l’élément après son activation ou après la modification de l’intervalle de mise à jour peut avoir lieu plus tôt que la valeur configurée. Les nouveaux éléments seront vérifiés dans les 60 secondes suivant leur création, sauf s’ils disposent d’un intervalle de mise à jour planifié ou flexible et que l’Intervalle de mise à jour est défini sur 0. Un élément passif existant peut être interrogé immédiatement en cliquant sur le bouton Exécuter maintenant button.
Intervalles personnalisés	Vous pouvez créer des règles personnalisées pour vérifier l’élément : Flexible - crée une exception à l’Intervalle de mise à jour (intervalle avec une fréquence différente). Planification - crée un calendrier d’interrogation personnalisé. Pour plus d’informations, consultez Intervalles personnalisés. Les suffixes de temps sont pris en charge dans le champ Intervalle, par exemple 30s, 1m, 2h, 1d. Les macros utilisateur sont prises en charge. Une seule macro doit remplir l’intégralité du champ. Plusieurs macros dans un champ ou des macros mélangées à du texte ne sont pas pris en charge.
Délai d’expiration	Définissez le délai d’expiration de la vérification de l’élément (disponible pour les types d’éléments pris en charge). Sélectionnez l’option de délai d’expiration : Global - le délai d’expiration du proxy ou le délai global est utilisé (affiché dans le champ Délai d’expiration grisé). Remplacement - un délai d’expiration personnalisé est utilisé (défini dans le champ Délai d’expiration ; plage autorisée : 1 - 600s). Les suffixes de temps, par exemple 30s et 1m, ainsi que les macros utilisateur sont pris en charge. Cliquer sur le lien Délais d’expiration permet de configurer les délais d’expiration du proxy ou les délais d’expiration globaux (si aucun proxy n’est utilisé). Notez que le lien Délais d’expiration est visible uniquement pour les utilisateurs de type Super administrateur disposant des autorisations nécessaires pour les sections de l’interface Administration > Général ou Administration > Proxies.
Historique	Sélectionnez l’une des options suivantes : Ne pas stocker - l’historique de l’élément n’est pas stocké. Utile pour les éléments maîtres si seuls les éléments dépendants doivent conserver leur historique. Ce paramètre ne peut pas être remplacé par les paramètres globaux du housekeeper. Stocker jusqu’à - indiquez la durée de conservation de l’historique détaillé dans la base de données (de 1 heure à 25 ans). Les données plus anciennes seront supprimées par le housekeeper. La durée est stockée en secondes. Les suffixes de temps sont pris en charge, par exemple 2h, 1d. Les macros utilisateur sont prises en charge. La valeur Stocker jusqu’à peut être remplacée globalement dans Administration > Housekeeper. Si un paramètre global de remplacement existe, une icône d’information orange est affichée. Si vous placez le pointeur de la souris dessus, un message d’avertissement s’affiche, par exemple : Remplacé par les paramètres globaux du housekeeper (1d). Il est recommandé de conserver les valeurs enregistrées pendant la durée la plus courte possible afin de réduire la taille de l’historique des valeurs dans la base de données. Au lieu de stocker un historique de valeurs long, vous pouvez conserver plus longtemps les données de tendance. Voir également Historique et tendances.
Tendances	Sélectionnez l’une des options suivantes : Ne pas stocker - les tendances ne sont pas stockées. Ce paramètre ne peut pas être remplacé par les paramètres globaux du housekeeper. Stocker jusqu’à - indiquez la durée de conservation de l’historique agrégé (minimum, maximum, moyenne et nombre horaires) dans la base de données (de 1 jour à 25 ans). Les données plus anciennes seront supprimées par le housekeeper. La durée est stockée en secondes. Les suffixes de temps sont pris en charge, par exemple 24h, 1d. Les macros utilisateur sont prises en charge. La valeur Stocker jusqu’à peut être remplacée globalement dans Administration > Housekeeper. Si un paramètre global de remplacement existe, une icône d’information orange est affichée. Si vous placez le pointeur de la souris dessus, un message d’avertissement s’affiche, par exemple : Remplacé par les paramètres globaux du housekeeper (7d). Remarque : la conservation des tendances n’est pas disponible pour les données non numériques : caractère, journal et texte. Voir également Historique et tendances.
Mappage de valeurs	Appliquez un mappage de valeurs à cet élément. Le mappage de valeurs ne modifie pas les valeurs reçues ; il sert uniquement à afficher les données. Il fonctionne avec les éléments Numérique (non signé), Numérique (flottant) et Caractère. Par exemple, « États des services Windows ».
Format de l’heure du journal	Disponible uniquement pour les éléments de type Journal. Espaces réservés pris en charge : y : année (1970-2038). M : mois (01-12). d : jour (01-31). h : heure (00-23). m : minute (00-59). s : seconde (00-59). Si le champ est laissé vide, l’horodatage sera défini sur 0 en temps Unix, ce qui représente le 1er janvier 1970. Par exemple, considérons la ligne suivante du fichier journal de Zabbix agent : « 23480:20100328:154718.045 Zabbix agent started. Zabbix 1.8.2 (revision 11211). » Elle commence par six positions de caractères pour le PID, suivies de la date, de l’heure et du reste du message. Le format de l’heure du journal pour cette ligne serait « pppppp:yyyyMMdd:hhmmss ». Notez que les caractères « p » et « : » sont des espaces réservés et peuvent être remplacés par n’importe quels caractères, à l’exception de « yMdhms ».
Remplit le champ d’inventaire de l’hôte	Vous pouvez sélectionner un champ d’inventaire de l’hôte que la valeur de l’élément remplira. Cela fonctionne si le remplissage automatique de l’inventaire est activé pour l’hôte et avec les éléments Numérique (non signé), Numérique (flottant), Caractère et Texte.
Description	Saisissez une description de l’élément. Les macros utilisateur sont prises en charge.
Activé	Cochez la case pour activer l’élément afin qu’il soit traité. Lorsque vous désactivez l’élément, il est immédiatement supprimé du cache de l’historique (à l’exception de sa dernière valeur, qui est conservée pour les journaux).
Dernières données	Cliquez sur le lien pour afficher les dernières données de l’élément. Ce lien est disponible uniquement lors de la modification d’un élément existant.

L’onglet Étiquettes permet de définir les étiquettes au niveau de l’élément.

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

L'onglet Prétraitement vous permet de définir des règles de transformation pour les valeurs reçues.

Test d'élément

Il est possible de tester un élément et, s'il est correctement configuré, d'obtenir une valeur réelle en retour. Le test peut être effectué même avant l'enregistrement d'un élément.

Le test est disponible pour les éléments d'hôte et de modèle, les prototypes d'élément et les règles de découverte bas niveau. Le test n'est pas disponible pour les éléments actifs.

Le test d'élément est disponible pour les types d'élément passifs suivants :

• Zabbix agent
• SNMP agent (v1, v2, v3)
• IPMI agent
• SSH checks
• Telnet checks
• JMX agent
• Simple checks (except icmpping*, vmware.* items)
• Zabbix internal
• Calculated items
• External checks
• Database monitor
• HTTP agent
• Script
• Browser

Pour tester un élément, cliquez sur le bouton Test en bas du formulaire de configuration de l'élément. Notez que le bouton Test sera désactivé pour les éléments qui ne peuvent pas être testés (comme les vérifications actives, les vérifications simples exclues).

Le formulaire de test d'élément comporte des champs pour les paramètres d'hôte requis (adresse de l'hôte, port, test avec serveur/proxy (nom du proxy)) et des détails spécifiques à l'élément (tels que la communauté SNMPv2 ou les identifiants de sécurité SNMPv3). Ces champs sont contextuels :

• Les valeurs sont préremplies lorsque cela est possible, c'est-à-dire, pour les éléments nécessitant un agent, en prenant les informations de l'interface agent sélectionnée de l'hôte.
• Les valeurs doivent être saisies manuellement pour les éléments de modèle.
• Les valeurs des macros en texte brut sont résolues.
• Les champs dont la valeur (ou une partie de la valeur) est un secret ou une macro Vault sont vides et doivent être saisis manuellement. Si un paramètre d'élément contient une valeur de macro secrète, le message d'avertissement suivant s'affiche : "Item contains user-defined macros with secret values. Values of these macros should be entered manually."
• Les champs sont désactivés lorsqu'ils ne sont pas nécessaires dans le contexte du type d'élément (par exemple, le champ d'adresse de l'hôte et le champ du proxy sont désactivés pour les éléments calculés)

Pour tester l'élément, cliquez sur Get value. Si la valeur est récupérée avec succès, elle remplira le champ Value, en déplaçant la valeur actuelle (le cas échéant) vers le champ Previous value tout en calculant également le champ Prev. time, c'est-à-dire la différence de temps entre les deux valeurs (clics), et en essayant de détecter une séquence EOL et de passer à CRLF si "\n\r" est détecté dans la valeur récupérée.

Cliquez sur Get value and test pour tester le prétraitement.

Les valeurs récupérées depuis un hôte et les résultats de test sont tronqués à une taille maximale de 512 KB lorsqu'ils sont envoyés à l'interface. Si un résultat de test est tronqué, une icône d'avertissement s'affiche ; survolez-la pour plus de détails. Si une valeur est tronquée, elle peut échouer à la validation du type de données lors de tests consécutifs comparant de grandes valeurs (par exemple, JSON) ; dans ce cas, un message d'erreur s'affiche. Notez que les données supérieures à 512 KB sont toujours entièrement traitées par le serveur Zabbix.

Si la configuration est incorrecte, un message d'erreur décrivant la cause possible s'affiche.

Une valeur récupérée avec succès depuis l'hôte peut également être utilisée pour tester les étapes de prétraitement.

Boutons du formulaire

Les boutons situés en bas du formulaire vous permettent d'effectuer plusieurs opérations.

	Ajouter un élément. Ce bouton est disponible uniquement pour les nouveaux éléments.
	Mettre à jour les propriétés d'un élément.
	Créer un autre élément à partir des propriétés de l'élément actuel.
	Exécuter immédiatement une vérification pour obtenir une nouvelle valeur d'élément. Pris en charge uniquement pour les vérifications passives (voir plus de détails). Remarque : lors de la vérification immédiate d'une valeur, le cache de configuration n'est pas mis à jour ; la valeur ne reflétera donc pas les modifications très récentes de la configuration de l'élément.
	Tester si la configuration de l'élément est correcte en obtenant une valeur.
	Supprimer l'historique et les tendances de l'élément.
	Supprimer l'élément.
	Annuler la modification des propriétés de l'élément.

Limites des données d'élément

Les limites des données d'élément dépendent du type de données de l'élément et du backend de base de données.

Les valeurs numériques (non signées) sont stockées telles quelles. Si une valeur à virgule flottante est reçue, seule la partie entière est stockée (par exemple, 1.23 → 1).

Les valeurs numériques (float) sont stockées telles quelles et prennent en charge environ 15 à 17 chiffres de précision, avec une plage d'environ -1.79E+308 à 1.79E+308. Les valeurs en notation scientifique sont également prises en charge (par exemple, 1.23E+7, 1e308, 1.1E-4).

Les valeurs textuelles sont tronquées avant d'être stockées afin de respecter la limite du type de valeur de la base de données :

Les valeurs binaires sont limitées à 16 MiB (16777216 octets). Les valeurs qui dépassent cette limite sont ignorées, et une erreur correspondante est affichée dans l'interface.

Les valeurs avec le type de données JSON sont limitées à 128 MiB (134217728 octets). Les valeurs qui dépassent cette limite sont ignorées, et une erreur correspondante est affichée dans l'interface. Pour MySQL/MariaDB, envisagez de configurer des partitions quotidiennes pour la table history_json (utilisée pour stocker les valeurs JSON), car elle peut grossir rapidement et verrouiller le housekeeper pendant une période prolongée. Si votre cas d'utilisation implique de grandes valeurs JSON (1 MiB ou plus), consultez la procédure de configuration de votre système pour la prise en charge des grandes valeurs JSON.

Lorsque Zabbix écrit des données d'élément dans la base de données, il utilise des requêtes INSERT et les journalise (si DebugLevel est défini sur 4 ou 5). Les grandes entrées de journal sont tronquées à 64 Ko.

Limite des scripts personnalisés

La longueur disponible pour les scripts personnalisés dépend de la base de données utilisée :

Délai d'expiration de l'élément

Le délai d'expiration de l'élément spécifie combien de temps Zabbix doit attendre avant d'interrompre la vérification en la considérant comme échouée.

Lorsque le délai d'expiration est atteint, la vérification est interrompue même si la récupération des données n'est pas terminée. Si les données sont reçues partiellement, l'élément devient non pris en charge et un message d'erreur est consigné (par exemple, si les données sont collectées avec succès pour un seul des plusieurs OID dans une vérification SNMP).

Pour de nombreux types d'éléments, vous pouvez définir des délais d'expiration flexibles pour les éléments:

• pour un seul élément
• par type d'élément (au niveau d'un proxy)
• par type d'élément (au niveau global interface)

Un délai d'expiration personnalisé pour un seul élément est utile si vous souhaitez spécifier un délai plus long pour un élément particulier, tout en conservant des délais courts pour les autres éléments.

Priorité des délais d'expiration

1. Le délai d'expiration d'un seul élément remplace tout autre délai.
2. Les délais d'expiration au niveau du proxy remplacent les délais d'expiration globaux.

Le délai d'expiration provenant de la configuration du serveur Zabbix ou du proxy ne joue aucun rôle dans les vérifications pour lesquelles des délais d'expiration flexibles sont définis.

Prise en charge des délais d'attente flexibles

Les délais d'attente flexibles des éléments sont pris en charge pour les types d'éléments suivants :

• agent Zabbix (vérifications passives et actives)
• agent SNMP (sauf les vérifications SNMP héritées¹)
• Vérification simple (sauf icmpping* et les éléments VMware²)
• agent SSH
• agent Telnet
• Vérification externe
• Surveillance de base de données
• Script
• agent HTTP

• Navigateur

  ¹ Pour les vérifications SNMP héritées (interrogation d'un seul OID), les paramètres de délai d'attente du serveur ou du proxy s'appliquent.
  ² Pour les éléments icmpping*, la valeur du délai d'attente est spécifiée directement dans la clé de l'élément ; une valeur maximale codée en dur de 600 secondes s'applique également. Les éléments de surveillance VMware utilisent leur propre paramètre VMwareTimeout issu de la configuration du serveur ou du proxy.

Éléments non pris en charge

Les éléments non pris en charge sont signalés avec le statut Non pris en charge et sont toujours revérifiés selon leur Intervalle de mise à jour standard.

Un élément devient non pris en charge si sa valeur ne peut pas être récupérée pour une raison quelconque (par exemple, une erreur de connexion, aucun poller configuré pour traiter l’élément). De plus, les éléments qui ne reçoivent pas de données historiques restent dans le statut Non pris en charge. Il s’agit du comportement attendu : un élément passe au statut Normal uniquement lorsqu’il reçoit de nouvelles données historiques valides.

Comme les problèmes, les éléments non pris en charge ne sont réévalués que lorsque de nouvelles données sont reçues, même s’il n’y a plus de données historiques disponibles pour cet élément. En d’autres termes, les éléments et les déclencheurs changent d’état uniquement lors de la réception de nouvelles données. Cependant, si une expression de déclencheur inclut une fonction date and time et/ou nodata(), le déclencheur sera recalculé toutes les 30 secondes (voir triggers calculation time pour plus de détails).