11 Découverte à l'aide de requêtes SQL ODBC

Aperçu

Ce type de découverte de bas niveau est effectué à l'aide de requêtes SQL, dont les résultats sont automatiquement transformés en un objet JSON adapté à la découverte de bas niveau.

Clé d'élément

Les requêtes SQL sont effectuées à l'aide d'une élément de type "Surveillance base de données". Par conséquent, la plupart des instructions de la page Surveillance ODBC s'appliquent afin d'obtenir une règle de découverte "Surveillance base de données" fonctionnelle.

Deux clés d'éléments peuvent être utilisées dans les règles de découverte "Surveillance base de données" :

• db.odbc.discovery[<courte description unique>,<dsn>,<chaîne de connexion>] - cet élément transforme le résultat de la requête SQL en un tableau JSON, transformant les noms de colonne du résultat de la requête en noms de macro de découverte de bas niveau associés aux valeurs de champ découvertes. Ces macros peuvent être utilisées pour créer des prototypes d'éléments, de déclencheurs, etc. Voir aussi : Utilisation de odb.odbc.discovery.

• db.odbc.get[<courte description unique>,<dsn>,<chaîne de connexion>] - cet élément transforme le résultat de la requête SQL en un tableau JSON, en conservant les noms de colonne d'origine du résultat de la requête en tant que nom de champ dans JSON associé aux valeurs découvertes. Comparé à db.odbc.discovery[], cet élément ne crée pas de macros de découverte de bas niveau dans le JSON renvoyé, il n'est donc pas nécessaire de vérifier si les noms de colonne peuvent être des noms de macro valides. Les macros de découverte de bas niveau peuvent être définies comme une étape supplémentaire si nécessaire, à l'aide de la fonctionnalité macro LLD personnalisée avec JSONPath pointant vers les valeurs découvertes dans le JSON renvoyé. Voir aussi : Utilisation de db.odbc.get.

Utilisation de db.odbc.discovery

Comme exemple pratique pour illustrer comment la requête SQL est transformée en JSON, considérons la découverte de bas niveau des proxys Zabbix en effectuant une requête ODBC sur la base de données Zabbix. Ceci est utile pour la création automatique des éléments internes "zabbix[proxy,<nom>,lastaccess]" afin de surveiller quels proxys sont actifs.

Commençons par la configuration de la règle de découverte :

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

Ici, la requête directe suivante sur la base de données Zabbix est utilisée pour sélectionner tous les proxys Zabbix, ainsi que le nombre d’hôtes qu’ils surveillent. Le nombre d'hôtes peut être utilisé, par exemple, pour filtrer les proxys vides :

mysql> SELECT h1.host, COUNT(h2.host) AS count FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxy_hostid WHERE h1.status IN (5, 6) GROUP BY h1.host;
           +---------+-------+
           | host    | count |
           +---------+-------+
           | Japan 1 |     5 |
           | Japan 2 |    12 |
           | Latvia  |     3 |
           +---------+-------+
           3 rows in set (0.01 sec)

Grâce au fonctionnement interne de l'élément “db.odbc.discovery[,{$DSN}]”, le résultat de cette requête est automatiquement transformé en JSON suivant :

[
           {
               "{#HOST}": "Japan 1",
               "{#COUNT}": "5"
           },
           {
               "{#HOST}": "Japan 2",
               "{#COUNT}": "12"
           },
           {
               "{#HOST}": "Latvia",
               "{#COUNT}": "3"
           }
       ]

On peut voir que les noms de colonne deviennent des noms de macro et que les lignes sélectionnées deviennent les valeurs de ces macros.

    $ grep db.odbc.discovery /tmp/zabbix_server.log
            ...
            23876:20150114:153410.856 In db_odbc_discovery() query:'SELECT h1.host, COUNT(h2.host) FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxy_hostid WHERE h1.status IN (5, 6) GROUP BY h1.host;'
            23876:20150114:153410.860 db_odbc_discovery() column[1]:'host'
            23876:20150114:153410.860 db_odbc_discovery() column[2]:'COUNT(h2.host)'
            23876:20150114:153410.860 End of db_odbc_discovery():NOTSUPPORTED
            23876:20150114:153410.860 Item [Zabbix server:db.odbc.discovery[proxies,{$DSN}]] error: Cannot convert column #2 name to macro.

Maintenant que nous comprenons comment une requête SQL est transformée en objet JSON, nous pouvons utiliser la macro {#HOST} dans des prototypes d’élément :

Une fois la découverte effectuée, un élément sera créé pour chaque proxy :

Utilisation de db.odbc.get

En utilisant db.odbc.get[,{$DSN}] et l'exemple SQL suivant :

    mysql> SELECT h1.host, COUNT(h2.host) AS count FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxy_hostid WHERE h1.status IN (5, 6) GROUP BY h1.host;
           +---------+-------+
           | host    | count |
           +---------+-------+
           | Japan 1 |     5 |
           | Japan 2 |    12 |
           | Latvia  |     3 |
           +---------+-------+
           3 rows in set (0.01 sec)

ce JSON sera retourné :

[
           {
               "host": "Japan 1",
               "count": "5"
           },
           {
               "host": "Japan 2",
               "count": "12"
           },
           {
               "host": "Latvia",
               "count": "3"
           }
       ]

Comme vous pouvez le voir, il n'y a pas de macros de découverte de bas niveau. Cependant, des macros de découverte personnalisées de bas niveau peuvent être créées dans l'onglet Macros LLD d'une règle de découverte à l'aide de JSONPath, par exemple :

    {#HOST} → $.host

Désormais, cette macro {#HOST} peut être utilisée dans les prototypes d'éléments :