Специфичные объекты мониторинга

[kai...]

Доброго времени суток.

Основной вопрос: "куда копать?", копать же буду я сам
Основная причина вопросов в том, что я не понимаю, как устроен внутри zabbix.

Решаемая задача: на удалённом объекте установлено УСПД (Устройство Сбора и Передачи Данных) -- железяка, на которой запущен HTTP-сервер. К УСПД по RS-232 подключены точки учёта. Установка агента на УСПД невозможна.

Необходимо мониторить не только доступность самого УСПД, но и собранные на нём данные по точкам учёта.
У каждой точки учёта есть своё имя и свои номера каналов. Данные доступны по номеру канала (он есть в http-запросе), пользователю нужно имя. Имена точек учёта уникальны в пределах одного УСПД, их количество различное.

Как это должно быть реализовано? Нужна адекватная обвязка, пользователь должен лишь задать каналы, но он не должен знать ничего об аргументах и про скрипт. Как это сделать? Есть ли пример подобного решения?

Самый-самый простой пример проверки данных следующий:

curl "http://$1/crq?req=archive&t1=$(date +%Y%m%d%H%M%S {минус час})&t2=$(date +%Y%m%d%H%M%S)&g1=b$2" | wc -l

Здесь и далее лишь ИМХО. Если я ошибаюсь, пожалуйста, поправьте.
Я предполагаю, что это должен быть плагин. К сожалению, документация zabbix описывает внешний интерфейс, а не то, как он организован изнутри. Поэтому я изучаю исходники плагина для мониторинга MongoDB, чтобы хотя бы понять, как нужно писать плагины и как zabbix с ними взаимодействует. Я не представляю, правильный это путь или нет.

[Zadralo23]

Привет.
На первый взгляд задачу надо разбить на несколько этапов:
1. Получить нужные данные с УСПД.
2. Преобразовать их в какой-либо удобный формат для обработки
3. Засунуть их в Zabbix.
По первому этапу тут вам вряд ли подскажу, но если кол-во переменных различное, то надо использовать LowLevelDiscovery из арсенала Zabbix, или писать самому скрипт по получению и парсингу HTTP данных.
По второму этапу - тут то же все на Ваш выбор, или лог файл или что-то иное на что фантазии хватит.
Методов впихнуть инфу в Zabbix полно, это и zabbix_sender и Zabbix API и еще что-то найти можно.
Я бы скорее всего писал бы скрипт, который бы выполнял все и отсылал бы в Zabbix c помощью Zabbix Sender или Zabbix API.
А внутрь самого Zabbix лезть не стоит. Эти изменения могут всплыть потом и замучаешься их исправлять.
Все это мое IMHO.

[sadman]

Писание модулей Zabbix - работа специфическая. Нужно не только представлять, как внутри устроена система мониторинга. Есть несколько явных подводных камней:
1) Судя по задаче - плагин должен исполняться в контексте Zabbix Server. Одно неверное движение мысли программиста и сервер будет крашится. Готовы к отладке на уровне сложности кода Zabbix?
2) Каждый раз после смены версий Zabbix выверять - не изменилось ли что во внутренних структурах и методах. Готовы к сопровождению модуля?
3) Интуиция мне подсказывает, что ваш УСПД не сильно быстрый в плане отдачи данных. Возможно даже, что и не многозадачный. Т.е. будут явные проблемы с обработкой параллельных запросов. Заббикс же не умеет запрашивать метрики с хоста последовательно. Т.е. придется выдумывать свою очередь, как-то ею рулить, семафоры там, то-сё.

Изучение же исходников плагинов стоит начинать с dumb-plugin, который лежит в исходниках Zabbix.

На данном этапе вам, на мой взгляд, стоит пойти классическим путем - используя тип данных External script, которому передается уникальный идентификатор метрики или "путь" к ней (номер канала + имя устройства). Далее всё на уровне скрипта - http-запрос на головное устройство, парсинг ответа, вываливание результата. На нем отладите логику - тогда уже и решите, что в модуле реализовать. Нужен он вам вообще или хватит уже сделанного.

Ну, и как было указано выше - LLD облегчит жизнь администратора/оператора Zabbix (но не программиста скрипта).

Для того, чтобы определиться со способом накидывания данных в Zabbix, необходимо ответить на вопросы:
1) насколько актуальные данные нужны и необходимы ли разные периоды их получения (например - величина температуры каждые 30 сек, влажности - раз в пять минут, а объем потребленной электроэнергии - раз в час).
2) Кто и как часто будет создавать/удалять/изменять набор контролируемых метрик.

UPD: Кстати, что за странное устройство? Промышленные девайсы имеют более легковесные протоколы для взаимодействия - modbus, snmp...

[pic16f874]

задачка решается примерно так:

какой-то компьютер( это может быть и сам заббикс сервер)
запускает внешний скрипт который подключается к железке и получает
сведения о датчиках. результаты заталкиваются как данные обнаружения в заббикс.

каждый обнаруженный элемент данных запрашивает свое значение через внешний скрипт с вашей железяки и заталкивает значение в заббикс.

скрипты можно запускать на самом сервере (если нагрузка позволяет)
или на другой машине, и данные загружать в заббикс сендером.

эту машину можно оформить как прокси и поставить рядом железкой,
если нужно сохранять данные в случае обрыва линии связи между заббиксом и железкой.

реализовывал нечто подобное, когда включал в заббикс большое количество не-snmp оборудования, которое все свои аварии писало в один общий лог.