nucleusv Jun 16 2014 at 07:11

Мониторинг базы данных Oracle через ODBC в Zabbix

10 min

56K

Configuring Linux * Server Administration * System administration *

Comments 7

Akint Jun 29 2015 at 04:10

Как и обещал на Zabbix Meetup, выкладываю SQL-запрос для дискавери, например, табличных пространств:

WITH tablespaces AS (
  SELECT DISTINCT '{"{#TBSNAME}":"' || tablespace_name || '"}' AS json FROM dba_data_files
)
SELECT '{"data":[' || (
  SELECT LISTAGG(json, ',') WITHIN GROUP (ORDER BY 1) FROM tablespaces
) || ']}' from  dual;

Следует иметь в виду, что функция listagg появилась только в Oracle 11.2, поэтому с более ранними версиями такой фокус не пройдёт.

nucleusv Jun 29 2015 at 12:37

Антон, спасибо!

Согласись, что родная функция в Zabbix 3.0 будет удобнее и не во всех базах такое можно будет провернуть, а ODBC это как раз попытка универсального доступа к разным базам?

Akint Jun 29 2015 at 13:46

Конечно, соглашусь. Я и позиционирую это решение как временное, пока не выйдет Zabbix 3.0. Учитывая, что контекстные макросы дадут возможность более гибко настраивать пороги триггеров, в третьей версии мониторинг через ODBC шагнёт далеко вперёд. Всего-то и останется желать, что persistent connection и bulk requests. =)

nucleusv Jun 30 2015 at 06:58

Тогда жмякай support.zabbix.com/browse/ZBXNEXT-2485 — vote :)
А bulk requests это как ты себе представляешь? просто если процесс не будет закрывать коннект, он просто последовательно их фигарить

Akint Jun 30 2015 at 07:45

Пожмякал =)
Под bulk request я имею в виду одновременный сбор нескольких однотипных данных, чтобы:
1) получать консистентные «срезы»;
2) уменьшить количество запросов (чтобы не бегать по одной и той же таблице несколько раз, например).
Persistent connection избавит нас от проблемы большого количества соединений к базе, но не от перечисленного выше.

Сейчас я скриптом запрашиваю что-то типа

SELECT tablespace_name, SUM(bytes) FROM dba_data_files GROUP BY tablespace_name;

а потом zabbix_sender'ом отсылаю на trapper items, сгенерированные LLD. Хочется нативного механизма, причём не только для ODBC проверок.

nucleusv Jun 30 2015 at 08:03

Это вопрос поднимал Илья Аблеев, когда Алексей приезжал месяца полтора назад. Он просил его сделать пассивный zabbix multi Item.
То есть когда ты дергаешь например system.run[], а он тебе возвращает данные в формате которые ты формируешь для zabbix sender.
Но понимаешь какая тут проблема именно в архитектуре заббикса, что метрика должна быть создана, то есть тебе предварительно все равно траппер элементы создавать надо — этой какой костыль получается. И предположим как тут считать когда элемент стал не поддерживаемым когда например он вернул несколько метрик которые пришли и сервер их принял, а одну он не принял например

Короче тут есть на чем подумать архитектурно

Akint Jun 30 2015 at 08:41

Да, я над этим думал. Если сбор данных — это отдельный item, то его надо делать неподдерживаемым, если он не смог забрать данные. Возвращать он может количество значений, отправка которых зафейлилась, тогда на это можно сделать отдельный триггер.
Если же реализовано это будет как-то по-другому, надо уже думать отдельно. Например, в порядке общего бреда:
Имеем item prototype.
ключ:


db.odbc.select[tbs_bytes,{#TBS_NAME},{HOST.NAME}]

запрос:

SELECT tablespace_name as TBS_NAME, SUM(bytes) FROM dba_data_files GROUP BY tablespace_name;

Новый чекбокс


Bulk request

. Если он установлен, то для выполняется одна проверка для всех айтемов, сгенерированных из этого прототипа. Полученные значения раскладываются по айтемам, исходя из значения поля, заголовок которого совпадет с LLD макросом в ключе (в данном случае — TBS_NAME).