Глюк/особенность или не понимание работы механизма discard unchanged with heartbeat

[csr]

Столкнулся с непонятным для меня поведением: есть два ранее созданных айтема, у которых в препроцессинге стоит "discard unchanged with heartbeat 1d". Эти айтемы не равны друг другу и не меняются уже очень давно.

Сейчас создал триггер, который сравнивает значения этих айтемов. Триггер простейший last(item1)<>last(item2). И триггер не работает, с учетом того, что эти айтемы не равны. Если изменить значение одного из айтемов, когда триггер уже создан, то он срабатывает.

Что я делаю не так? Как сравнить такие айтемы?

ps Предполагаю, что триггеры проверяются при изменении значения, а т.к. его не происходит, то триггер и не проверяется

[Kos]

Предполагаю, что триггеры проверяются при изменении значения, а т.к. его не происходит, то триггер и не проверяется

Ваше предположение верно.
Условие триггера пересчитывается каждый раз по приходу нового значения для любого элемента данных, участвующего в триггерной формуле.
Кроме того, при наличии в триггере какой-либо из временнЫх функций (date(), time(), now(), nodata() и т.д.) условие триггера дополнительно пересчитывается ещё и каждые 30 секунд (вне зависимости от прихода новых значений).

мы добавляем шаблон на хосты (для обнаружения какой-то проблемы), а там heartbeat может быть разным и очень большим

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

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

[Semiadmin]

А в чем проблема? В наличии айтемов, созданных раньше, чем триггер? Но в течение суток триггер пересчитается, т.к. heartbeat 1d.
Чтобы не ждать, можно временно добавить в условие триггера ... and now(), и он пересчитается за полминуты, сравнив старые значения. А потом убрать за ненадобностью.

[csr]

в этом и проблема. выходит, что если триггер пересчитывается только в момент heartbeat, то может получиться не хорошая картина: мы добавляем шаблон на хосты (для обнаружения какой-то проблемы), а там heartbeat может быть разным и очень большим. шаблон добавили - алертов нет, успокоились. а получается, что надо вручную проверять интервалы heartbeat и понимать, что проблема может "вылезти", например, через неделю

добавить в условие триггера ... and now()

как в таком случае будет считаться триггер? в момент получения значения или каждую минуту/секунду/итд?

[Kos]

Предполагаю, что триггеры проверяются при изменении значения, а т.к. его не происходит, то триггер и не проверяется

Ваше предположение верно.
Условие триггера пересчитывается каждый раз по приходу нового значения для любого элемента данных, участвующего в триггерной формуле.
Кроме того, при наличии в триггере какой-либо из временнЫх функций (date(), time(), now(), nodata() и т.д.) условие триггера дополнительно пересчитывается ещё и каждые 30 секунд (вне зависимости от прихода новых значений).

мы добавляем шаблон на хосты (для обнаружения какой-то проблемы), а там heartbeat может быть разным и очень большим

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

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

[csr]

получается, при добавлении новых проверок надо за правило делать "костыль" с временными функциями и не забывать его убрать.
кроме того, если стоит просто discard unchanged, то триггер никогда не посчитается, пока не произойдет изменение какого-либо задействованого айтема.

всем большое спасибо

ps для понимания реальной ситуации: например, обнаружили, что какая-то версия прошивки имеет дыру. нам надо оперативно узнать, на каких устройствах ее надо обновить. понятно, что можно "руками посмотреть" через latest data. Но мы же хотим, чтобы это отработалось штатно - увидеть алерт на сейчас и на будущее, по алерту создать тикет и пр.

Создаем триггер в шаблоне, а он не работает, т.к. прошивка собирается через discard unchanged (или с большим hearbeat-ом), а т.к. и никто ее "за просто так" обновлять не будет, то он никогда и не сработает, кроме новых устройств или при обновлении прошивки, которые обновляются по запросу. и такое поведение может оказаться неожиданным