Zabbix Documentation 3.4

3.04.04.2 (current)In development:4.4 (devel)Unsupported:1.82.02.22.43.23.4

User Tools

Site Tools


Sidebar

ru:manual:discovery:low_level_discovery:sql_queries

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

Обзор

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

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

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

db.odbc.discovery[<описание>,<dsn>]

вместо “db.odbc.select[<описание>,<dsn>]”.

Обнаружение с использованием SQL запросов поддерживается начиная с Zabbix сервера/прокси 3.0.

В качестве практического примера, иллюстрирующего как 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[]”, результат этого запроса автоматически преобразуется в следующий JSON:

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

Как только обнаружение будет выполнено, элемент данных будет создан по каждому прокси: