12 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 exécutées à l’aide d’un type d’élément « Database monitor ». Par conséquent, la plupart des instructions de la page ODBC monitoring s’appliquent afin d’obtenir une règle de découverte « Database monitor » fonctionnelle.

Deux clés d’élément peuvent être utilisées dans les règles de découverte « Database monitor » :

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

• db.odbc.get[<description courte 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 colonnes d’origine du résultat de la requête comme noms de champs dans le JSON, associés 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 colonnes peuvent être des noms de macros valides. Les macros de découverte de bas niveau peuvent être définies comme étape supplémentaire selon les besoins, à l’aide de la fonctionnalité custom LLD macro avec JSONPath pointant vers les valeurs découvertes dans le JSON renvoyé. Voir aussi : Utilisation de db.odbc.get.

Utilisation de db.odbc.discovery

L'exemple suivant montre comment une requête SQL est transformée en JSON à l'aide de la découverte de bas niveau des proxies Zabbix, sur la base d'une requête ODBC sur la base de données Zabbix. Cela est utile pour la création automatique d'éléments internes "zabbix[proxy,<name>,lastaccess]" afin de surveiller quels proxies sont actifs.

Commencez 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 proxies Zabbix, ainsi que le nombre d'hôtes qu'ils surveillent. Le nombre d'hôtes peut être utilisé, par exemple, pour exclure les proxies vides :

mysql> SELECT h1.host, COUNT(h2.host) AS count FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxyid 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)

Par le 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 colonnes deviennent des noms de macros 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 les prototypes d'éléments :

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.proxyid 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 renvoyé :

[
    {
        "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 personnalisées de découverte 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

Cette macro {#HOST} peut maintenant être utilisée dans les prototypes d’élément :