Очень хочется включить это в следующую версию 5.0, но нам всегда приходится выбирать, так что обещать, к сожалению, не могу.
когда можно будет проводить инвентаризацию по типу glpi?
Расскажите, что именно в первую очередь не хватает.
когда заббикс научится очищать «умершие» хосты в обнаружении
«Умершие», которые были обнаружены через авторегистрацию или сетевое обнаружение? Рассматриваем возможность добавить TTL и автоматически очищать хосты, которые не сообщали о себе продолжительное время. Посмотрим.
— Если можно делать pull, то можно просто сделать нужные метрики доступными по HTTP/HTTPS, обернутые, например, в JSON, и забирать их оттуда через встроенный HTTP agent+ препроцессинг(JSONPath/ Regex ....) на стороне сервера.
А не поможет использование правил LLD как зависимых метрик обойтись без вложенных LLD?
То есть:
— берем одну мастер-метрику, ей забираем нужный нам JSON массив с вложенными объектами.
— Создаем правила обнаружения, используем в правилах мастер-метрику как источник данных.
— Через препроцессинг в правилах обнаружения (JS, например) преобразываем массив в нужный нам вид, получаем нужные макросы.
Получится только дискретный. Если входящий сигнал аналоговый, то можно попробовать «загрубить» его до меньшей точности тем же JavaScript preprocessing перед троттлингом.
да, есть. Но нужно использовать отдельные правила обнаружения для SSD и HDD. Планирую сделать такой шаблон в дальнейшем. Однако, уже сейчас LLD отдает метку в макросе DISKTYPE = SSD / HDD по которой можно создать такой шаблон самостоятельно.
Меркурий 230 — вроде точно такой же протокол. Утилита должна работать по идее. Не знаю, правда, как она отреагирует если будет три тарифа, а не два, например. Но наверняка адаптировать утилиту посильная задача.
В 3.2 и старше можно вешать nodata() и на not supported items. Таким образом, довольно простым триггером можно зафиксировать, когда oid перестал существовать.
Спасибо, завели тикет: support.zabbix.com/browse/ZBX-12602, будем проверять.
Если не сложно, уточните пожалуйста (в тикете, или тут) версию php, и другую информацию об окружении.
Очень хочется включить это в следующую версию 5.0, но нам всегда приходится выбирать, так что обещать, к сожалению, не могу.
Расскажите, что именно в первую очередь не хватает.
«Умершие», которые были обнаружены через авторегистрацию или сетевое обнаружение? Рассматриваем возможность добавить TTL и автоматически очищать хосты, которые не сообщали о себе продолжительное время. Посмотрим.
Есть в планах, на 4.4
— если нужно делать push данных, то использовать протокол zabbix_sender. Можно просто взять консольную утилиту, а можно его имплементацию на разных ЯП.
Тут подробнее: zabbix.org/wiki/Docs/protocols/zabbix_sender/4.0
Вот например, для питона есть готовое решение:
github.com/adubkov/py-zabbix#zabbixsender
А nobodysu, например, выше дал пример для node.
— Если можно делать pull, то можно просто сделать нужные метрики доступными по HTTP/HTTPS, обернутые, например, в JSON, и забирать их оттуда через встроенный HTTP agent+ препроцессинг(JSONPath/ Regex ....) на стороне сервера.
То есть:
— берем одну мастер-метрику, ей забираем нужный нам JSON массив с вложенными объектами.
— Создаем правила обнаружения, используем в правилах мастер-метрику как источник данных.
— Через препроцессинг в правилах обнаружения (JS, например) преобразываем массив в нужный нам вид, получаем нужные макросы.
Что скажете?
www.zabbix.com/documentation/3.4/manual/config/macros/usermacros#configuration
www.smartmontools.org/wiki/Supported_RAID-Controllers
ZBX-12572
support.zabbix.com/browse/ZBXNEXT-4036
Если не сложно, уточните пожалуйста (в тикете, или тут) версию php, и другую информацию об окружении.