Discard unchanged with heartbeat. Требуется пояснение

[Diesel315]

Добрый день!

Требуется пояснение по Discard unchanged with heartbeat. Не очень понятен механизм данного функционала.

Суть:
Есть элемент данных допустим который опрашивается каждую минуту (1m), если мы включаем предобработку Discard unchanged with heartbeat и выставляем значение в 1 час (1h), то правильно ли я понимаю, что теперь элемент данных будет опрашиваться только 1 раз в час?
Иначе говоря время предобработки "перебивает" время опроса прописанного в самом элементе данных. Так?

[Kos]

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

Например, у вас есть параметр, показывающий состояние какого-то сервиса, который возвращает 1 (up) или 0 (down).
Тогда бОльшую часть времени при нормальной работе будут возвращаться единицы, но хранить их все в базе нет большого смысла.
При настройке с тротлингом такая единица будет сохраняться в базе лишь раз в час, хотя опрашиваться по-прежнему будет раз в минуту.
Зато в случае сбоя (когда вместо единицы придёт ноль) это будет обнаружено сразу же (т.е. в течение минуты), поскольку значение отличается от предыдущего.
Аналогично - при закрытии проблемы: раз в минуту будут приходить нули, которые будут отбрасываться (т.е. не записываться в базу), но по приходе первой же единицы триггер закроется.

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

[Kos]

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

Например, у вас есть параметр, показывающий состояние какого-то сервиса, который возвращает 1 (up) или 0 (down).
Тогда бОльшую часть времени при нормальной работе будут возвращаться единицы, но хранить их все в базе нет большого смысла.
При настройке с тротлингом такая единица будет сохраняться в базе лишь раз в час, хотя опрашиваться по-прежнему будет раз в минуту.
Зато в случае сбоя (когда вместо единицы придёт ноль) это будет обнаружено сразу же (т.е. в течение минуты), поскольку значение отличается от предыдущего.
Аналогично - при закрытии проблемы: раз в минуту будут приходить нули, которые будут отбрасываться (т.е. не записываться в базу), но по приходе первой же единицы триггер закроется.

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

[Diesel315]

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

Спасибо. Да уже методом эксперимента/тыка в целом понял этот смысл.

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

