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

Преглед

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

Кључ ставке

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

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

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

• db.odbc.get[<unique shortdescription>,<dsn>,<connection string>] - ова ставка трансформише резултат SQL упита у JSON низ, чувајући оригинална имена колона из резултата упита као имена поља у JSON-у упарена са откривеним вредностима. У поређењу са db.odbc.discovery[], ова ставка не креира макрое за откривање ниског нивоа у враћеном JSON-у, стога нема потребе да се проверава да ли имена колона могу бити валидна имена макроа. Макрои за откривање ниског нивоа могу се дефинисати као додатни корак по потреби, коришћењем функционалности прилагођени LLD макро са JSONPath који указује на откривене вредности у враћеном JSON-у. Видите такође: Коришћење db.odbc.get.

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

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

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

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

Овде се следећи директан упит на 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 реда у скупу (0,01 сек)

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

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

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

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

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

Коришћење 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 реда у скупу (0,01 сек)

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

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

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

{#HOST} → $.host

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