Пользовательские интервалы. Странная работа.

[Alex_UUU]

Коллеги, приветствую. Уэе голову сломал. Или баг или фича.
Версия заббикс-сервера 5,2,4
Элемент данных: заббикс-агент (пассивный)
Интервал обновления 0
Пользовательский интервал md8h9m30
Судя по статистике все работало. Раз в месяц 8 числа в 9:30 делался зхапрос и значение есть в истории.
Поменял интервал на md8h9m0-30/5
Т.е. мне надо, чтобы опросы делались 8 числа в 9:00, 9:05 и т.д каждые 5 минут до 9:30.
Но.
Судя по статистике срабатываний триггера он начинает работать каждый день (т.е. плюет на md8)
При этом в истории данных нет, т.е. запрос не делается!!!
А т.к. в триггере у меня стоит, сраюатывать, если время больше 093000, то соответственно срабатывает каждый день в 9:30 и восстанавливается в 00:00.
Собственно вопрос: Почему не работает md8 ?

[Kos]

Больше похоже на то, что запрос-то делается по расписанию правильно, а вот с триггером - проблема.
В триггере, случайно, не выставлен режим "Multiple problem event generation"?

[Alex_UUU]

Нет. Режим генерации событий ПРОБЛЕМА - ОДИНОЧНАЯ

[Kos]

Собственно вопрос: Почему не работает md8 ?

А почему Вы думаете, что оно не работает? Работало бы - были бы данные в истории.

По всей видимости, последнее значение, которое приходило, подходит под условия триггера.
А с учётом того, что

в триггере у меня стоит, сраюатывать, если время больше 093000, то соответственно срабатывает каждый день в 9:30 и восстанавливается в 00:00.

Покажите свою триггерную формулу и последние значения из истории.

[Alex_UUU]

Вот триггер

{Template UUU:system.run[{$HOME_DIR}/UUU.pl].str(status='Ok')}=0
and
{Template UUU:system.run[{$HOME_DIR}UUU.pl].time()}>092000

Вот так срабатывало

Список событий [20 предыдущих]

Время Время восстановления Состояние Возраст Длительность Подтверждено Действия
07.04.2022 09:20:12 08.04.2022 00:00:12 РЕШЕНО 1д 3ч 24м 14ч 40м Нет 6 actions
06.04.2022 09:20:12 07.04.2022 00:00:12 РЕШЕНО 2д 3ч 24м 14ч 40м Нет 6 actions
05.04.2022 09:20:12 06.04.2022 00:00:12 РЕШЕНО 3д 3ч 24м 14ч 40м Нет 6 actions
04.04.2022 12:38:42 05.04.2022 00:00:12 РЕШЕНО 4д 6м 11ч 21м 30с Нет 6 actions
08.07.2021 09:30:03 08.08.2021 09:30:03 РЕШЕНО 9м 4д 3ч 1м 1д Нет
13.04.2021 09:23:56 13.04.2021 09:26:56 РЕШЕНО 1г 3м Нет
13.04.2021 09:18:56 13.04.2021 09:19:56 РЕШЕНО 1г 1м Нет
12.04.2021 12:31:56 12.04.2021 12:32:56 РЕШЕНО 1г 1м Нет

Вот значения

08.04.2022 09:30:07 status='Ok'
08.04.2022 09:25:03 status='Ok'
08.04.2022 09:20:07 status='Ok'
08.04.2022 09:15:05 status='Ok'
08.04.2022 09:10:04 status='Ok'
08.04.2022 09:05:00 status='Ok'
08.04.2022 09:00:06 status='Ok'
08.03.2022 09:30:03 status='Critical'
08.02.2022 09:30:06 status='Ok'

Заморачиваться с временем стал из-за того, что в качестве БД используется Кликхауз, а он данные записывает пакетами. И для ЭД, которые очень редкие получаетсяситуация, что делаетсяопрос ЭД, они отправляются в хистори, инициируется триггер, который вытаскивает данные их хистори, а новых данных еще нет и он берет старые.. Но это уже другая проблема.

[Kos]

Вроде, нормальный триггер (ну, кроме того, что один раз в элементе данных есть слэш после макроса {$HOME_DIR}, а другой раз - нет; но это больше похоже на опечатку при копировании, иначе бы Zabbix ругался при попытке сохранить такой триггер).

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

Что, на мой взгляд, можно было бы сделать:

• обновить версию Zabbix. Идеальный вариант - либо до 5.4 (она ещё поддерживается, но ей тоже осталось уже недолго), либо до 6.0 (текущая версия, к тому же LTS). А нет, 5.4 уже тоже совсем не поддерживается, поэтому только на 6.0.
• если это по каким-то причинам сделать нельзя - обновить хотя бы релиз: последний релиз линейки 5.2 - это 5.2.7 (всё же поновее, чем ваш 5.2.4); это делается достаточно безболезненно.
• если обновляться вообще противопоказано - то делать какие-то workarounds, т.е. "костыли" в качестве затычки. Например, можно добавить в конец триггерной формулы ещё такое условие:

and {Template UUU:system.run[{$HOME_DIR}/UUU.pl].nodata(300)}=0

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

[Alex_UUU]

Слеш - это я затирал лишнее :--)
Насчет nodata - подумаем, попробуем.
Спасибо.

Подумал, и решил пока сделать так:
у меня раз в месяц делается 7 опросов. И пусть триггер срабатывает, если за последние 6 :-) опросов не было ни одного Ок. Это, для меня, даже лучше, ибо ТМ проверяет наличие файла на удаленном сервере. А "файл - это очень уж странный предмет" (с) Если он есть - то никуда не денется. А ложные срабатывания могут быть из-за проблем с сеткой, например, и я их-, таким подсчетом, отметаю.