11 Ontdekking met behulp van ODBC SQL query's

Overzicht

Dit type low-level ontdekking wordt uitgevoerd met behulp van SQL-query's, waarvan de resultaten automatisch worden omgezet in een JSON-object dat geschikt is voor low-level ontdekking.

Item-sleutel

SQL-query's worden uitgevoerd met behulp van een itemtype "Database monitor". Daarom zijn de meeste instructies op de ODBC-monitoring pagina van toepassing om een werkende "Database monitor" ontdekkingsregel te krijgen.

Er kunnen twee itemsleutels worden gebruikt in "Database monitor" ontdekkingsregels:

  • db.odbc.discovery[<unieke korte beschrijving>,<dsn>,<connectie-reeks>] - dit item transformeert het resultaat van de SQL-query in een JSON-array, waarbij de kolomnamen uit het queryresultaat worden omgezet in low-level ontdekkingsmacro's die worden gekoppeld aan de ontdekte veldwaarden. Deze macro's kunnen worden gebruikt bij het maken van item-, trigger-, enzovoort-prototypen. Zie ook: Gebruik van db.odbc.discovery.
  • db.odbc.get[<unieke korte beschrijving>,<dsn>,<connectie-reeks>] - dit item transformeert het resultaat van de SQL-query in een JSON-array, waarbij de oorspronkelijke kolomnamen uit het queryresultaat worden gebruikt als veldnaam in JSON, gekoppeld aan de ontdekte waarden. In vergelijking met db.odbc.discovery[] creëert dit item geen low-level ontdekkingsmacro's in de geretourneerde JSON. Daarom is het niet nodig om te controleren of de kolomnamen geldige macronamen kunnen zijn. De low-level ontdekkingsmacro's kunnen indien nodig worden gedefinieerd als een aanvullende stap met behulp van de functionaliteit voor aangepaste LLD-macro's met JSONPath die wijst naar de ontdekte waarden in de geretourneerde JSON. Zie ook: Gebruik van db.odbc.get.

Gebruik van db.odbc.discovery

Als praktisch voorbeeld om te illustreren hoe de SQL-query wordt omgezet in JSON, laten we eens kijken naar de low-level ontdekking van Zabbix proxies door een ODBC-query uit te voeren op de Zabbix-database. Dit is handig voor het automatisch aanmaken van "zabbix[proxy,<naam>,lastaccess]" interne items om te controleren welke proxies actief zijn.

Laten we beginnen met de configuratie van de ontdekkingsregel:

lld_rule_odbc.png

Alle verplichte invoervelden zijn gemarkeerd met een rode asterisk.

Hier wordt de volgende directe query op de Zabbix-database gebruikt om alle Zabbix proxies te selecteren, samen met het aantal hosts dat ze in de gaten houden. Het aantal hosts kan bijvoorbeeld worden gebruikt om lege proxies te filteren:

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)

Door de interne werking van het "db.odbc.discovery[,{$DSN}]" item wordt het resultaat van deze query automatisch omgezet in de volgende JSON:

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

Hierbij worden kolomnamen omgezet in macronamen en worden geselecteerde rijen de waarden van deze macro's.

Als het niet duidelijk is hoe een kolomnaam wordt omgezet in een macronaam, wordt aangeraden om kolomaliasnamen te gebruiken zoals "COUNT(h2.host) AS count" in het bovenstaande voorbeeld.

In het geval dat een kolomnaam niet kan worden omgezet in een geldige macronaam, wordt de ontdekkingsregel niet ondersteund en wordt het foutbericht weergegeven waarin het problematische kolomnummer wordt vermeld. Als er aanvullende hulp nodig is, worden de verkregen kolomnamen weergegeven onder DebugLevel=4 in het Zabbix-serverlogbestand:

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

Nu we begrijpen hoe een SQL-query wordt omgezet in een JSON-object, kunnen we de {#HOST} macro gebruiken in item-prototypen:

item_prototype_odbc.png

Zodra de ontdekking is uitgevoerd, wordt er een item aangemaakt voor elke proxy:

discovered_items_odbc1.png

Gebruik van db.odbc.get

Met behulp van db.odbc.get[,{$DSN}] en het volgende SQL-voorbeeld:

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)

zal deze JSON worden geretourneerd:

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

Zoals je kunt zien, zijn er geen low-level discovery macros aanwezig. Niettemin kunnen aangepaste low-level discovery macros worden aangemaakt in het tabblad LLD macros van een ontdekkingsregel met behulp van JSONPath, bijvoorbeeld:

{#HOST} → $.host

Nu kan deze {#HOST} macro worden gebruikt in itemprototypen:

item_prototype_odbc.png