Проблемы вообщем две, и прежде чем писать что то на трекере хотелось бы услышать другие мнения, возможно я чего то не понимаю...
1) icmppingsec[] если не получает в ответ ни одного ICMP reply возвращает НОЛЬ. С точки зрения графика это лажа, так как мы увидем не разрыв линии, а плавное снижение RTT до нуля. А что с точки зрения тригеров? Выгоднее проверять на нулевое значение или на nodata, или вообще никто не практикует тригеры на loss по icmppingsec[,1,,] ?
2) Как правило для мониторинга потерь в дополнение к icmppingsec[] мы таки используем icmppingloss[] и, как мне кажется, в большинстве случаев набор параметров для этих двух проверок идентичен, как и интервал обновления. Реализация же пулера zabbix такова, что каждая из этих проверок вызовет "пропинговку", т.о. если мы в каждой из этих проверок будем посылать 3 пакета и интервал опроса 60 секунд, то каждую минуту мы будем посылать на хост 6 ICMP request. Есть ли какие то причины не группировать такие проверки на уровне пулера и убирать дублирования или всем просто пофик на этот мизерный паразитный трафик?
1) icmppingsec[] если не получает в ответ ни одного ICMP reply возвращает НОЛЬ. С точки зрения графика это лажа, так как мы увидем не разрыв линии, а плавное снижение RTT до нуля. А что с точки зрения тригеров? Выгоднее проверять на нулевое значение или на nodata, или вообще никто не практикует тригеры на loss по icmppingsec[,1,,] ?
2) Как правило для мониторинга потерь в дополнение к icmppingsec[] мы таки используем icmppingloss[] и, как мне кажется, в большинстве случаев набор параметров для этих двух проверок идентичен, как и интервал обновления. Реализация же пулера zabbix такова, что каждая из этих проверок вызовет "пропинговку", т.о. если мы в каждой из этих проверок будем посылать 3 пакета и интервал опроса 60 секунд, то каждую минуту мы будем посылать на хост 6 ICMP request. Есть ли какие то причины не группировать такие проверки на уровне пулера и убирать дублирования или всем просто пофик на этот мизерный паразитный трафик?