12 Discovery mit ODBC-SQL-Abfragen

Übersicht

Diese Art der Low-Level-Discovery wird mithilfe von SQL-Abfragen durchgeführt, deren Ergebnisse automatisch in ein JSON-Objekt umgewandelt werden, das für die Low-Level-Discovery geeignet ist.

Datenpunktschlüssel

SQL-Abfragen werden mit einem Datenpunkt-Typ „Database monitor“ ausgeführt. Daher gelten die meisten Anweisungen auf der Seite ODBC monitoring, um eine funktionierende Discovery-Regel vom Typ „Database monitor“ zu erhalten.

In Discovery-Regeln vom Typ „Database monitor“ können zwei Datenpunktschlüssel verwendet werden:

  • db.odbc.discovery[<unique short description>,<dsn>,<connection string>] - dieser Datenpunkt wandelt das Ergebnis der SQL-Abfrage in ein JSON-Array um, wobei die Spaltennamen aus dem Abfrageergebnis in Low-Level-Discovery-Makronamen umgewandelt und mit den erkannten Feldwerten verknüpft werden. Diese Makros können beim Erstellen von Prototypen für Datenpunkte, Auslöser usw. verwendet werden. Siehe auch: Using db.odbc.discovery.

  • db.odbc.get[<unique short description>,<dsn>,<connection string>] - dieser Datenpunkt wandelt das Ergebnis der SQL-Abfrage in ein JSON-Array um, wobei die ursprünglichen Spaltennamen aus dem Abfrageergebnis als Feldnamen im JSON beibehalten und mit den erkannten Werten verknüpft werden. Im Vergleich zu db.odbc.discovery[] erstellt dieser Datenpunkt keine Low-Level-Discovery-Makros im zurückgegebenen JSON, daher muss nicht geprüft werden, ob die Spaltennamen gültige Makronamen sein können. Die Low-Level-Discovery-Makros können bei Bedarf in einem zusätzlichen Schritt definiert werden, indem die Funktion custom LLD macro mit JSONPath verwendet wird, das auf die erkannten Werte im zurückgegebenen JSON verweist. Siehe auch: Using db.odbc.get.

Verwendung von db.odbc.discovery

Das folgende Beispiel zeigt, wie eine SQL-Abfrage mithilfe der Low-Level-Discovery von Zabbix-Proxys auf Basis einer ODBC-Abfrage an die Zabbix-Datenbank in JSON umgewandelt wird. Dies ist nützlich für die automatische Erstellung von „zabbix[proxy,<name>,lastaccess]“-internen Datenpunkten, um zu überwachen, welche Proxys aktiv sind.

Beginnen Sie mit der Konfiguration der Discovery-Regel:

lld\_rule\_odbc.png

Alle erforderlichen Eingabefelder sind mit einem roten Sternchen markiert.

Hier wird die folgende direkte Abfrage an die Zabbix-Datenbank verwendet, um alle Zabbix-Proxys zusammen mit der Anzahl der Hosts auszuwählen, die sie überwachen. Die Anzahl der Hosts kann beispielsweise verwendet werden, um leere Proxys herauszufiltern:

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)

Durch die interne Funktionsweise des Datenpunkts „db.odbc.discovery[,{$DSN}]“ wird das Ergebnis dieser Abfrage automatisch in das folgende JSON umgewandelt:

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

Es ist zu erkennen, dass Spaltennamen zu Makronamen werden und ausgewählte Zeilen zu den Werten dieser Makros werden.

Wenn nicht offensichtlich ist, wie ein Spaltenname in einen Makronamen umgewandelt wird, wird empfohlen, Spaltenaliase wie „COUNT(h2.host) AS count“ im obigen Beispiel zu verwenden.

Falls ein Spaltenname nicht in einen gültigen Makronamen umgewandelt werden kann, wird die Discovery-Regel nicht unterstützt; die Fehlermeldung enthält dann die Nummer der betreffenden Spalte. Falls zusätzliche Hilfe gewünscht ist, werden die ermittelten Spaltennamen bei DebugLevel=4 in der Zabbix-Server-Logdatei ausgegeben:

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

Nachdem wir nun verstanden haben, wie eine SQL-Abfrage in ein JSON-Objekt umgewandelt wird, können wir das Makro {#HOST} in Datenpunkt-Prototypen verwenden:

item\_prototype\_odbc.png

Sobald die Discovery durchgeführt wurde, wird für jeden Proxy ein Datenpunkt erstellt:

discovered\_items\_odbc1.png

Verwendung von db.odbc.get

Bei Verwendung von db.odbc.get[,{$DSN}] und des folgenden SQL-Beispiels:

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)

wird dieses JSON zurückgegeben:

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

Wie Sie sehen können, gibt es dort keine Low-Level-Discovery-Makros. Benutzerdefinierte Low-Level-Discovery-Makros können jedoch im Reiter LLD macros einer Discovery-Regel mithilfe von JSONPath erstellt werden, zum Beispiel:

{#HOST} → $.host

Dieses Makro {#HOST} kann nun in Datenpunkt-Prototypen verwendet werden:

item\_prototype\_odbc.png