Генерация лишних событий

[pas9x]

Здравствуйте. Имеется 1 триггер, 1 действие и 3 элемента данных.

Также имеются 2 консольных php-скрипта: http.php и https.php которые проверяют сайт на доступность. Скрипты эти принимают на вход имя хоста и URI а на консоль возвращают 0 в случае успешной проверки, либо номер ошибки.

Элементы данных:
1) Результат проверки сервера пингом: 0 - не пропинговался, 1 - пропинговался
2) Результат доступности сайта по http: 0 - всё ок, либо номер ошибки
3) Результат доступности сайта по https: 0 - всё ок, либо номер ошибки

Триггер.
Условие вычисления значения триггера такое:

[COLOR="red"]([/COLOR]({mysite.ru:icmpping.last()} = 1) & ({mysite.ru:http.php[mysite.ru,/].last()} = 0) & ({mysite.ru:https.php[mysite.ru,/].last()} = 0)[COLOR="red"])[/COLOR] = 0

В общем триггер имеет значение OK когда последний пинг успешен, сайт доступен по http и https. Если хотя-бы одно из условий не выполнено то значение триггера = ПРОБЛЕМА.

Действие.
Условие выполнения: Значение триггера = ПРОБЛЕМА
Операции: отправить сообщение о падении сайта по email и sms

Состояние триггера у меня всегда правильное. Однако есть проблема: когда веб-сервер становится недоступен (по http и https) генерируется аш 3 события, причём как-то странно. Сначала генерируется событие со статусом ОК. Затем генерируется ещё два события со статусом ПРОБЛЕМА. Соответственно мне приходит 2 письма и 2 смс. Все три события генерируются с разницей в 1 секунду.
Почему события генерируется три?

Хотелось-бы установить действие на событие "смена значения триггера", но такого я не нашёл. Т.е. хочется установить действие на событие смены значения с TRUE на FALSE или с FALSE на TRUE. При этом повторное присвоение триггеру TRUE когда он уже в состоении TRUE не должно считаться СМЕНОЙ его значения.

Собсно вопрос: как добавить какое-то действие которое будет выполняться только при ИЗМЕНЕНИИ значения триггера?

[pas9x]

PS: уже решил вопрос, но обходным путём. Создал вычисляемый элемент данных значение которого вычисляется по трём вышеуказанным показателям (ping, http, https). Элемент данных на триггере теперь только один, поэтому событие срабатывает один раз. Но это ненужный флуд БД значениями которые нужны только ради уведомлений.

В любом случае событие на смену значения триггера нужно.

Кроме того, у меня с частотой 10 секунд БД забивается одинаковыми значениями. В конце дня их получается десятки тысяч. Хотелось-бы чтобы заббикс, также, умел складывать в БД только изменение значения а не флудил БД одинаковыми значениями.

Например, у меня весь день в БД пишется статус-код http-сервиса = 0 (всё в порядке). Потом падает сайт и ещё 10 минут статус-код 4. Затем сайт снова поднимается и в БД снова пишется статус-код 0. А можно-бы было не флудить базу значениями а записывать только новое значение и время его появления.

[Kos]

Хотелось-бы установить действие на событие "смена значения триггера", но такого я не нашёл. Т.е. хочется установить действие на событие смены значения с TRUE на FALSE или с FALSE на TRUE. При этом повторное присвоение триггеру TRUE когда он уже в состоении TRUE не должно считаться СМЕНОЙ его значения.

По теме:

Оно именно так и работает (с поправкой на то, что состояния триггера называются не TRUE и FALSE, а PROBLEM и OK).
Триггер пересчитывается при получении нового значения для каждого элемента данных, который входит в выражение этого триггера (в Вашем случае таких было три).
Если надо, чтобы событие генерировалось на каждом "проблемном" вычислении (даже если триггер уже находится в состоянии PROBLEM), то в свойствах триггера есть "галочка" "Multiple PROBLEM events generation".

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

Host.ItemA.last()<>Host.ItemB.last()

неправильно, т.к. новые значения для ItemA и ItemB придут неодновременно и будут обрабатываться по очереди, т.е. триггер будет пересчитываться сначала по приходу одного из значений, а потом - по приходу второго.
Решением для такой ситуации будет не использовать функцию last(), а строить более сложные выражения, учитывающие не одно, а хотя бы два последних значения для каждого из элементов данных.

Offtopic:

Не очень понятно, зачем городить свои PHP-скрипты для веб-проверок, если сервер Zabbix сам умеет это делать. Если же надо выполнять веб-проверки не с сервера, а с агента, то при использовании ключа net.tcp.service[http,IP,port] или net.tcp.service[https,IP,port] можно добиться и этого.

[pas9x]

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

Пересчитываться может он и пересчитывается, но генерировать новое событие при том, что значение триггера не меняется - это явный баг. А если не баг то с точки зрения пользователя софта - это нелогично. Зачем генерировать новое событие со значением триггера TRUE когда оно итак уже TRUE? Ожидаемо, что событие должно генерироваться при изменении значения триггера а не при перезаписи его значения.
Спорить на эту тему бессмысленно, моё дело - предложить. Если разрабы не хотят это учитывать - ну ок, спасибо и на том что софт бесплатный.

Не очень понятно, зачем городить свои PHP-скрипты для веб-проверок, если сервер Zabbix сам умеет это делать. Если же надо выполнять веб-проверки не с сервера, а с агента, то при использовании ключа net.tcp.service[http,IP,port] или net.tcp.service[https,IP,port] можно добиться и этого.

Встроенные проверялки заббикса неинформативны. Мне нужны параноидальные проверки со всей диагностической информацией которая только может быть. В том числе мне нужно логировать HTTP-ответ сервера, если он не нормальный. Пример чекера: http://pastebin.com/Z4v40bAf

[Kos]

Ожидаемо, что событие должно генерироваться при изменении значения триггера а не при перезаписи его значения.

Повторюсь:

Оно именно так и работает [если] в свойствах триггера [НЕ выставлена] "галочка" "Multiple PROBLEM events generation".

Если у Вас не так - открывайте баг-репорт, но для этого нужно обращаться не на форум (где тусуются такие же как Вы пользователи), а в техсаппорт, прикладывая подробное описание проблемы. В Вашем случае я бы приложил, в частности, скриншоты, показывающие хронологию событий: Monitoring -> Triggers для конкретного хоста (где было бы видно, что за указанный период триггер переходил в состояние PROBLEM, как Вы говорите, только один раз); и далее - скриншот экрана после нажатия на дату (будут видны события, сгенерированные для этого триггера) и ещё раз на дату уже для события (будут видны действия - реакция сервера Zabbix на конкретное событие).

Вполне может оказаться, что триггер у Вас, всё-таки, вопреки предположениям, переходил в PROBLEM, потом в OK и снова в PROBLEM (что и вызвало двойную отсылку уведомлений).

Встроенные проверялки заббикса неинформативны. Мне нужны параноидальные проверки со всей диагностической информацией которая только может быть. В том числе мне нужно логировать HTTP-ответ сервера, если он не нормальный.

Ну, встроенная веб-чекалка тоже может давать вполне себе информативный ответ: есть web.test.fail[Scenario] и web.test.error[Scenario] для сценария и web.test.rspcode[Scenario,Step] для шага сценария, кроме того - для каждого шага можно указать тайм-аут, ожидаемый код ответа и даже строку, которая должна присутствовать в ожидаемом ответе. Впрочем, если использование скрипта для данной задачи Вас устраивает, то спорить не буду; лишь хотел указать на альтернативу.