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

Обзор

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

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

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

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

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

Использование db.odbc.discovery

В качестве практического примера, иллюстрирующего как SQL запрос трансформируется в JSON, рассмотрим низкоуровневое обнаружения Zabbix прокси, выполнив ODBC запрос в Zabbix базу данных. Он может быть полезен для автоматического создания внутренних элементов данных "zabbix[proxy,<имя>,lastaccess]", чтобы наблюдать какие прокси живы.

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

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

Здесь используется следующий прямой запрос в базу данных 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"
           }
       ]

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

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