12 Wykrywanie za pomocą zapytań SQL poprzez 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 pozycji

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

W regułach wykrywania „Database monitor” można używać 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 sparowane z wykrytymi wartościami pól. Makra te mogą być używane 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 sparowane 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 w razie potrzeby, używając funkcji custom LLD macro z JSONPath wskazującym wykryte wartości w zwracanym JSON. Zobacz także: Using db.odbc.get.

Użycie db.odbc.discovery

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

Zacznij od konfiguracji reguły wykrywania:

lld\_rule\_odbc.png

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

Tutaj używane jest następujące bezpośrednie zapytanie do bazy danych Zabbix w celu wybrania wszystkich proxy Zabbix wraz z liczbą hostów, które monitorują. Liczba hostów może zostać 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 formatu JSON:

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

Jak widać, 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 zostanie przekształcona w nazwę makra, zaleca się użycie aliasów kolumn, takich jak "COUNT(h2.host) AS count" w powyższym przykładzie.

Jeśli nazwa kolumny nie może zostać przekonwertowana na prawidłową nazwę makra, reguła wykrywania stanie się nieobsługiwana, a komunikat błędu będzie zawierał numer problematycznej kolumny. Jeśli potrzebna jest dodatkowa pomoc, uzyskane nazwy kolumn są podawane przy DebugLevel=4 w pliku dziennika serwera Zabbix:

$ 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 zostanie utworzona pozycja dla każdego proxy:

discovered\_items\_odbc1.png

Używanie db.odbc.get

Używając db.odbc.get[,{$DSN}] oraz poniższego 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 niskopoziomowego wykrywania. Jednak własne makra niskopoziomowego wykrywania można utworzyć na karcie LLD macros reguły wykrywania przy użyciu JSONPath, na przykład:

{#HOST} → $.host

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

item\_prototype\_odbc.png