Timestamp момента генерации item

[IgorB]

Коллеги, добрый день

Я что-то не могу найти, как в выражении триггера добраться до таймштампа момента генерации активного или трапового итема. Смысл в том, что если какое-то значение (числовое, строковое - любое), сигнализирующее об ошибке, добралось до сервера с существенной задержкой (например, через час), то по нему не надо поднимать панику. Как реализовать такую дополнительную проверку в триггере? fuzzytime срабатывает только на итемах формата таймштампа, а больше вообще ничего похожего не вижу. Куда смотреть?

Или, на совсем исхудавший конец, в оповещение вставить эту информацию, чтобы получатель не беспокоился... Но в наборе макросов {ITEM.XXX} тоже ничего похожего.

[Semiadmin]

Думаю, можно попробовать добавить в Problem expression триггера
... and {item.key.nodata(1h)}=0
чтобы значения со старыми таймстемпами не вызывали срабатывание триггера.
В Recovery expression продублировать инвертированное Problem expression без этого дополнения, чтобы корректно сработавшие триггеры не гасились автоматически через час.

[IgorB]

nodata(1h) даст 0, если данные в течение последнего часа пришли. Она проверяет приход данных, а не момент их формирования. Так? Они и пришли. Просто уже не нужны.

[Semiadmin]

Надо проверять в ваших условиях. Я проверил через отправку значения с таймстемпом из прошлого через zabbix_sender -T -i, триггер на него не среагировал. Из этого я делаю вывод, что проверяется не момент прихода данных, а таймстемп самого свежего значения.
Что логично, т.к. в history есть timestamp, но нет никакого момента прихода значения.

[Kos]

IgorB, это, к сожалению, и вправду тот функционал, которого нет (и иногда не хватает).
Для активных айтемов с типом "Log" есть макросы {ITEM.LOG.DATE1} и {ITEM.LOG.TIME1} - они раскрываются в дату и время записи, взятой из лога; но именно только для этого типа.
Триггерных функций, которые бы возвращали таймстэмп для любых типов данных, к сожалению, нет :-(

Мне кажется, что даже были ZBXNEXT-ы на эту тему. Да, даже нашёл: вот оно.

[IgorB]

Мне кажется, что даже были ZBXNEXT-ы на эту тему. Да, даже нашёл: вот оно.

Да, я тоже это видел. Но подумал - может какой-то обход проблемы известен сообществу.

[IgorB]

Надо проверять в ваших условиях.

Для полноценной проверки мне нужно стенд развернуть с имитацией реальной обстановки. Это долго. Тем не менее - попробую, отпишусь. Но нескоро.

[IgorB]

Надо проверять в ваших условиях. Я проверил через отправку значения с таймстемпом из прошлого через zabbix_sender -T -i, триггер на него не среагировал. Из этого я делаю вывод, что проверяется не момент прихода данных, а таймстемп самого свежего значения.
Что логично, т.к. в history есть timestamp, но нет никакого момента прихода значения.

И шо я вам скажу? Оно таки работает! Подробности тестирования кому-то интересны?

[Semiadmin]

Вероятно, искусственно создавалась очередь данных на заббикс-прокси при помощи файерволла?

[IgorB]

Вероятно, искусственно создавалась очередь данных на заббикс-прокси при помощи файерволла?

Ну да. Только не файрволлом, а переключением интерфейса виртуальной машины с прокси в "тупик". Проверено на трапах и активных ключах.

Теперь осталось понять, как срабатывает функция nodata() при таком массовом приходе устаревших данных. И будет ли это работать не на стенде, где полтора хоста, сотня item-ов, тестовый обрыв связи в несколько минут, и гигабитная сеть. И очередь в результате пролетает за миллисекунды. А в реальной ситуации сеть весьма неторопливая, хостов десятки, item-ов тысячи, и перерыв связи может быть несколько часов. И обработка очереди после восстановления связи может занимать минуты. И не поэкспериментируешь особо.

[Semiadmin]

Насколько я понимаю, все очень просто. Раз в полминуты проверяется, есть ли по айтему данные с timestamp не старше часа (для nodata(1h)) . Если нет - значит, ничего и не приходило.

[IgorB]

Насколько я понимаю, все очень просто. Раз в полминуты проверяется, есть ли по айтему данные с timestamp не старше часа (для nodata(1h)) . Если нет - значит, ничего и не приходило.

Почему раз в полминуты? Почему не в момент обработки поступившего айтема и проверки сработки триггера? Куча пришедших одновременно айтемов обрабатывается параллельно или последовательно? Очередность обработки по времени их формирования соблюдается строго, или не гарантируется? И "старше часа" - это относительно чего? Момента формирования обрабатываемого в данный момент айтема? Момента его прихода на сервер? Момента его обработки (текущего времени сервера)?

Больно уж у этой функции описание скромное. И примеров практически нет.

[Semiadmin]

Nodata проверяет раз в полминуты, как сказано в доке. Айтем попадает в БД с таймстемпом от прокси, отсюда известный кейс с отрицательной длительностью проблем. Старше часа - относительно проверки nodata, т. е. текущего времени.

[IgorB]

*Nodata проверяет раз в полминуты, как сказано в доке. Айтем попадает в БД с таймстемпом от прокси, отсюда известный кейс с отрицательной длительностью проблем. Старше часа - относительно проверки nodata, т. е. текущего времени.

Т.е. Заббикс раз в полминуты обновляет для айтемов какое-то "последнее время". И в процессе вычисления функции обращается к нему, сравнивая с ним текущее время сервера. Судя по описанию функции - это какая-то временная таблица в БД или ОП, и заполняется она не по БД (раз функция дает ошибку после рестарта сервера когда еще нет данных), а по мере поступления данных. Хорошо. Принято.

Какое "последнее время" в этой таблице? Вы говорите про время прокси, которое попадает с айтемом в БД (предполагаем, что время генерации айтема совпадает с моментом его попадания на прокси). В доке на функцию говорится про "Checking for no data received" . Полученных кем? Прокси или сервером, который ведет эту таблицу "последних времен" и который вычисляет функцию?

Куча значений айтема с разным временем генерации пришла на сервер. Что-то обработалось (допустим, обработка идет строго последовательно по времени формирования - а если не допускать? совсем беда?), что-то ждет обработки. В этот момент срабатывает таймер обновления "таблицы". Какое "время" в эту таблицу попадет? Максимальное из обработанных? Максимальное из полученных в пакете? Еще какое-то? Или просто - время срабатывания таймера, мол, "на этот момент данные по этому айтему есть"? На последний вариант наталкивает ограничение на параметр функции - не менее периода срабатывания таймера.

Это в доке не описано. А оно влияет на результаты в нестандартной ситуации.

По хорошему надо не задавать эти вопросы, а полезть в код и посмотреть. Но у меня для этого недостаточно физической силы ума.

[Semiadmin]

Да нет никакой таблицы последних времен (свят-свят). Есть таблицы history для разных типов айтемов, а в них timestamp в unixtime и поправка к нему в наносекундах для каждого значения айтема. Не надо понимать "Checking for no data received" столь буквально.