12 Откривање помоћу ODBC SQL упита

Преглед

Ова врста ниског нивоа откривања се ради помоћу SQL упита, чији се резултати аутоматски трансформишу у JSON објекат погодан за откривање ниског нивоа.

Кључ ставке

SQL упити се изводе помоћу типа ставке "Монитор базе података". Стога, већина инструкција на ODBC надгледање страница се примењује у како бисте добили исправно правило откривања "Монитор базе података".

Два кључа ставки се могу користити у правилима откривања "Монитор базе података":

  • db.odbc.discovery[<unique short description>,<dsn>,<connection string>] - ова ставка трансформише резултат SQL упита у JSON низ, претварајући имена колона из резултата упита у макро за откривање ниског нивоа имена упарена са откривеним вредностима поља. Ови макрои могу бити користи се у креирању прототипа предмета, окидача итд. Такође погледајте: Using db.odbc.discovery.

  • db.odbc.get[<unique short description>,<dsn>,<connection string>] - ова ставка трансформише резултат SQL упита у JSON низ, задржавајући оригинална имена колона из резултата упита као име поља у JSON-у упарен са откривеним вредностима. У поређењу са db.odbc.discovery[], ова ставка не ствара откриће ниског нивоа макроа у враћеном JSON-у, стога нема потребе да проверавате да ли имена колона могу бити важећа имена макроа. Откриће ниског нивоа макрои се могу дефинисати као додатни корак по потреби, користећи custom LLD macro функционалност са JSONPath који указује на откривене вредности у вратио JSON. Такође погледајте: Using db.odbc.get.

Коришћење db.odbc.discovery

Као практичан пример за илустрацију како се SQL упит трансформише у JSON, размотримо откривање Zabbix проксија на ниском нивоу од стране извођење ODBC упита на Zabbix бази података. Ово је корисно за аутоматско креирање "zabbix[proxy,<name>,lastaccess]" интерне ставке за надгледање који су пуномоћници живи.

Почнимо са конфигурацијом правила откривања:

lld_rule_odbc.png

Сва обавезна поља за унос су означена црвеном звездицом.

Овде се за избор користи следећи директни упит за Zabbix базу података сви Zabbix проксији, заједно са бројем домаћина који су праћење. Број домаћина се може користити, на пример, за филтрирање празни проксији:

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)

Интерним радом ставке "db.odbc.discovery[,{$DSN}]", резултат овог упита се аутоматски трансформише у следећи JSON:

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

Може се видети да имена колона постају имена макроа и изабраних редова постају вредности ових макроа.

Ако није очигледно како би се трансформисало име колоне у име макроа, предлаже се да се користе псеудоними колона попут "COUNT(h2.host) AS count" у примеру изнад.

У случају да се назив колоне не може конвертовати у важеће име макроа, правило откривања постаје неподржано, са детаљима поруке о грешци број колоне која крши. Ако се жели додатна помоћ, добијена имена колона су наведена под DebugLevel=4 у датотеци евиденције 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.

Сада када разумемо како се SQL упит трансформише у JSON објекат, можемо користити {#HOST} макро у прототиповима ставки:

item_prototype_odbc.png

Када се открије изврши, биће креирана ставка за сваки прокси:

discovered_items_odbc1.png

Коришћењем db.odbc.get

Коришћењем db.odbc.get[,{$DSN}] и следећег SQL примера:

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)

овај JSON ће бити враћен:

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

Као што видите, тамо нема макроа за откривање ниског нивоа. међутим, прилагођени макрои за откривање ниског нивоа могу се креирати у LLD макрои картица правило откривања користећи JSONPath, на пример:

{#HOST} → $.host

Сада овај {#HOST} макро може да се користи у прототиповима ставки:

item_prototype_odbc.png