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 pozycja
Zapytania SQL są wykonywane przy użyciu typu pozycja „Database monitor”. Dlatego większość instrukcji na stronie monitorowania ODBC ma zastosowanie, aby uzyskać działającą regułę odkrywania „Database monitor”.
W regułach odkrywania „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 niskopoziomowego odkrywania 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 nazwę pola w JSON powiązaną z wykrytymi wartościami. W porównaniu z
db.odbc.discovery[], ta pozycja nie tworzy makr niskopoziomowego odkrywania w zwracanym JSON, dlatego nie ma potrzeby sprawdzania, czy nazwy kolumn mogą być prawidłowymi nazwami makr. Makra niskopoziomowego odkrywania można zdefiniować jako dodatkowy krok, jeśli jest to wymagane, korzystając z funkcji niestandardowego makra LLD z JSONPath wskazującym wykryte wartości w zwracanym JSON. Zobacz także: Using db.odbc.get.
Korzystanie z db.odbc.discovery
Jako praktyczny przykład ilustrujący, jak zapytanie SQL jest przekształcane do JSON, rozważmy wykrywanie niskiego poziomu proxy Zabbix poprzez wykonanie zapytania ODBC na bazie danych Zabbix. Jest to przydatne do automatycznego tworzenia "zabbix[proxy,<name>,lastaccess]" pozycji wewnętrznych w celu monitorowania, które proxy są aktywne.
Zacznijmy od konfiguracji reguły wykrywania:

Wszystkie obowiązkowe pola wejściowe są oznaczone czerwoną gwiazdką.
Tutaj używane jest następujące bezpośrednie zapytanie do bazy danych Zabbix, aby wybrać wszystkie proxy Zabbix 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życie 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 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:

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

Używanie db.odbc.get
Używając 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 niskopoziomowego. Jednak niestandardowe makra wykrywania niskopoziomowego można utworzyć na karcie Makra LLD reguły wykrywania przy użyciu JSONPath, na przykład:
{#HOST} → $.host
Teraz to makro {#HOST} może być używane w prototypach pozycji:
