триггер на равнозначные элементы данных

[zabbix777]

Здравствуйте.
У меня есть три источника данных на одном узле сети. через 3 элемента данных (test1, test2, test3) я узнаю их состояние. Допустим 0 - доступен, 1 -недоступен. Источники данных взаимосвязаны между собой и доступен всегда только один.
мне нужно отловить событие, когда станут недоступны сразу все источники. Т.е. ситуация когда недоступны только 1 или 2 из них это норма. Как это можно настроить? какой должен быть триггер? я так понимаю зависимые триггеры здесь не помогут, т.к. тут должен быть один основной элемент данных, а они равнозначны.
Да и можно ли выставить задержку, т.е. они должны быть недоступны в течении 1 мин и более.

[Kos]

Не очень понятно, с каким интервалом собираются эти данные.

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

Или сделать элементы данных с ключами test[1], test[2] и test[3] (т.е. номер источника данных перенести из имени в параметры ключа).
Тогда несложно добавить четвёртый элемент данных - вычисляемый, указав в нём функцию агрегации min() и желаемый интервал. И уже на этот элемент данных навешивать триггер.

[zabbix777]

Не очень понятно, с каким интервалом собираются эти данные.

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

Или сделать элементы данных с ключами test[1], test[2] и test[3] (т.е. номер источника данных перенести из имени в параметры ключа).
Тогда несложно добавить четвёртый элемент данных - вычисляемый, указав в нём функцию агрегации min() и желаемый интервал. И уже на этот элемент данных навешивать триггер.

Данные о состоянии собираются через трап. Т.е. если проиходит переключение источника данных, приходит отключение от одного источника и подключение от другого источника.
Не совсем понял, что значит номер источника перенести в параметр ключа. Как будет ключ выглядет?

[Kos]

Не совсем понял, что значит номер источника перенести в параметр ключа. Как будет ключ выглядеть?

Вместо ключей

test1, test2, test3

сделать ключи

test[1], test[2] и test[3]

Разумеется, в скриптах, вызывающих zabbix_sender, это тоже нужно будет поправить.

[Alex_UUU]

Ну и вариант: вычисляемый ЭД, в котором все три ЭД и триггер на него.
Типа складываем, и если равно нулю - "Шеф, все пропало".

[zabbix777]

Вместо ключей

сделать ключи

Разумеется, в скриптах, вызывающих zabbix_sender, это тоже нужно будет поправить.

а как работает вычисляемый элемент данных для функции min с периодом, если на самом вычисляемом элементе есть свой интервал обновления?
Давайте предположим реальную ситуацию. Переключение с test 1 на test2. C Источник данных test1 приходит 1 через 4 секунды с test2 приходит 0 с test 3 ничего не приходит он остается в состоянии 1.Предположим я допустимым временем переключения считаю 15 s. Потом после переключения может несколько часов никаких данных не приходить, если все ок. как в этом случае должна формула выглядеть?
min(/test1/test[1],/test2/test[2],/test3/test[3], 15s) . Какой интервал обновления тогда ставить? без разницы
Ну и потом видимо тригер должен быть last(вычисляемый элемент)=1

[Kos]

Если исходные данные приходят крайне нерегулярно (и в нормальной ситуации довольно редко), то вариант с вычисляемым элементом данных будет, наверное, неэффективным, поскольку для него нужно, чтобы в истории были значения остальных элементов данных, на которые он ссылается.
Хотя, как раз, функции агрегации могут нормально работать и в том случае, когда каких-то значений в истории нет.
Да и для "обычного" триггерного выражения нужно, чтобы значения были (за редкими исключениями, вроде функции count()).

Хм, надо ещё подумать. Что-то крутится в голове, но пока не могу сформулировать.

[zabbix777]

Если исходные данные приходят крайне нерегулярно (и в нормальной ситуации довольно редко), то вариант с вычисляемым элементом данных будет, наверное, неэффективным, поскольку для него нужно, чтобы в истории были значения остальных элементов данных, на которые он ссылается.
Хотя, как раз, функции агрегации могут нормально работать и в том случае, когда каких-то значений в истории нет.
Да и для "обычного" триггерного выражения нужно, чтобы значения были (за редкими исключениями, вроде функции count()).

Хм, надо ещё подумать. Что-то крутится в голове, но пока не могу сформулировать.

я пока сделал триггер на три элемента данных:

last(/test1/test[1])=1 and last(/test2/test[2])=1 and last(/test3/test[3])=1 and nodata(/test1/test[1],15s)=1 and nodata(/test2/test[2],15s)=1 and nodata(/test3/test[3],15s)=1

Вроде более менее работает.

Еще мне нужен информационный триггер, который бы говорил, что произошло переключение этих трех источников данных. тоесть об изменении нормального состояния 0,1,1 на 1,0,1 и т.п. желательно чтобы в этом случае уведомление о восстановлении не приходило, но я так понимаю это действие оповещения надо настраивать, причем так чтобы во всех других имеющихся действиях исключить этот триггер, что как-то сильно громоздко кажется для одного триггера. Поэтому в принципе уведомление о восстановлении пусть приходит, но сразу же после сработки аварии. Как это можно настроить?
У меня пока получилось только так:

avg(last(/test1/test[1]),last(/test2/test[2]),last(/test3/test[3]))<1

с опцией множественной сработки. Проблема в том, что тут восстановление приходит, когда приходит в момент следующей сработки, т.е. сначала восстановление потом сработка.