Сброс триггера по времени.

[Victor Sklyarov]

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

[Kos]

Имеется в виду - генерировать проблему не более одного раза за текущие сутки? А закрывать эту проблему при смене суток, в полночь?

[Victor Sklyarov]

Да, именно так

[Kos]

Ну, получить-то текущую дату в триггере легко - для этого есть триггерная функция date().
Кроме того, существует системный макрос {DATE} (правда, выдающий данные в чуть другом формате, и его нельзя использовать в триггерной формуле).

Тут основная проблема - с чем сравнивать эту дату. По идее, её надо сравнивать с датой последнего срабатывания триггера. Т.е. с чем-то вроде того, что возвращается макросом {EVENT.DATE}, но этот макрос недоступен в триггерной формуле (он доступен только в Action-ах по проблеме). А из того, что доступно в триггерном выпажении, - это либо значение какого-то другого элемента данных, либо пользовательский макрос.

Отсюда вытекает возможное "костыльное" решение: на исходную проблему сделать дополнительное (помимо отсылки уведомлений, если они есть) действие (Action), в котором запускать скрипт. А в этом скрипте записывать текущую дату в нужное место: либо в качестве значения пользовательского макроса (это можно сделать через Zabbix API), либо в качестве значения дополнительного элемента данных (это можно сделать утилитой zabbix_sender). Только формат этой даты дожен совпадать с тем, как она возвращается функцией date().

Мне более простым кажется второй вариант. Если сделать элемент данных с типом "Zabbix trapper" и ключом, допустим, problem_lastdate, то заслать в неё текущую дату в нужном формате можно такой командой, запускаемой на сервере Zabbix:

zabbix_sender -z 127.0.0.1 -s {HOST.HOST} -k problem_lastdate -o $(date "+%Y%m%d")

В свою очередь, в триггерной формуле для восстановления потребуется просто добавить условие:

... and date()>last(//problem_lastdate)

[Semiadmin]

А зачем к дате привязываться? Около полуночи отличить сегодня от вчера можно и с помощью time()

[Kos]

А зачем к дате привязываться? Около полуночи отличить сегодня от вчера можно и с помощью time()

Тоже верно. Если вероятность получить срабатывание триггера сразу после полуночи пренебрежимо мала, то можно просто к условиям восстановления добавить:

and time()<000100

Тогда в первую минуту после полуночи триггер закроется (если исходное условие перестало выполняться).

Если же надо закрывать в любом случае (даже если исходное условие всё ещё выполняется), то не в условие восстановления, а в исходную формулу триггера добавить:

and time()>000100

Тогда в первую минуту после полуночи триггер по-любому закроется (и, возможно, сгенерирует новую проблему в следующую минуту, если остальные условия всё ещё соблюдаются).

[Victor Sklyarov]

and time()>000100 это условие будет позволять триггеру сбрасываться в любой момент дня. and time()<000100 - в этот период должен попасть момент сбора метрики, чтобы произошло срабатывание. Но тогда не and, а or, потому что метрика в этот момент может быть и ненормальной. Решил проблему по другому. Выражение срабатывания триггера trendmax(метрика, 1h:now/1h)-trendmin(метрика, 1h:now/1h)>10 Выражение сброса rendmax(метрика, 1h:now/1h)-trendmin(метрика, 1h:now/1h)<2 Метрики снимаются каждые 10 мин, значения их в процентах. Периодичность паразитных процессов 10-20 мин. Посмотрел за двое суток поведение, очень хорошо работает. Пока есть изменение значения метрики сброса не происходит.

[Kos]

and time()<000100 - в этот период должен попасть момент сбора метрики, чтобы произошло срабатывание.

Триггерная формула пересчитывается каждый раз, когда приходит новое значение, это верно.
Но, кроме того, независимо от поступающих значений она пересчитывается ещё и раз в 30 секунд просто по таймеру в том случае, если в триггерное выражение входит хотя бы одна из временнЫх функций - time(), date(), nodata() и т.п. В промежуток от 00:00:00 до 00:01:00 такой пересчёт должен произойти дважды, поэтому условие time()<000100 хоть раз да выполнится.

and time()>000100 это условие будет позволять триггеру сбрасываться в любой момент дня.

С какой стати? Или просто невнимательно прочитали - я ведь предлагал добавить эту часть "не в условие восстановления, а в исходную формулу триггера".
Т.е. для срабатывания триггера необходимо, чтобы время суток было больше 00:01:00, соответственно - в первую минуту после полуночи это условие перестанет выполняться и проблема закроется; выражение восстановления в это случае вообще не нужно.

Но если у Вас есть решение, которое Вас устраивает, то и замечательно.

[Victor Sklyarov]

Интересно, какую нагрузку на сервер вносят пересчёты временных функций каждые 30с? Сколько же нужно запустить таймеров для обслуживания 10000 узлов с пятью триггерами с временными функциями?

[Kos]

Интересно, какую нагрузку на сервер вносят пересчёты временных функций каждые 30с? Сколько же нужно запустить таймеров для обслуживания 10000 узлов с пятью триггерами с временными функциями?

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