This is the documentation page for an unsupported version of Zabbix.
Is this not what you were looking for? Switch to the current version or choose one from the drop-down menu.

3 Découverte de bas niveau

Aperçu

La découverte de bas niveau permet de créer automatiquement des éléments, des déclencheurs et des graphiques pour différentes entités sur un ordinateur. Par exemple, Zabbix peut démarrer automatiquement la surveillance des systèmes de fichiers ou des interfaces réseaux sur votre ordinateur, sans qu'il soit nécessaire de créer manuellement des éléments pour chaque système de fichiers ou interface réseau. De plus, il est possible de configurer Zabbix pour qu'il supprime automatiquement les entités inutiles en fonction des résultats réels de la découverte effectuée périodiquement.

Un utilisateur peut définir ses propres types de découverte, à condition de suivre un protocole JSON particulier.

L'architecture générale du processus de découverte est la suivante.

Tout d'abord, un utilisateur crée une règle de découverte dans la colonne "Configuration" → "Modèles" → "Découverte". Une règle de découverte consiste en (1) un élément qui découvre les entités nécessaires (par exemple, des systèmes de fichiers ou des interfaces réseau) et (2) des prototypes d'éléments, de déclencheurs et de graphiques qui doivent être créés en fonction de la valeur de cet élément.

Un élément qui découvre les entités nécessaires est comme un élément standard vu ailleurs : le serveur demande à un agent Zabbix (ou quel que soit le type d’élément défini) une valeur de cet élément, l’agent répond avec une valeur textuelle. La différence est que la valeur avec laquelle l'agent répond doit contenir une liste d'entités découvertes dans un format JSON spécifique. Bien que les détails de ce format ne soient importants que pour les développeurs de vérifications de découverte personnalisées, il est nécessaire de savoir que la valeur renvoyée contient une liste de paires macro → valeur. Par exemple, l'élément “net.if.discovery” peut renvoyer deux paires : “{#IFNAME}” → “lo” et “{#IFNAME}” → “eth0”.

Ces macros sont utilisées dans les noms, les clés et les autres champs prototypes où elles sont ensuite remplacées par les valeurs reçues pour créer des éléments réels, des déclencheurs, des graphiques ou même des hôtes pour chaque entité découverte. Consultez la liste complète des options d’utilisation des macros LLD.

Lorsque le serveur reçoit une valeur pour un élément de découverte, il examine les paires macro → valeur et génère pour chaque paire des éléments réels, des déclencheurs et des graphiques, en fonction de leurs prototypes. Dans l'exemple avec "net.if.discovery" ci-dessus, le serveur générerait un ensemble d'éléments, de déclencheurs et de graphiques pour l'interface loopback "lo" et un autre ensemble pour l'interface "eth0".

Voir aussi : Entités découvertes

Configuration de la découverte de bas niveau

Nous allons illustrer la découverte de bas niveau en nous basant sur un exemple de découverte de système de fichiers.

Pour configurer la découverte, procédez comme suit :

  • Aller dans ConfigurationModèles
  • Cliquez sur Découverte dans la ligne d'un modèle approprié.

  • Cliquez sur Créer une règle de découverte dans le coin supérieur droit de l'écran.
  • Remplissez le formulaire de règle de découverte avec les détails requis

Règle de découverte

L'onglet Règle de découverte contient les attributs généraux de règle de découverte :

Tous les champs de saisie obligatoires sont marqués d'un astérisque rouge.

Paramètre Description
Nom Nom de la règle de découverte.
Type Le type de vérification pour effectuer la découverte ; doit être agent Zabbix ou agent Zabbix (actif) pour la découverte du système de fichier.
Clé Un élément avec la clé "vfs.fs.découverte" est intégré à l’agent Zabbix depuis la version 2.0 sur de nombreuses plates-formes (voir la liste des clés d’élément supportées pour plus de détails) et renverra un JSON avec la liste des systèmes de fichiers présents sur l’ordinateur et leurs types.
Intervalle d'actualisation Ce champ spécifie la fréquence à laquelle Zabbix effectue la découverte. Au début, lorsque vous configurez simplement la découverte de système de fichiers, vous pouvez définir un intervalle réduit, mais une fois que vous savez que cela fonctionne, vous pouvez le définir sur 30 minutes ou plus, car les systèmes de fichiers ne changent généralement pas très souvent.
Les suffixes temporels sont supportés, ex : 30s, 1m, 2h, 1d, depuis Zabbix 3.4.0.
Les macros utilisateurs sont supportées, depuis Zabbix 3.4.0.
Remarque : Si la valeur est '0', l'élément ne sera pas interrogé. Toutefois, si un intervalle flexible existe également avec une valeur différente de zéro, l'élément sera interrogé pendant la durée de l'intervalle flexible.
Notez que pour une règle de découverte existante, la découverte peut être effectuée immédiatement en appuyant sur le bouton Vérifier maintenant.
Intervalle personnalisé Vous pouvez créer des règles personnalisées pour vérifier l'élément :
Flexible - créer une exception à l'intervalle d'actualisation (intervalle avec une fréquence différente)
Planification - créez un calendrier d'interrogation personnalisé.
Pour plus d'informations, voir Intervalles personnalisés. La planification est supportée depuis Zabbix 3.0.0.
Période de conservation des ressources perdues Ce champ vous permet de spécifier la durée pendant laquelle l’entité découverte sera conservée (elle ne sera pas supprimée) une fois que son statut de découverte deviendra "Plus découvert" (entre 1 heure et 25 ans ; ou "0").
Les suffixes temporels sont supportés, ex : 2h, 1d, depuis Zabbix 3.4.0.
Les macros utilisateurs sont supportées, depuis Zabbix 3.4.0.
Remarque : Si la valeur est "0", les entités seront immédiatement supprimées. L'utilisation de "0" n'est pas recommandée, car une modification incorrecte du filtre risque de se retrouver dans l'entité en cours de suppression avec toutes les données historiques.
Description Entrez une description.
Activé Si coché, la règle sera traitée.

Filtre de règle de découverte

L'onglet Filtres contient les définitions de filtre de règle de découverte :

