Odkrywanie za pomocą zapytań SQL ODBC

Przegląd

Ten typ wykrywania niskiego poziomu jest realizowany przy użyciu zapytań SQL, których wyniki są automatycznie przekształcane w obiekt JSON odpowiedni do wykrywania niskiego poziomu.

Klucz pozycja

Zapytania SQL są wykonywane przy użyciu typu pozycja „Database monitor”. Dlatego większość instrukcji na stronie ODBC monitoring ma zastosowanie, aby uzyskać działającą regułę wykrywania „Database monitor”.

W regułach wykrywania „Database monitor” można użyć dwóch kluczy pozycji:

  • db.odbc.discovery[<unique short description>,<dsn>,<connection string>] - ta pozycja przekształca wynik zapytania SQL w tablicę JSON, zamieniając nazwy kolumn z wyniku zapytania na nazwy makr wykrywania niskiego poziomu, powiązane z wykrytymi wartościami pól. Te makra można wykorzystać podczas tworzenia prototypów pozycji, wyzwalaczy itp. Zobacz także: Using db.odbc.discovery.

  • db.odbc.get[<unique short description>,<dsn>,<connection string>] - ta pozycja przekształca wynik zapytania SQL w tablicę JSON, zachowując oryginalne nazwy kolumn z wyniku zapytania jako nazwy pól w JSON, powiązane z wykrytymi wartościami. W porównaniu z db.odbc.discovery[], ta pozycja nie tworzy makr wykrywania niskiego poziomu w zwracanym JSON, dlatego nie ma potrzeby sprawdzania, czy nazwy kolumn mogą być prawidłowymi nazwami makr. Makra wykrywania niskiego poziomu można zdefiniować jako dodatkowy krok, jeśli jest to wymagane, korzystając z funkcji custom LLD macro z JSONPath wskazującym wykryte wartości w zwracanym JSON. Zobacz także: Using db.odbc.get.

Korzystanie z db.odbc.discovery

Poniższy przykład pokazuje, jak zapytanie SQL jest przekształcane do formatu JSON przy użyciu niskopoziomowego wykrywania proxy Zabbixa, na podstawie zapytania ODBC do bazy danych Zabbixa. Jest to przydatne do automatycznego tworzenia zabbix[proxy,<name>,lastaccess] pozycji wewnętrznych, aby monitorować, które proxy są aktywne.

Zacznij od konfiguracji reguły wykrywania:

lld\_rule\_odbc.png

Wszystkie wymagane pola wejściowe są oznaczone czerwoną gwiazdką.

W tym przykładzie użyto następującego bezpośredniego zapytania do bazy danych Zabbixa, aby wybrać wszystkie proxy Zabbixa wraz z liczbą hostów, które monitorują. Liczba hostów może być użyta na przykład do odfiltrowania pustych proxy:

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)

Dzięki wewnętrznemu działaniu pozycji db.odbc.discovery[,{$DSN}] wynik tego zapytania jest automatycznie przekształcany do następującego JSON:

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

Widać, że nazwy kolumn stają się nazwami makr, a wybrane wiersze stają się wartościami tych makr.

Jeśli nie jest oczywiste, w jaki sposób nazwa kolumny zostałaby przekształcona w nazwę makra, zaleca się używanie aliasów kolumn, takich jak COUNT(h2.host) AS count w powyższym przykładzie.

Jeśli nazwy kolumny nie można przekształcić w prawidłową nazwę makra, reguła wykrywania staje się nieobsługiwana, a komunikat o błędzie zawiera numer problematycznej kolumny. Jeśli potrzebna jest dodatkowa pomoc, uzyskane nazwy kolumn są dostępne przy DebugLevel=4 w pliku dziennika serwera Zabbixa:

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

Teraz, gdy rozumiemy, jak zapytanie SQL jest przekształcane w obiekt JSON, możemy użyć makra {#HOST} w prototypach pozycji:

item\_prototype\_odbc.png

Po wykonaniu wykrywania dla każdego proxy zostanie utworzona pozycja:

discovered\_items\_odbc1.png

Korzystanie z db.odbc.get

Korzystając z db.odbc.get[,{$DSN}] oraz następującego przykładu SQL:

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)

zostanie zwrócony następujący JSON:

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

Jak widać, nie ma tam makr wykrywania niskiego poziomu. Jednak niestandardowe makra wykrywania niskiego poziomu można utworzyć na karcie Makra LLD reguły wykrywania, używając JSONPath, na przykład:

{#HOST} → $.host

Teraz to makro {#HOST} może być używane w prototypach pozycji:

item\_prototype\_odbc.png