Чтение данных из архива хранящегося на вн

[jov]

Стоит задача - мониторить данные которые приходят с энергосчётчика по rs-232. Текущие данные не особо интересны, гораздо предпочтительней поминутные архивы которые накапливает устройство, ибо по ним и происходит сверка. В архивной записи хранятся все интересующие меня параметры. При стандартной схеме получения данных zabbix-агентом, за один активный/пассивный запрос приходит всего один параметр, это сильно нагружает устройство, но это полбеды. Гораздо хуже, что интернет-канал до агента очень не стабилен(проблема "последней мили"), то-есть я не могу сконфигурировать UserParameter на чтение последних 10 минут архива, не факт, что коннект отсутствовал меньше. Да к тому же, как я понимаю я не могу самостоятельно устанавливать timestamp у пересылаемого на сервер значения.
Извините за сумбурное изложение, мысль с утра совсем не идёт
Пока, как рабочий вариант, рассматриваю только допиливание zabbix-агента, хочу добавить туда очередь из записей считанных из устройства, которые и будут отправляться на сервер. Но это кастыли, влекущая за собой потерю возможности обновить агент стандартными средствами. Может кто-нибудь подскажет, как мне поступить?
Резюмируя. Вопросы:

• Возможно ли отсылать на сервер более одного значения, одной строкой, а затем на сервере, выделять отдельные поля из этой записи?
• Возможно ли задавать timestamp у отсылаемого параметра?
• Возможно ли автоматическое изменение параметра передаваемого в UserParameter
• в зависимости от триггера(наличие записи за последнюю минуту) и по продолжительности его пребывания в активном состояние?
• Есть примеры наращивания функционала zabbix-агента?

[dima_dm]

Используйте zabbix_sender.
Лучше использовать zabbix_sender с ключём -i и посылать сразу много значений за один вызов.

zabbix_sender


-i, --input-file <входящийфайл>
Загрузка данных из указанного файла. Укажите - для стандартного ввода. Каждая строка файла должна содержать разделители в виде blanks: <имяхоста> <ключ> <значение>.
-T --with-timestamps
Каждая строка файла содержит разделители в виде blanks: <имяхоста> <ключ> <timestamp> <значение>. Этот параметр может использоваться совместно с опцией --input-file. DT>-r --real-time
Отправлять метрики один за другим, как только они были получены. Эта функция может быть использована при чтении из стандартного ввода.

[jov]

dima_dm, вариант с zabbix_sender рассматривался, но он не решает всех проблем, зато порождает новую - необходимость писать скрипт который периодически запускается. Как по мне, так гораздо изящнее в этом случае дописывать функционал в штатный zabbix-агент.
Спасибо за то, что вы откликнулись

[dima_dm]

dima_dm, вариант с zabbix_sender рассматривался, но он не решает всех проблем, зато порождает новую - необходимость писать скрипт который периодически запускается. Как по мне, так гораздо изящнее в этом случае дописывать функционал в штатный zabbix-агент.

Я бы так не сказал. Допилить zabbix-агент, который потянет за собой zabbix_server (т.к. доработки плохо ложатся на текущую концепцию Zabbix) и поддерживать всё это в актуальном состоянии задача на несколько порядков сложнее и более трудоёмкая, чем поддержка cron скрипта который использует штатные утилиты и легко интегрируется с новыми версиями.

[gdgsoft]

необходимость писать скрипт который периодически запускается

dima_dm дело говорит и я с ним полностью соглашусь!
Пишете скрипт, который вычитывает все данные, которые вам нужны и потом через zabbix_sender кидаете данные в сам Zabbix.

Я так работаю практически со всем своим оборудованием, особенно тем, которое работает через SNMP. Это дает возможность передать на них(скрипты) всю логику обработки аварий с железки.
Сам скрипт пускаю с помощью элемента Заббикса, в который скрипт возвращает ОК или ERROR, что дает возможность контролировать процесс работы скрипта, читай - процесса мониторинга.

[jov]

dima_dm & gdgsoft, спасибо вам за ваши ответы и извините за заминку с ответом. Минусы которые я вижу в zabbix_sender'e:

• Необходимость создания с нуля системы контролирующую отправку данных. Как я уже упомянул в первом посте - connect безобразный.
• Большие проблемы с созданием инсталлятора который могла бы поставить любая секретарша. Софт будет запускаться в среде windows, вопрос создания задачи в "назначенных задания" средствами инсталлятора остаётся открытым

Поковырял исходники, большой проблемы в "допиливание" не вижу. Пока остался один вопрос, который не даёт покоя. Допустим хост с запущенном на нём zabbix'ом выключили, затем включили, как(исключительно средствами zabbix'а, не хочется использовать файловую систему хоста) определить время последней(удачной) отправки данных(чтобы не считывать весь архив данных из внешнего устройства)?

[gdgsoft]

Пусть dima_dm поправит, если я не прав...

Дело в том, что максимальное время проверки, в течении которого может ждать Zabbix данных от оборудования - 30сек.
Таким образом, если у Вас очень плохой канал, и в среднем данные из железки вычитываются больше 30сек, то скорее всего Вам без zabbix_sender не обойтись.

Касательно получения времени получения последних данных от железа, как вариант, прямое чтение из БД или использование API.

Но конечно это не тот вариант (установить заббикс на комп секретарше), для системы мониторинга, по крайней мере Заббикса.
Поставьте отдельные десктоп или поищите что нибудь другое

[dima_dm]

Поковырял исходники, большой проблемы в "допиливание" не вижу.

О каких доработках идёт речь.

Пока остался один вопрос, который не даёт покоя. Допустим хост с запущенном на нём zabbix'ом выключили, затем включили, как(исключительно средствами zabbix'а, не хочется использовать файловую систему хоста) определить время последней(удачной) отправки данных(чтобы не считывать весь архив данных из внешнего устройства)?

Это ещё один аргумент в пользу zabbix_sender, просто создаёте status файл, в котором пишите, что отправили.

[emailua]

Выложите, поажулуйста, 1 рабочий пример существующего скрипта, который работает совокупно с zabbix_sender.