Почему? Делаем элемент данных типа Zabbix internal с zabbix[host,discovery,interfaces] Лепим с него два LLD - один будет обнаруживать интерфейсы для IPMI и создавать айтемы на их пинг, авторой - агента, и тоже создавать элементы на пинг.
Что-то я немного так промахнулся. Всё равно же не будет работать, да? Два одинаковых прототипа icmpping[{#IF.IP}] создать даже в разных правилах не получится.
Ладно, я тут добрался до заббикса, сам отвечу на свой вопрос. =) В принципе, да, нельзя так, но если очень захотеть, можно выкрутиться, создав чуть разные прототипы: icmpping[{#IF.IP},3] icmpping[{#IF.IP}]
А зачем он вам если не секрет? В текущей версии ничего вкусного кроме мониторинга redis и systemd я не увидел.. Все хорошее будет в 5.0 В репо уже закомитили мониторинг mysql, на подходе pg, но все это в 5.0
А зачем он вам если не секрет? В текущей версии ничего вкусного кроме мониторинга redis и systemd я не увидел.. Все хорошее будет в 5.0 В репо уже закомитили мониторинг mysql, на подходе pg, но все это в 5.0
Параллельность выполнения проверок и возможность написания модулей на Go
А значит меньше геморроя с написанием бизнес-юзерпараметров отделу мониторинга, т.к. можно будет отдать написание Go-плагина для очередного Go-сервиса Go-разработчику с:
Всем привет, настроил item c ключом eventlog на активную проверку журнала windows, так он мне все логи тянет начиная с 2013 года, поставил параметр skip, все равно. Как настроить чтоб не тянул исторические данные
Всем привет, настроил item c ключом eventlog на активную проверку журнала windows, так он мне все логи тянет начиная с 2013 года, поставил параметр skip, все равно. Как настроить чтоб не тянул исторические данные