Да, я над этим думал. Если сбор данных — это отдельный 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).
Пожмякал =)
Под 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 3.0. Учитывая, что контекстные макросы дадут возможность более гибко настраивать пороги триггеров, в третьей версии мониторинг через ODBC шагнёт далеко вперёд. Всего-то и останется желать, что persistent connection и bulk requests. =)
Как и обещал на 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, поэтому с более ранними версиями такой фокус не пройдёт.
«Срезать неактуальное» через время хранения в элементе данных возможно, только если включен housekeeper. На больших объёмах данных его рекомендуют выключать, поэтому эти логи у вас будут занимать место до тех пор, пока жива соответствующая партиция таблицы history_log. Как вариант, конечно, можно уменьшить время хранения партиций для history_log, оставив остальные таблицы как есть.
Возможно, зря останавливает. Мне импонирует то, что unixODBC позволяет настроить подключение один раз, а новые проверки добавлять через Web-интерфейс, не обновляя конфиги агентов.
Скажите, пожалуйста, не рассматривали возможность отправки запросов самим Zabbix'ом через unixODBC? Если рассматривали, то почему предпочли локального агента?
В подобной ситуации mintty мне не понравился тем, что забирает на себя фокус при выделении мышью. Потом приходится совершать лишние телодвижения, чтобы вернуть фокус в ConEmu. А без этого невозможно переключаться между вкладками с клавиатуры.
Для себя выбрал ConEmu + cygwin bash + вручную отредактированный terminfo (без него в Solaris, например, работать было невозможно).
Хорошее дело делаете, полезное! =)
У меня реализован подобный функционал для себя и друзей. Для своего домашнего сервера тоже делал на php + mysql. Когда же друзья начали просить и им «настроить автоматическое скачивание новых серий», пришёл к следующим выводам:
1) Для популярных систем типа Ubuntu надо оборачивать всё в пакет, где в зависимостях указывать тот же php5-curl и mysql-server, и выкладывать в свой репозиторий. Пакет сделать недолго, а устанавливать и обновлять пользователям будет гораздо удобнее.
2) (спорно) Для конечного пользователя, возможно, будет проще связка perl + sqlite, т.к. в той же Ubuntu perl уже стоит по умолчанию, недостающие модули спокойно устанавливаются через зависимости пакета, а sqlite избавляет от необходимости крутить сервер mysql (есть у меня некое предубеждение против запуска серверных демонов на рабочей машине). Но при таком раскладе встанет вопрос с GUI (в перловом варианте у меня всё реализовано через консоль).
А чем, позвольте поинтересоваться, он заслужил такой отзыв? Сам являюсь обладателем такого же, но аппаратом вполне доволен. Хотя да, клавиатура — его главное преимущество.
У меня похожая история. Возникает иногда некая неудовлетворённость жизнью, осознание того, что не занимаюсь ничем «для души». Начинал заниматься изготовлением моделей световых мечей из Star Wars. Вспомнил основы РЭЛа, нашёл поставщиков необходимых компонентов, собрал рабочие прототипы со световыми эффектами, а вот доделать звук и довести изделие до ума уже запала не хватило. Занялся стрельбой из лука, но сходить пострелять удаётся только в выходные, да и то не каждую неделю. А причина в том, что после смены места работы на дорогу начало уходить не 10 минут, а 3 часа. К тому же взял себя в руки и упорно получаю-таки высшее образование, а это отнимает то время на выходных, которое могло бы пойти как раз на что-нибудь «для души».
Судя по тому, что у Вас уходит по 6 часов в день только на дорогу, на занятие «рутинной частью» своего хобби уже нет сил, т.к. рутина менее интересна и побеждает желание потратить столь ценное свободное время либо на что-то поинтереснее, либо просто на отдых. Себя я тешу мыслью, что когда закончу свои затянувшиеся отношения с университетом, высвободится свободное время и «жизнь наладится» =)
Если бы Droid 3 продавался в России, то я бы с превеликим удовольствием его пощупал и, наверное, купил. А так выбор пал на SE Xperia Pro. Работает — не нарадуюсь.
А если для ноута сделать откидную полочку справа от монитора? Под ней руке с мышкой будет достаточно пространства, а если хватит места поставить открытый ноут лицом к пользователю, то будет второй монитор. Когда надо закрыть стол, ноут с полки убирается, сама полка прижимается обратно к крышке стола и не мешает его закрытию.
А у каких именно китайцев заказывали, что так быстро вышло?
Если же реализовано это будет как-то по-другому, надо уже думать отдельно. Например, в порядке общего бреда:
Имеем item prototype.
ключ:
db.odbc.select[tbs_bytes,{#TBS_NAME},{HOST.NAME}]запрос:
Новый чекбокс
Bulk request. Если он установлен, то для выполняется одна проверка для всех айтемов, сгенерированных из этого прототипа. Полученные значения раскладываются по айтемам, исходя из значения поля, заголовок которого совпадет с LLD макросом в ключе (в данном случае — TBS_NAME).Под bulk request я имею в виду одновременный сбор нескольких однотипных данных, чтобы:
1) получать консистентные «срезы»;
2) уменьшить количество запросов (чтобы не бегать по одной и той же таблице несколько раз, например).
Persistent connection избавит нас от проблемы большого количества соединений к базе, но не от перечисленного выше.
Сейчас я скриптом запрашиваю что-то типа
а потом zabbix_sender'ом отсылаю на trapper items, сгенерированные LLD. Хочется нативного механизма, причём не только для ODBC проверок.
Следует иметь в виду, что функция listagg появилась только в Oracle 11.2, поэтому с более ранними версиями такой фокус не пройдёт.
Для себя выбрал ConEmu + cygwin bash + вручную отредактированный terminfo (без него в Solaris, например, работать было невозможно).
У меня реализован подобный функционал для себя и друзей. Для своего домашнего сервера тоже делал на php + mysql. Когда же друзья начали просить и им «настроить автоматическое скачивание новых серий», пришёл к следующим выводам:
1) Для популярных систем типа Ubuntu надо оборачивать всё в пакет, где в зависимостях указывать тот же php5-curl и mysql-server, и выкладывать в свой репозиторий. Пакет сделать недолго, а устанавливать и обновлять пользователям будет гораздо удобнее.
2) (спорно) Для конечного пользователя, возможно, будет проще связка perl + sqlite, т.к. в той же Ubuntu perl уже стоит по умолчанию, недостающие модули спокойно устанавливаются через зависимости пакета, а sqlite избавляет от необходимости крутить сервер mysql (есть у меня некое предубеждение против запуска серверных демонов на рабочей машине). Но при таком раскладе встанет вопрос с GUI (в перловом варианте у меня всё реализовано через консоль).
Судя по тому, что у Вас уходит по 6 часов в день только на дорогу, на занятие «рутинной частью» своего хобби уже нет сил, т.к. рутина менее интересна и побеждает желание потратить столь ценное свободное время либо на что-то поинтереснее, либо просто на отдых. Себя я тешу мыслью, что когда закончу свои затянувшиеся отношения с университетом, высвободится свободное время и «жизнь наладится» =)