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

Обзор

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

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

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

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

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

• db.odbc.get[<unique short description>,<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]" внутренних элементов данных для мониторинга того, какие прокси активны.

Начните с настройки правила обнаружения:

Все обязательные поля ввода отмечены красной звездочкой.

Здесь используется следующий прямой запрос к базе данных Zabbix для выбора всех прокси Zabbix вместе с количеством узлов сети, которые они мониторят. Количество узлов сети можно использовать, например, чтобы отфильтровать пустые прокси:

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)

За счет внутренней работы элемента данных "db.odbc.discovery[,{$DSN}]" результат этого запроса автоматически преобразуется в следующий JSON:

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

Как видно, имена столбцов становятся именами макросов, а выбранные строки становятся значениями этих макросов.

$ 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} в прототипах элементов данных:

После выполнения обнаружения для каждого прокси будет создан элемент данных:

Использование 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.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)

будет возвращён следующий JSON:

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

Как видите, здесь нет макросов низкоуровневого обнаружения. Однако пользовательские макросы низкоуровневого обнаружения можно создать на вкладке LLD macros правила обнаружения с использованием JSONPath, например:

{#HOST} → $.host

Теперь этот макрос {#HOST} можно использовать в прототипах элементов данных: