This is a translation of the original English documentation page. Help us make it better.

Sidebar

Become a monitoring expert!
Sign up for Zabbix training

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".

Notez que depuis ** Zabbix 4.2 **, le format du JSON renvoyé par les règles de découverte de bas niveau a été modifié. Il n'est plus prévu que le JSON contienne l'objet "data". La découverte de bas niveau acceptera désormais un JSON normal contenant un tableau, afin de prendre en charge de nouvelles fonctionnalités telles que le prétraitement de la valeur d'élément et les chemins personnalisés vers les valeurs de macro de découverte de bas niveau dans un document JSON.

Les clés de découverte intégrées ont été mises à jour pour renvoyer un tableau de lignes LLD à la racine du document JSON. Zabbix extraira automatiquement une macro et une valeur si un champ de tableau utilise la syntaxe {#MACRO} comme clé. Toute nouvelle vérification de découverte native utilisera la nouvelle syntaxe sans les éléments "data". Lors du traitement d'une valeur de découverte de bas niveau, la racine est d'abord localisée (tableau à $. ou $.data).

Bien que l'élément "data" ait été supprimé de tous les éléments natifs liés à la découverte, pour des raisons de rétrocompatibilité, Zabbix acceptera toujours la notation JSON avec un élément "data", bien que son utilisation soit déconseillée. Si le JSON contient un objet avec un seul élément de tableau "data", il extraira automatiquement le contenu de l'élément en utilisant JSONPath $.data. La découverte de bas niveau accepte désormais les macros LLD facultatives définies par l'utilisateur avec un chemin personnalisé spécifié dans la syntaxe JSONPath.

Suite aux changements ci-dessus, les nouveaux agents ne pourront plus fonctionner avec un ancien serveur Zabbix.

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 ou Hôtes
  • Cliquez sur Découverte dans la ligne d'un modèle/hôte 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

Le formulaire de règle de découverte contient cinq onglets, représentant, de gauche à à droite, le flux de données lors de la découverte :

  • Règle de découverte - spécifie, surtout, l'élément intégré ou le script personnalisé pour récupérer les données de découverte
  • Prétraitement - applique un prétraitement aux données découvertes
  • macros LLD - permet d'extraire certaines valeurs de macro à utiliser dans les éléments découverts, les déclencheurs, etc.
  • Filtres - permet de filtrer les valeurs découvertes
  • Surcharge - permet de modifier des éléments, des déclencheurs, des graphiques ou des prototypes d'hôte lors de l'application à des objets découverts spécifiques

L'onglet Règle de découverte contient la clé d'élément à utiliser pour la découverte (ainsi que certains attributs généraux de la 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
Dans cet exemple, nous utilisons une clé d'élément agent Zabbix.
La règle de découverte peut également être un élément dépendant. Elle ne peut pas dépendre d'une autre règle de découverte. Pour un élément dépendant, sélectionnez le type respectif (Élément dépendant) et spécifiez l'élément maître dans le champ 'Élément maitre'. L'élément maître doit exister.
Clé Saisir la clé de l'élément de découverte (jusqu'à 2 048 caractères).
Par exemple, vous pouvez utiliser la clé d'élément intégrée "vfs.fs.discovery" pour renvoyer un JSON avec la liste des systèmes de fichiers présents sur l'ordinateur et leur types.
Notez qu'une autre option pour la découverte du système de fichiers utilise les résultats de la découverte par la clé d'agent "vfs.fs.get", prise en charge depuis Zabbix 4.4.5 (voir exemple).
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 : L'intervalle de mise à jour ne peut être défini sur '0' que s'il existe des intervalles personnalisés 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 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.

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

Prétraitement

L'onglet Prétraitement permet de définir des règles de transformation à appliquer au résultat de la découverte. Une ou plusieurs transformations sont possibles dans cette étape. Les transformations sont exécutées dans l'ordre dans lequel elles sont définies. Tout le prétraitement est effectué par le serveur Zabbix.

Voir également :

Type Transformation Description
Texte
Expression régulière Faire correspondre la valeur reçue à l'expression régulière <motif> et remplacez la valeur par la <sortie> extraite. L'expression régulière prend en charge l'extraction d'un maximum de 10 groupes capturés avec la séquence \N.
Paramètres :
motif - expression régulière
sortie - modèle de formatage de sortie. Une séquence d'échappement \N (où N=1…9) est remplacée par le Nième groupe correspondant. Une séquence d'échappement \0 est remplacée par le texte correspondant.
Si vous cochez la case Personnalisé en cas d'échec, il est possible de spécifier des options de gestion des erreurs personnalisées : soit pour ignorer la valeur, soit pour définir une valeur spécifiée, soit pour définir un message d'erreur spécifié.
Remplacer Trouver la chaîne de recherche et la remplacer par une autre (ou rien). Toutes les occurrences de la chaîne de recherche seront remplacées.
Paramètres :
chaîne recherchée - la chaîne à rechercher et à remplacer, sensible à la casse (obligatoire)
remplacement - la chaîne par laquelle remplacer la chaîne de recherche. La chaîne de remplacement peut également être vide, ce qui permet de supprimer la chaîne de recherche lorsqu'elle est trouvée.
Il est possible d'utiliser des séquences d'échappement pour rechercher ou remplacer les sauts de ligne, les retours chariot, les tabulations et les espaces "\n \r \t \s" ; la barre oblique inverse peut être échappée sous la forme "\\" et les séquences d'échappement peuvent être échappées sous la forme "\\n". L'échappement des sauts de ligne, des retours chariot et des tabulations est automatiquement effectué lors de la découverte de bas niveau.
Pris en charge depuis 5.0.0.
Données structurées
JSONPath Extraire une valeur ou un fragment de données JSON à l'aide de la fonctionnalité JSONPath.
Si vous cochez la case Personnalisé en cas d'échec, l'élément ne deviendra pas non pris en charge en cas d'échec de l'étape de prétraitement et il est possible de spécifier des options de gestion des erreurs personnalisées : soit pour ignorer la valeur, soit pour définir une valeur spécifiée, soit pour définir un message d'erreur spécifié .
XPath XML Extraire une valeur ou un fragment de données XML à l'aide de la fonctionnalité XPath.
Pour que cette option fonctionne, le serveur Zabbix doit être compilé avec le support libxml.
Exemples :
number(/document/item/value) extraira 10 de <document><item><value>10</value></item></document>
number(/document/item/@attribute) extraira 10 de<document><item attribute="10"></item></document>
/document/item extraira <item><value>10</value></item> de <document><item><value>10</value></item></document>
Notez que les espaces de noms ne sont pas pris en charge.
Pris en charge depuis la version 4.4.0.
Si vous cochez la case Personnalisé en cas d'échec, il est possible de spécifier des options de gestion des erreurs personnalisées : soit pour ignorer la valeur, soit pour définir une valeur spécifiée, soit pour définir un message d'erreur spécifié.
CSV vers JSON Convertir les données du fichier CSV au format JSON.
Pour plus d'informations, voir : Prétraitement CSV vers JSON.
Pris en charge depuis 4.4.0.
XML vers JSON Convertir les données au format XML en JSON.
Pour plus d'informations, voir : Règles de sérialisation.
Si vous cochez la case Personnalisé en cas d'échec, il est possible de spécifier des options de gestion des erreurs personnalisées : soit pour ignorer la valeur, soit pour définir une valeur spécifiée, soit pour définir un message d'erreur spécifié.
Scripts personnalisés
JavaScript Entrer le code JavaScript dans le bloc qui apparaît en cliquant dans le champ paramètre ou sur Ouvrir.
Notez que la longueur JavaScript disponible dépend de la base de données utilisée.
Pour plus d'informations, voir : Prétraitement JavaScript
Validation
Ne correspond pas à l'expression régulière Spécifier une expression régulière à laquelle une valeur ne doit pas correspondre.
Par exemple Error:(.*?)\.
Si vous cochez la case Personnalisé en cas d'échec, il est possible de spécifier des options de gestion des erreurs personnalisées : soit pour ignorer la valeur, soit pour définir une valeur spécifiée, soit pour définir un message d'erreur spécifié.
Rechercher une erreur dans le JSON Rechercher un message d'erreur au niveau de l'application situé dans JSONpath. Arrêtez le traitement en cas de succès et si le message n'est pas vide ; sinon, continuez le traitement avec la valeur qui était avant cette étape de prétraitement. Notez que ces erreurs de service externes sont signalées à l'utilisateur telles quelles, sans ajouter d'informations sur l'étape de prétraitement.
Par exemple $.errors. Si un JSON comme {"errors":"e1"} est reçu, la prochaine étape de prétraitement ne sera pas exécutée.
Si vous cochez la case Personnalisé en cas d'échec, il est possible de spécifier des options de gestion des erreurs personnalisées : soit pour ignorer la valeur, soit pour définir une valeur spécifiée, soit pour définir un message d'erreur spécifié.
Rechercher une erreur dans le XML Rechercher un message d'erreur au niveau de l'application situé dans xpath. Arrêtez le traitement en cas de succès et si le message n'est pas vide ; sinon, continuez le traitement avec la valeur qui était avant cette étape de prétraitement. Notez que ces erreurs de service externe sont signalées à l'utilisateur telles quelles, sans ajouter d'informations sur l'étape de prétraitement.
Aucune erreur ne sera signalée en cas d'échec de l'analyse du XML non valide.
Pris en charge depuis la version 4.4.0.
Si vous cochez la case Personnalisé en cas d'échec, il est possible de spécifier des options de gestion des erreurs personnalisées : soit pour ignorer la valeur, soit pour définir une valeur spécifiée, soit pour définir un message d'erreur spécifié.
Limitation
Ecarte les inchangés avec bit de vie Ignorer une valeur si elle n'a pas changé au cours de la période définie (en secondes).
Les valeurs entières positives sont prises en charge pour spécifier les secondes (minimum - 1 seconde). Des suffixes de temps peuvent être utilisés dans ce champ (par exemple 30s, 1m, 2h, 1d). Des macros utilisateur et des macros de découverte de bas niveau peuvent être utilisées dans ce champ.
Une seule option de limitation peut être spécifiée pour un élément de découverte.
Par exemple 1m. Si un texte identique est passé deux fois dans cette règle en 60 secondes, il sera supprimé.
Remarque : La modification des prototypes d'éléments ne réinitialise pas la limitation. La limitation est réinitialisée uniquement lorsque les étapes de prétraitement sont modifiées.
Prometheus
Prometheus vers JSON Convertire les métriques Prometheus requises en JSON.
Voir Vérifications Prometheus pour plus de détails.

Notez que si la règle de découverte a été appliquée à l'hôte via un modèle, le contenu de cet onglet est en lecture seule.

Macros personnalisées

L'onglet Macros LLD permet de spécifier des macros de découverte personnalisées de bas niveau.

Les macros personnalisées sont utiles dans les cas où le JSON renvoyé n'a pas les macros requises déjà définies. Ainsi, par exemple :

  • La clé native vfs.fs.discovery pour la découverte du système de fichiers renvoie un JSON avec des macros LLD prédéfinies telles que {#FSNAME}, {#FSTYPE}. Ces macros peuvent être utilisées dans l'élément, déclencher des prototypes (voir les sections suivantes de la page) directement ; la définition de macros personnalisées n'est pas nécessaire ;
  • L'élément d'agent vfs.fs.get renvoie également un JSON avec données du système de fichiers, mais sans macros LLD prédéfinies. Dans ce cas, vous pouvez définir vous-même les macros et les mapper aux valeurs du JSON à l'aide de JONPath :

Les valeurs extraites peuvent être utilisées dans les éléments découverts, les déclencheurs, etc. Notez que les valeurs seront extraites du résultat de la découverte et de toutes les étapes de prétraitement traitées jusqu'à présent.

Paramètre Description
macro LLD Nom de la macro de découverte de bas niveau, utilisant la syntaxe suivante : {#MACRO}.
JSONPath Chemin utilisé pour extraire la valeur de macro LLD d'une ligne LLD, en utilisant la syntaxe JSONPath.
Par exemple, $.foo extraira "bar" et "baz" de ce JSON : [{"foo":" bar"}, {"foo":"baz"}]
Les valeurs extraites du JSON renvoyé sont utilisées pour remplacer les macros LLD dans les champs de prototype d'élément, de déclencheur, etc.
JSONPath peut être spécifié à l'aide la notation pointée ou la notation parenthèse. La notation entre parenthèses doit être utilisée dans le cas de caractères spéciaux et d'Unicode, comme $['unicode + special chars #1']['unicode + special chars #2'].

Filtres

Un filtre peut être utilisé pour générer des éléments réels, des déclencheurs et des graphiques uniquement pour les entités qui correspondent aux critères. L'onglet Filtres contient des définitions de filtre de règle de découverte permettant de filtrer les valeurs de découverte :

Paramètre Description
Type of calcul Les options suivantes de calcul des filtres sont disponibles :
Et - tous les filtres doivent être réussis ;
Ou - suffisant si un filtre est réussi ;
Et/Ou - utilise And avec des noms de macro différents et Or avec le même nom de macro ;
Expression personnalisée - offre la possibilité de définir un calcul personnalisé des filtres. La formule doit inclure tous les filtres de la liste. Limité à 255 symboles.
Filtres Les opérateurs de condition de filtre suivants sont disponibles : correspond, ne correspond pas, existe, n'existe pas.
Les opérateurs correspond et ne correspond pas attendent une expression régulière compatible Perl (PCRE). Par exemple, si vous n'êtes intéressé que par les systèmes de fichiers C:, D: et E:, vous pouvez mettre {#FSNAME} dans "Macro" et "^C|^D|^E" regular expression dans les champs de texte "Expression régulière". Le filtrage est également possible par type de système de fichiers à l'aide de la macro {#FSTYPE} (par exemple, "^ext|^reiserfs") et par type de lecteur (uniquement pris en charge par l'agent Windows) à l'aide de la macro {#FSDRIVETYPE} (par exemple, " fixed").
Vous pouvez saisir une expression régulière ou faire référence à 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"; doneLa macro {#FSDRIVETYPE} sous Windows est prise en charge depuis Zabbix 3.0.0.

Les opérateurs existe et n'existe pas permettent de filtrer les entités en fonction de la présence ou de l'absence de la macro LLD spécifiée dans la réponse (supporté depuis la version 5.4.0).
La définition de plusieurs filtres est prise en charge depuis Zabbix 2.4.0.
Notez que si une macro du filtre est manquante dans la réponse, l'entité trouvée sera ignorée, sauf si une condition "n'existe pas" est spécifiée pour cette macro.

Une erreur ou une faute de frappe dans l'expression régulière utilisée dans la règle LLD (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 configuration, de valeurs historiques et d'événements pour de nombreux hôtes.

La base de données Zabbix dans MySQL doit être créée en respectant la casse si les noms de système de fichiers qui ne diffèrent que par la casse doivent être découverts correctement.

Trigger prototypes

We create trigger prototypes in a similar way as item prototypes:

Attributes that are specific for trigger prototypes:

Parameter Description
Create enabled If checked the trigger will be added in an enabled state.
If unchecked, the trigger will be added to a discovered entity, but in a disabled state.

When real triggers are created from the prototypes, there may be a need to be flexible as to what constant ('20' in our example) is used for comparison in the expression. See how user macros with context can be useful to accomplish such flexibility.

You can define dependencies between trigger prototypes as well (supported since Zabbix 3.0). To do that, go to the Dependencies tab. A trigger prototype may depend on another trigger prototype from the same low-level discovery (LLD) rule or on a regular trigger. A trigger prototype may not depend on a trigger prototype from a different LLD rule or on a trigger created from trigger prototype. Host trigger prototype cannot depend on a trigger from a template.

Graph prototypes

We can create graph prototypes, too:

Finally, we have created a discovery rule that looks like shown below. It has five item prototypes, two trigger prototypes, and one graph prototype.

Note: For configuring host prototypes, see the section about host prototype configuration in virtual machine monitoring.

Discovered entities

The screenshots below illustrate how discovered items, triggers, and graphs look like in the host's configuration. Discovered entities are prefixed with an orange link to a discovery rule they come from.

Note that discovered entities will not be created in case there are already existing entities with the same uniqueness criteria, for example, an item with the same key or graph with the same name.

Items (similarly, triggers and graphs) created by a low-level discovery rule will be deleted automatically if a discovered entity (file system, interface, etc) stops being discovered (or does not pass the filter anymore). In this case the items, triggers and graphs will be deleted after the days defined in the Keep lost resources period field pass.

When discovered entities become 'Not discovered anymore', a lifetime indicator is displayed in the item list. Move your mouse pointer over it and a message will be displayed indicating how many days are left until the item is deleted.

If entities were marked for deletion, but were not deleted at the expected time (disabled discovery rule or item host), they will be deleted the next time the discovery rule is processed.

Entities containing other entities, which are marked for deletion, will not update if changed on the discovery rule level. For example, LLD-based triggers will not update if they contain items that are marked for deletion.

Other types of discovery

More detail and how-tos on other types of out-of-the-box discovery is available in the following sections:

For more detail on the JSON format for discovery items and an example of how to implement your own file system discoverer as a Perl script, see creating custom LLD rules.

Data limits for return values

There is no limit for low-level discovery rule JSON data if it is received directly by Zabbix server, because return values are processed without being stored in a database. There's also no limit for custom low-level discovery rules, however, if it is intended to acquire custom LLD data using a user parameter, then user parameter return value limit applies (512 KB).

If data has to go through Zabbix proxy it has to store this data in database so database limits apply, for example, 2048 bytes on a Zabbix proxy run with IBM DB2 database.

Multiple LLD rules for same item

Since Zabbix agent version 3.2 it is possible to define several low-level discovery rules with the same discovery item.

To do that you need to define the Alias agent parameter, allowing to use altered discovery item keys in different discovery rules, for example vfs.fs.discovery[foo], vfs.fs.discovery[bar], etc.

Creating custom LLD rules

It is also possible to create a completely custom LLD rule, discovering any type of entities - for example, databases on a database server.

To do so, a custom item should be created that returns JSON, specifying found objects and optionally - some properties of them. The amount of macros per entity is not limited - while the built-in discovery rules return either one or two macros (for example, two for filesystem discovery), it is possible to return more.

The required JSON format is best illustrated with an example. Suppose we are running an old Zabbix 1.8 agent (one that does not support "vfs.fs.discovery"), but we still need to discover file systems. Here is a simple Perl script for Linux that discovers mounted file systems and outputs JSON, which includes both file system name and type. One way to use it would be as a UserParameter with key "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";

Allowed symbols for LLD macro names are 0-9 , A-Z , _ , .

Lowercase letters are not supported in the names.

An example of its output (reformatted for clarity) is shown below. JSON for custom discovery checks has to follow the same 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"  }
         
         ]
       }

Then, in the discovery rule's "Filter" field, we could specify "{#FSTYPE}" as a macro and "rootfs|ext3" as a regular expression.

You don't have to use macro names FSNAME/FSTYPE with custom LLD rules, you are free to use whatever names you like.

Note that, if using a user parameter, the return value is limited to 512 KB. For more details, see data limits for LLD return values.

Using LLD macros in user macro contexts

User macros with context can be used to accomplish more flexible thresholds in trigger expressions. Different thresholds may be defined on user macro level and then used in trigger constants depending on the discovered context. Discovered context appears when the low-level discovery macros used in the macros are resolved to real values.

To illustrate we can use data from the example above and assume that the following file systems will be discovered: /, /home, /tmp, /usr, /var.

We may define a free-disk-space trigger prototype for a host, where the threshold is expressed by a user macro with context:

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

Then add user macros:

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

Now, once the file systems are discovered, events will be generated if /, /usr and /var filesystems have less than 10% of free disk space, the /home filesystem - less than 20% of free disk space or the /tmp filesystem - less than 50% of free disk space.