12 Обнаружение с использованием SQL-запросов ODBC

Обзор

Этот тип низкоуровневого обнаружения осуществляется с использованием SQL-запросов, результаты которых автоматически преобразуются в объект JSON, пригодный для низкоуровневого обнаружения.

Ключ элемента данных

SQL-запросы выполняются при помощи элементов данных типа «Монитор баз данных». Так что большая часть указаний со страницы мониторинга ODBC применима к получению работающего правила обнаружения «Монитора баз данных».

В правилах обнаружения «Монитор баз данных» можно использовать два ключа элементов данных:

• db.odbc.discovery[<уникальное короткое описание>,<dsn>,<строка подключения>] - этот элемент данных преобразует результат SQL-запроса в массив JSON, превращает имена столбцов из результата запроса в имена макросов низкоуровневого обнаружения в парах с обнаруженными значениями полей. Эти макросы можно использовать при создании прототипов элементов данных, триггеров и т.п. Смотрите также: Использование db.odbc.discovery.

• db.odbc.get[<уникальное короткое описание>,<dsn>,<строка подключения>] - этот элемент данных преобразует результат SQL-запроса в массив JSON, сохраняя оригинальные имена столбцов из результата запроса в качестве имён полей в JSON в сочетании с обнаруженными значениями. В сравнении с db.odbc.discovery[], этот элемент данных не создает макросы низкоуровневого обнаружения в возвращаемом JSON, поэтому не требуется проверять, могут ли имена столбцов быть корректными именами макросов. Макросы низкоуровневого обнаружения можно определить дополнительным шагом по мере необходимости, используя функционал настраиваемых макросов с JSONPath, указывающим на обнаруженные значения в полученном JSON. Смотрите также: Использование db.odbc.get.

Using db.odbc.discovery

As a practical example to illustrate how the SQL query is transformed into JSON, let us consider low-level discovery of Zabbix proxies by performing an ODBC query on Zabbix database. This is useful for automatic creation of "zabbix[proxy,<name>,lastaccess]" internal items to monitor which proxies are alive.

Let us start with discovery rule configuration:

All mandatory input fields are marked with a red asterisk.

Here, the following direct query on Zabbix database is used to select all Zabbix proxies, together with the number of hosts they are monitoring. The number of hosts can be used, for instance, to filter out empty proxies:

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)

By the internal workings of "db.odbc.discovery[,{$DSN}]" item, the result of this query gets automatically transformed into the following JSON:

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

It can be seen that column names become macro names and selected rows become the values of these macros.

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

Now that we understand how a SQL query is transformed into a JSON object, we can use {#HOST} macro in item prototypes:

Once discovery is performed, an item will be created for each proxy:

Using db.odbc.get

Using db.odbc.get[,{$DSN}] and the following SQL example:

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)

this JSON will be returned:

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

As you can see, there are no low-level discovery macros there. However, custom low-level discovery macros can be created in the LLD macros tab of a discovery rule using JSONPath, for example:

{#HOST} → $.host

Now this {#HOST} macro may be used in item prototypes: