nucleusv 16 июн 2014 в 07:11

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

10 мин

56K

Настройка Linux * Серверное администрирование * Системное администрирование *

Комментарии 7

Akint 29 июн 2015 в 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 29 июн 2015 в 12:37

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

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

Akint 29 июн 2015 в 13:46

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

nucleusv 30 июн 2015 в 06:58

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

Akint 30 июн 2015 в 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 30 июн 2015 в 08:03

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

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

Akint 30 июн 2015 в 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).

Зарегистрируйтесь на Хабре, чтобы оставить комментарий