Вот с этим как раз и столкнулся. Пока первые мысли, что Discard unchanged with heartbeat вообще лучше не использовать на тех элементах, которые имеют связанные триггеры. Неоднозначные последствия...
Ну и собственно по вашему примеру выше /реагировать, если последние пять значений - нули/, как тогда надо переписать триггер? Потому что как раз ранее он (триггер) и был написан условно с параметром max(......,#5)=0.
Получается нужно уходить "на время" - max(......,5m)=0?

[Kos]

Ну и собственно по вашему примеру выше /реагировать, если последние пять значений - нули/, как тогда надо переписать триггер? Потому что как раз ранее он (триггер) и был написан условно с параметром max(......,#5)=0.
Получается нужно уходить "на время" - max(......,5m)=0?

Тут тоже не так всё просто, поскольку грабли любезно разложены со всех строн

Грабли первые: триггерное выражение пересчитывается при обработке нового значения при записи его в базу. То есть, написав просто "max(......,5m)=0" мы ничего не добьёмся, поскольку такое выражение пересчитается сразу же при получении первого нуля (и либо сразу же сработает, либо нет - смотря когда была предыдущая последняя единица: больше пяти минут назад или меньше), а следующий раз (если сервис всё ещё неработоспособен) пересчитается только через час, когда придёт следующий ноль.
Но эти грабли сравнительно несложно обойти: достаточно добавить в триггерное выражение какую-либо из функций, связанных со временем (nodata(), time(), date(), month() и т.д.), тогда триггер будет пересчитываться не только по приходу нового значения элемента данных, но и (дополнительно к этому) просто по таймеру каждые 30 секунд. Например: "max(......,5m)=0 and time()>=0" - последняя часть на логику не повлияет (она является формальной, поскольку всегда будет верной), но приведёт к пересчёту триггера по таймеру.

Грабли вторые: значений в базе гораздо меньше (поскольку, как мы выяснили, сохраняются только изменённые значения, либо не чаще чем раз в час для нашего примера). То есть, если новых значений в базу записано не было, то через пять минут функция "max(......,5m)" вернёт неизвестно что (за последние 5 минут значений-то нет). Поэтому лучше использовать функцию count() (она возвращает значение всегда) и, возможно, в сочетании с last() (смотреть, что было последним). Например:

time()>=0 and last(...)=0 and count(..., 5m, "ne", 0)=0

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

last(...)=0 and nodata(5m)=1

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

last(...)=0 and (nodata(5m)=1 or last(..., #2)=0)

Т.е. последнее значение - точно ноль, и либо предпоследнее тоже было нулём, либо более пяти минут не приходило ничего.

[Alex_UUU]

Вот было бы на русском написано, тоже бы вставил свои пять копеек.
С предобработкой "Отбрасывать неизменившиеся значения" можно работать, если в триггерах используется только последнее значение элементов.. Например diff прекрасно работает.

[Kos]

Вот было бы на русском написано, тоже бы вставил свои пять копеек.

Хм, это о чём такая реплика? Надеюсь, не о моём комментарии?

[Alex_UUU]

Хм, это о чём такая реплика? Надеюсь, не о моём комментарии?

Не-не... О " Discard unchanged with heartbeat."
ПРосто привык к переводу :-) И сначала не понял о чем речь, увидев незнакомые буквы :-)

А на такое поведения действительно натыкаешься, но обычно потом, когда начинаешь все оптимизировать. А у тебя триггер на max(#5)=0 а ты поставил при минутном опросе "не записывать не измененные данные с контролем времени раз в сутки". И триггер сработал только через 5 дней.

[Diesel315]

Тут тоже не так всё просто...

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

В общем пока эта функция для моего случая загадка.
Усложнять логику триггеров (с вашей помощью и подсказками) пока нет желания. Система не должна быть сложной, она должна быть просто и понятной и лишь в исключительных случаях необходимы "костыли".

[Kos]

Хмм, если честно, то жесть...
[...]
В общем пока эта функция для моего случая загадка.

Понимаю вас, поэтому и ответил подробно (поскольку сам на эти грабли наступал).

По поводу применения - есть, как минимум, два типовых сценария, когда такая функция однозначно полезна:

1. Мониторинг редко меняющихся параметров, отражающих состояние; при этом надо оперативно реагировать на смену этого состояния (как в моём примере). То есть, опрашиваем параметр часто, если всё в порядке - в базу сохраняем редко, но если произошёл сбой - то реагируем сразу же (и сообщение о восстановлении получаем сразу же).
2. Правила низкоуровневого обраружения. Как правило, список обнаруживаемых объектов (файловых систем, сетевых интерфейсов, портов на сетевом оборудовании и т.п.) меняется относительно редко, поэтому для подобных вещей тротлинг вполне оправдан (если ничего не менялось, то ничего и не делаем), тем более, что отрабатывание правил LLD в Zabbix-е - относительно "тяжёлая" задача. Зато при изменении конфигурации (например, добавили новый виртуальный порт на свитче - скажем, агрегат или VPN) не надо долго ждать следующего (редкого) цикла опроса.

Разновидность второго сценария - случай (всё чаще встречающийся), когда какая-либо система возвращает JSON, который затем (при помощи зависимых элементов данных) используется как для обнаружения объектов, так и для извлечения их значений. Значения собирать нужно часто, а список объектов меняется редко; поэтому для правила обнаружения можно делать предобработку из двух шагов: 1) оставить в JSON-е только то, что нужно для обнаружения (т.е. убрать все динамические значения, оставив только относительно статичный список объектов); 2) добавить тротлинг, чтобы не дёргать LLD лишний раз, если список объектов не менялся.