Paramètre Description
Type de calcul Les options suivantes pour le calcul des filtres sont disponibles :
Et - tous les filtres doivent être corrects ;
Ou - suffisant si un filtre est correct ;
Et/Ou - utilise Et avec des noms de macro différents et Ou avec le même nom de macro ;
Expression personnalisée - offre la possibilité de définir un calcul personnalisé de filtres. La formule doit inclure tous les filtres de la liste. Limité à 255 symboles.
Filtres Un filtre peut être utilisé pour générer des éléments réels, des déclencheurs et des graphiques uniquement pour certains systèmes de fichiers. Il attend une expression régulière compatible Perl (PCRE). Par exemple, si vous êtes uniquement intéressé par les systèmes de fichiers C:, D: et E:, vous pouvez insérer {#FSNAME} dans "Macro" et l'expression régulière "^C|^D|^E" dans le champs "Expression régulière". Le filtrage est également possible par type de système de fichiers utilisant la macro {#FSTYPE} (par exemple, "^ext|^reiserfs") et par types de lecteur (supporté uniquement par l'agent Windows) en utilisant une macro {#FSDRIVETYPE} (par exemple, "fixed").
Vous pouvez entrer une expression régulière ou référencer une expression régulière globale dans le champ "Expression régulière".
Pour tester une expression régulière, vous pouvez utiliser "grep -E", par exemple : for f in ext2 nfs reiserfs smbfs; do echo $f \| grep -E '^ext\|^reiserfs' \|\| echo "SKIP: $f"; done La macro {#FSDRIVETYPE} sous Windows est prise en charge depuis Zabbix 3.0.0.
La définition de plusieurs filtres est prise en charge depuis Zabbix 2.4.0.
Notez que si une macro du filtre manque dans la réponse, l'entité trouvée sera ignorée.
La liste déroulante Filtre offre deux valeurs permettant de spécifier si une macro correspond à une expression régulière ou non.

La base de données Zabbix dans MySQL doit être créée avec une distinction entre les majuscules et les minuscules si les noms de système de fichiers ne différant que par les majuscules doivent être correctement reconnus.

L'erreur ou la faute de frappe dans regex utilisée dans la règle LLD peut entraîner la suppression de milliers d'éléments de configuration, de valeurs historiques et d'événements pour de nombreux hôtes. Par exemple, une expression régulière "Systèmes de fichiers pour la découverte" incorrecte peut entraîner la suppression de milliers d'éléments, de déclencheurs, de valeurs historiques et d'événements.

L'historique des règles de découverte n'est pas conservé.

Boutons de formulaire

Les boutons au bas du formulaire permettent d'effectuer plusieurs opérations.

Ajouter une règle de découverte. Ce bouton est uniquement disponible pour les nouvelles règles de découverte.
Mettre à jour les propriétés d'une règle de découverte. Ce bouton est uniquement disponible pour les règles de découverte existantes.
Créer une autre règle de découverte basée sur les propriétés de la règle de découverte actuelle.
Effectuer immédiatement une découverte basée sur la règle de découverte. La règle de découverte doit déjà exister. Voir plus de détails.
Notez que lors de l'exécution immédiate de la découverte, le cache de configuration n'est pas mis à jour. Par conséquent, le résultat ne reflète pas les modifications très récentes apportées à la configuration des règles de découverte.
Supprimer la règle de découverte.
Annuler la modification des propriétés de la règle de découverte.

Prototypes d'élément

Une fois la règle créée, accédez aux éléments de cette règle et appuyez sur "Créer un prototype" pour créer un prototype d’élément. Notez comment la macro {#FSNAME} est utilisée lorsqu'un nom de système de fichiers est requis. Lorsque la règle de découverte est traitée, cette macro sera remplacée par le système de fichiers découvert.

Des macros de découverte de bas niveau et des macros utilisateur peuvent être utilisées dans la configuration du prototype d'élément et les paramètres de pré-traitement de la valeur d'élément. Notez que lorsqu'elle est utilisée dans les intervalles de mise à jour, une seule macro doit remplir tout le champ. Plusieurs macros dans un champ ou des macros mélangées avec du texte ne sont pas supportées.

Un échappement spécifique au contexte des macros de découverte de bas niveau est effectué pour une utilisation en toute sécurité dans les paramètres d'expressions régulières et de prétraitement XPath.

Attributs spécifiques aux prototypes d'élément :

Paramètre Description
Nouveau prototype d'application Vous pouvez définir un nouveau prototype d'application.
Dans les prototypes d'application, vous pouvez utiliser des macros de découverte de bas niveau qui, après la découverte, seront remplacées par des valeurs réelles pour créer des applications spécifiques à l'entité découverte. Voir aussi les notes de découverte d'application pour des informations plus spécifiques.
Prototypes d'applications Sélectionnez parmi les prototypes d'application existants.
Créer activé Si coché, l'élément sera ajouté dans un état activé.
Si cette case n'est pas cochée, l'élément sera ajouté à une entité découverte, mais dans un état désactivé.

Nous pouvons créer plusieurs prototypes d'éléments pour chaque métrique de système de fichiers qui nous intéresse :

Prototypes de déclencheurs

Nous créons des prototypes de déclencheurs de la même manière que les prototypes d'éléments :

Attributs spécifiques aux prototypes de déclencheurs :

Paramètre Description
Créer activé Si coché, le déclencheur sera ajouté dans un état activé.
Si cette case n'est pas cochée, le déclencheur sera ajouté à une entité découverte, mais dans un état désactivé.

Lorsque des déclencheurs réels sont créés à partir des prototypes, il peut s'avérer nécessaire de faire preuve de souplesse quant à la constante ('20' dans notre exemple) utilisée pour la comparaison dans l'expression. Découvrez comment des macros utilisateur avec contexte peuvent être utiles pour obtenir une telle flexibilité.

Vous pouvez également définir des dépendances entre les prototypes de déclencheur (supporté depuis Zabbix 3.0). Pour ce faire, allez dans l'onglet Dépendances. Un prototype de déclencheur peut dépendre d'un autre prototype de déclencheur de la même règle de découverte de bas niveau (LLD) ou d'un déclencheur normal. Un prototype de déclencheur peut ne pas dépendre d'un prototype de déclencheur provenant d'une règle LLD différente ou d'un déclencheur créé à partir du prototype de déclencheur. Le prototype de déclencheur d'hôte ne peut pas dépendre d'un déclencheur d'un modèle.

Prototypes de graphiques

Nous pouvons aussi créer des prototypes de graphiques :

Enfin, nous avons créé une règle de découverte semblable à celle présentée ci-dessous. Il comporte cinq prototypes d'élément, deux prototypes de déclencheur et un prototype de graphe.

Remarque : pour configurer les prototypes d'hôte, reportez-vous à la section relative à la configuration du prototype d'hôte dans la supervision des machines virtuelles.

Entités découvertes

Les captures d'écran ci-dessous illustrent l'aspect des éléments découverts, des déclencheurs et des graphiques dans la configuration de l'hôte. Les entités découvertes sont préfixées par un lien orange vers une règle de découverte dont elles proviennent.

Notez que les entités découvertes ne seront pas créées s'il existe déjà des entités avec les mêmes critères d'unicité, par exemple, un élément avec la même clé ou le même graphique portant le même nom. Dans ce cas, un message d'erreur indique que la règle de découverte de bas niveau n'a pas pu créer certaines entités.

Les éléments (de même que les déclencheurs et les graphiques) créés par une règle de découverte de bas niveau seront automatiquement supprimés si une entité découverte (système de fichiers, interface, etc.) cesse d'être découverte (ou ne correspond plus au filtre). Dans ce cas, les éléments, les déclencheurs et les graphiques seront supprimés une fois que les jours définis dans le champ Période de conservation des ressources perdues seront dépassés.

Lorsque les entités découvertes deviennent 'Plus découvertes', un indicateur de durée de vie est affiché dans la liste des éléments. Déplacez le pointeur de la souris dessus pour afficher un message indiquant le nombre de jours restant avant la suppression de l'élément.

Si des entités ont été marquées pour suppression, mais n'ont pas été supprimées à l'heure prévue (règle de découverte désactivée ou hôte d'élément), elles seront supprimées lors du prochain traitement de la règle de découverte.

Les entités contenant d'autres entités marquées pour suppression ne seront pas mises à jour si elles sont modifiées au niveau de la règle de découverte. Par exemple, les déclencheurs basés sur LLD ne seront pas mis à jour s'ils contiennent des éléments marqués pour suppression.

Autres types de découverte

Vous trouverez plus de détails et de procédures sur d'autres types de découverte immédiate dans les sections suivantes :

Pour plus de détails sur le format JSON pour les éléments découverts et un exemple sur la manière d'implémenter votre propre découvreur de système de fichiers en tant que script Perl, voir Création de règles LLD personnalisées.

Limites de données pour les valeurs de retour

Les données JSON de règles de découverte de niveau inférieur ne sont pas limitées si elles sont reçues directement par le serveur Zabbix, car les valeurs renvoyées sont traitées sans être stockées dans une base de données. Il n'y a pas non plus de limite pour les règles de découverte de bas niveau personnalisées. Toutefois, si vous souhaitez acquérir des données LLD personnalisées à l'aide d'un paramètre utilisateur, la limite de la valeur de retour de paramètre utilisateur s'applique (512 Ko).

Si les données doivent passer par le proxy Zabbix, elles doivent être stockées dans une base de données pour que les limites de la base de données s'appliquent, par exemple, 2 048 octets sur un proxy Zabbix exécuté avec une base de données IBM DB2.

Plusieurs règles LLD pour le même élément

Depuis la version 3.2 de l’agent Zabbix, il est possible de définir plusieurs règles de découverte de bas niveau avec le même élément de découverte.

Pour ce faire, vous devez définir le paramètre agent Alias, permettant d’utiliser des clés d’éléments de découverte modifiées dans différentes règles de découverte, par exemple vfs.fs.discovery[foo], vfs.fs.discovery[bar], etc.

Création de règles LLD personnalisées

Il est également possible de créer une règle LLD entièrement personnalisée, découvrant tout type d’entités - par exemple, des bases de données sur un serveur de base de données.

Pour ce faire, vous devez créer un élément personnalisé renvoyant un JSON, en spécifiant les objets trouvés et éventuellement - certaines de leurs propriétés. Le nombre de macros par entité n'est pas limité - bien que les règles de découverte intégrées renvoient une ou deux macros (par exemple, deux pour la découverte de système de fichiers), il est possible d'en renvoyer davantage.

Le format JSON requis est mieux illustré par un exemple. Supposons que nous utilisions un ancien agent Zabbix 1.8 (un agent qui ne prend pas en charge "vfs.fs.discovery"), mais que nous devons toujours découvrir les systèmes de fichiers. Voici un script Perl simple pour Linux qui découvre les systèmes de fichiers montés et génère du JSON, qui inclut le nom et le type du système de fichiers. Une façon de l'utiliser serait comme un UserParameter avec la clé "vfs.fs.discovery_perl" :

#!/usr/bin/perl
       
       $first = 1;
       
       print "{\n";
       print "\t\"data\":[\n\n";
       
       for (`cat /proc/mounts`)
       {
           ($fsname, $fstype) = m/\S+ (\S+) (\S+)/;
       
           print "\t,\n" if not $first;
           $first = 0;
       
           print "\t{\n";
           print "\t\t\"{#FSNAME}\":\"$fsname\",\n";
           print "\t\t\"{#FSTYPE}\":\"$fstype\"\n";
           print "\t}\n";
       }
       
       print "\n\t]\n";
       print "}\n";

Les symboles autorisés pour les noms de macro LLD sont 0-9 , A-Z , _ , .

Les lettres minuscules ne sont pas prises en charge dans les noms.

Un exemple de son résultat (reformaté pour plus de clarté) est présenté ci-dessous. Le JSON pour les vérifications de découverte personnalisées doit suivre le même format.

{
         "data":[
         
         { "{#FSNAME}":"/",                           "{#FSTYPE}":"rootfs"   },
         { "{#FSNAME}":"/sys",                        "{#FSTYPE}":"sysfs"    },
         { "{#FSNAME}":"/proc",                       "{#FSTYPE}":"proc"     },
         { "{#FSNAME}":"/dev",                        "{#FSTYPE}":"devtmpfs" },
         { "{#FSNAME}":"/dev/pts",                    "{#FSTYPE}":"devpts"   },
         { "{#FSNAME}":"/lib/init/rw",                "{#FSTYPE}":"tmpfs"    },
         { "{#FSNAME}":"/dev/shm",                    "{#FSTYPE}":"tmpfs"    },
         { "{#FSNAME}":"/home",                       "{#FSTYPE}":"ext3"     },
         { "{#FSNAME}":"/tmp",                        "{#FSTYPE}":"ext3"     },
         { "{#FSNAME}":"/usr",                        "{#FSTYPE}":"ext3"     },
         { "{#FSNAME}":"/var",                        "{#FSTYPE}":"ext3"     },
         { "{#FSNAME}":"/sys/fs/fuse/connections",    "{#FSTYPE}":"fusectl"  }
         
         ]
       }

Ensuite, dans le champ "Filtre" de la règle de découverte, vous pouvez spécifier "{#FSTYPE}" en tant que macro et "rootfs|ext3" en tant qu'expression régulière.

Vous n'êtes pas obligé d'utiliser les noms de macro FSNAME/FSTYPE avec les règles personnalisées LLD, vous êtes libre d'utiliser les noms de votre choix.

Notez que si vous utilisez un paramètre utilisateur, la valeur de retour est limitée à 512 Ko. Pour plus de détails, voir Limites de données pour les valeurs de retour LLD.

Utilisation de macros LLD dans des contextes de macro utilisateur

Les macros utilisateur avec contexte peuvent être utilisées pour atteindre des seuils plus souples dans les expressions de déclencheur. Différents seuils peuvent être définis au niveau macro utilisateur puis utilisés dans des constantes de déclencheur en fonction du contexte découvert. Le contexte découvert apparaît lorsque les macros de découverte de bas niveau utilisées dans les macros sont résolues en valeurs réelles.

Pour illustrer notre propos, nous pouvons utiliser les données de l'exemple ci-dessus et supposer que les systèmes de fichiers suivants seront découverts : /, /home, /tmp, /usr, /var.

Nous pouvons définir un prototype de déclencheur d'espace disque libre pour un hôte, où le seuil est exprimé par une macro utilisateur avec un contexte :

{host:vfs.fs.size[{#FSNAME},pfree].last()}<{$LOW_SPACE_LIMIT:"{#FSNAME}"}

Ajoutez ensuite les macros utilisateur :

  • {$LOW_SPACE_LIMIT} 10
  • {$LOW_SPACE_LIMIT:/home} 20
  • {$LOW_SPACE_LIMIT:/tmp} 50

Maintenant, une fois les systèmes de fichiers découverts, des événements seront générés si les systèmes de fichiers /, /usr et /var ont moins de 10 % d’espace disque disponible, le système de fichiers /home - moins de 20 % d’espace disque disponible ou le système de fichiers /tmp - moins de 50 % de l'espace disque disponible.