Comments 7
Как и обещал на Zabbix Meetup, выкладываю SQL-запрос для дискавери, например, табличных пространств:
Следует иметь в виду, что функция listagg появилась только в Oracle 11.2, поэтому с более ранними версиями такой фокус не пройдёт.
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, поэтому с более ранними версиями такой фокус не пройдёт.
Антон, спасибо!
Согласись, что родная функция в Zabbix 3.0 будет удобнее и не во всех базах такое можно будет провернуть, а ODBC это как раз попытка универсального доступа к разным базам?
Согласись, что родная функция в Zabbix 3.0 будет удобнее и не во всех базах такое можно будет провернуть, а ODBC это как раз попытка универсального доступа к разным базам?
Конечно, соглашусь. Я и позиционирую это решение как временное, пока не выйдет Zabbix 3.0. Учитывая, что контекстные макросы дадут возможность более гибко настраивать пороги триггеров, в третьей версии мониторинг через ODBC шагнёт далеко вперёд. Всего-то и останется желать, что persistent connection и bulk requests. =)
Тогда жмякай support.zabbix.com/browse/ZBXNEXT-2485 — vote :)
А bulk requests это как ты себе представляешь? просто если процесс не будет закрывать коннект, он просто последовательно их фигарить
А bulk requests это как ты себе представляешь? просто если процесс не будет закрывать коннект, он просто последовательно их фигарить
Пожмякал =)
Под bulk request я имею в виду одновременный сбор нескольких однотипных данных, чтобы:
1) получать консистентные «срезы»;
2) уменьшить количество запросов (чтобы не бегать по одной и той же таблице несколько раз, например).
Persistent connection избавит нас от проблемы большого количества соединений к базе, но не от перечисленного выше.
Сейчас я скриптом запрашиваю что-то типа
а потом zabbix_sender'ом отсылаю на trapper items, сгенерированные LLD. Хочется нативного механизма, причём не только для ODBC проверок.
Под 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 проверок.
Это вопрос поднимал Илья Аблеев, когда Алексей приезжал месяца полтора назад. Он просил его сделать пассивный zabbix multi Item.
То есть когда ты дергаешь например system.run[], а он тебе возвращает данные в формате которые ты формируешь для zabbix sender.
Но понимаешь какая тут проблема именно в архитектуре заббикса, что метрика должна быть создана, то есть тебе предварительно все равно траппер элементы создавать надо — этой какой костыль получается. И предположим как тут считать когда элемент стал не поддерживаемым когда например он вернул несколько метрик которые пришли и сервер их принял, а одну он не принял например
Короче тут есть на чем подумать архитектурно
То есть когда ты дергаешь например system.run[], а он тебе возвращает данные в формате которые ты формируешь для zabbix sender.
Но понимаешь какая тут проблема именно в архитектуре заббикса, что метрика должна быть создана, то есть тебе предварительно все равно траппер элементы создавать надо — этой какой костыль получается. И предположим как тут считать когда элемент стал не поддерживаемым когда например он вернул несколько метрик которые пришли и сервер их принял, а одну он не принял например
Короче тут есть на чем подумать архитектурно
Да, я над этим думал. Если сбор данных — это отдельный item, то его надо делать неподдерживаемым, если он не смог забрать данные. Возвращать он может количество значений, отправка которых зафейлилась, тогда на это можно сделать отдельный триггер.
Если же реализовано это будет как-то по-другому, надо уже думать отдельно. Например, в порядке общего бреда:
Имеем item prototype.
ключ:
запрос:
Новый чекбокс
Если же реализовано это будет как-то по-другому, надо уже думать отдельно. Например, в порядке общего бреда:
Имеем 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).Sign up to leave a comment.
Мониторинг базы данных Oracle через ODBC в Zabbix