Исторические данные в имени триггера (например, .last(#2))

[DSV12]

Всем привет!

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

Триггер выглядит так:

(item.last(#1) + item.last(#2))  > (item.last(#3) + item.last(#4)) * K

Идея такая: триггер срабатывает, если за последний час сумма #1 + #2 превысит в K раз сумму #3 + #4 за предпоследний час. Очевидная идея использовать item.sum(3605) > item.sum(3605,3605) * K работала плохо, если в последовательности данных было много подряд идущих нулей (ещё было бы удобным иметь возможность в sum() указывать смещение в штуках, а не по времени, как в last()).

Поэтому решил триггер сделать не по времени, а используя last(). Но вылезла проблема - как передать (отразить) в имени триггера не просто ITEM.VALUE (ITEM.LASTVALUE), а сумму двух значений: last(#1) + last(#2). Дело в том, что в ITEM.VALUE (ITEM.LASTVALUE) всегда выводится последнее значение ITEM, невзирая на использованные функции в триггере, т.е. item.last(), item.last(#4), item.sum(3605) и т.д. всегда будут выдавать значение item.last(), для любого N в ITEM.VALUEN, т.к. это один и тот же item.

Пример:
K = 10
item.last(#5) = 20
item.last(#4) = 7
item.lst(#3) = 8
item.last(#2) = 159
item.last(#1) = 1

Сработает, когда #1 = 1 (на шаг раньше - НЕ сработает: (159 + 8) < ((7 + 20) * 10). Но, из-за того, что я написал выше, в диагностике будет значение ITEM.VALUE=1 и сообщение аларма будет выглядеть странно: "Слишком большое количество: 1". А хочется увидеть правильное: "Слишком большое количество: 160". Ещё раз напомню, что здесь не спасёт использование .sum() - всё равно будет выведено последнее значение (на момент срабатывания), т.е., всё та же единица.

Вопрос: как вывести в имени сумму двух значений - последнюю и предпоследнюю? Согласен на вариант типа: "Слишком большое количество: 1 + 159", без реального суммирования

Если простыми средствами не получится, два варианта решения:

1. Сделать период опроса = 3600 (час) и сравнивать только #1 и #2.
2. Сравнение на > *K делать на получасовом интервале (и тоже сравнивать только #1 и #2).

В обоих случаях в имени триггера будет выводится правильный ITEM.VALUE (last()).

[Kos]

Версия Zabbix?

Потому как в современных версиях (как минимум, 6.0 и выше; возможно, в некоторых чуть более ранных) это можно делать штатным образом. Смотри описание поля "Имя события" в настройках триггера (ссылка) и соответствующий пример (ссылка), очень похожий на приведённую задачу.

[DSV12]

Приветствую!

Версия Zabbix?

4.4

Потому как в современных версиях (как минимум, 6.0 и выше; возможно, в некоторых чуть более ранных)

{TIME} в имени события появился с 5.2.0. Я про это в курсе, но это не точно то, что мне нужно.

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

Похожий, но не точно то, что хочется. Я уже говорил, что когда использовал в триггере работу по времени: "item.sum(3605) > item.sum(3605,3605) * K", наблюдались странности в срабатывании триггера, если в последовательности данных было много нулей.

Например, так и не смог понять, почему при такой последовательности (реальный пример):
K=10
item.last(#0) = 0
item.last(#5) = 0
item.last(#4) = 0
item.last(#3) = 64
item.last(#2) = 0
item.last(#1) = 0

триггер срабатывал не на #3, а на #1 ! И при это "честно" сообщалось "Слишком большое количество: 0" с временной отметкой, соответствующей событию #1, т.е. на ЧАС позже!

Собственно, я и начал разборки, когда таких событий стало слишком много и стало интересно, откуда же это берётся. Использовался (с небольшой доработкой) готовый шаблон/скрипт, на который наткнулся где-то в интернетах. Ошибку с выводом ITEM.VALUE.last() понял сразу, но срабатывание на час позже возникновения события - так и не осознал. Как-то, за уши, можно было притянуть объяснение срабатывания на полчаса позже. Но на час? Потому и перешёл на честный .last(#n). Теперь срабатывание происходит точно, синхронно с наступлением условия. Соответственно, и в имени триггера/события хотелось бы иметь возможность доступаться к истории item, поштучно, в стиле last(), а не по времени, чтобы в событии было корректное уведомление. После разборок с sum(time, shift) чувствую, что и с {TIME} могли возникнуть какие-нибудь непонятки.

Если бы просто в "Имени триггера/события" можно было бы сослаться на любой элемент из истории, а не только на безусловный .last() (т.е., item.last(#1) и item.last(#2) считались бы разными ITEM-ами в смысле нумерации в ITEM.VALUEN).

[Kos]

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

2) "item.sum(3605) > item.sum(3605,3605) * K"
"item.sum(3605)" - это сумма значений, поступивших по настоящий момент за последний час и 5 секунд. То есть, если данные поступают с интервалом в полчаса, то сумма последних трёх (!) значений.
"item.sum(3605,3605)" - это сумма значений, поступивших за те же (1 час 5 секунд), но не по настоящий момент, а по момент, который был (1 час и 5 секунд) назад. То есть, если данные поступают с интервалом в полчаса, то сумма последних двух (!) значений:

3)

Похожий, но не точно то, что хочется

Там ключевой является возможность использовать в этом поле макросов выражений ({?EXPRESSION}), с помощью которых можно сослаться хоть на last(#2), хоть на sum(#2), хоть на почти что угодно.

[DSV12]

Константин, привет!

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

Да понятно, но сейчас нет ни времени, ни ресурсов (человеческих), чтобы перенести всё с версии 4.4 на что-нибудь более современное. С 7-ой версией забикс пробуксовал, запаздывает против своего обычного графика на полгода, на шестую переходить смысла уже нет. В своё время переходили 1.8 -> 2 -> 3 -> 4 - не всегда гладко (при переходе 2 -> 3 необратимо побилась база данных, по непонятным причинам, пришлось начинать жизнь сначала, со старых бэкапов). С переходом на пятую уже просто не было желания и сил повторять подвиги, хотя всех остальных коллег я уже успел к тому времени подсадить на заббикс, и они дружно тогда выбрали как раз пятую версию

2) "item.sum(3605) > item.sum(3605,3605) * K"
"item.sum(3605)" - это сумма значений, поступивших по настоящий момент за последний час и 5 секунд. То есть, если данные поступают с интервалом в полчаса, то сумма последних трёх (!) значений.
"item.sum(3605,3605)" - это сумма значений, поступивших за те же (1 час 5 секунд), но не по настоящий момент, а по момент, который был (1 час и 5 секунд) назад. То есть, если данные поступают с интервалом в полчаса, то сумма последних двух (!) значений:

Эт-понятно, я тоже всё подобными картинками изрисовал, вычислял. Я не упомянул ещё одну странность - при одной и той же последовательности данных, которую я приводил в качестве реального примера, срабатывание происходило ИНОГДА (чаще) через ЧАС, ИНОГДА (процентов 10-15 случаев, после скрупулёзного анализа логов) - через ПОЛЧАСА. Вот этот непонятный "джиттер" меня и доконал.

3)

Там ключевой является возможность использовать в этом поле макросов выражений ({?EXPRESSION}), с помощью которых можно сослаться хоть на last(#2), хоть на sum(#2), хоть на почти что угодно.

А, точно, ты прав - про {?EXPRESSION} я читал, но как-то мимо ушей пропустил.

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

[Kos]

Константин, привет!

Да понятно, но сейчас нет ни времени, ни ресурсов (человеческих), чтобы перенести всё с версии 4.4 на что-нибудь более современное.

Понимаю и сочувствую.
Из личного опыта: 5 версия была достаточно стабильная, мне нравилась. При переходе на 6 версию поимели немного "граблей" с настройками SLA (которые были там переделаны, фактически, с нуля), но всё остальное - вполне себе ОК, особенно порадовала возможность использовать функции агрегации с переменным числом обсчитываемых элементов (указывая в формуле звёздочку вместо имени хоста или вместо параметра в ключе элемента данных). Сейчас тоже ждём релиза семёрки, но он пока что в roadmap-е сдвинут на не очень определённое "весна 2024".

Если вернуться к исходной задаче, то для версии 4.4 я могу предложить только костыль с использованием вычисляемого элемента данных. Только нужно учитывать, что у него будет своё расписание; поэтому для подстраховки можно настроить пользовательские интервалы: задать вычисление вычисляемого (извини за тавтологию) элемента данных, скажем, секунд через 10 после опроса исходного элемента данных. Для вычисляемого хранение истории сделать коротким (одни сутки), формулу - master.last(#1) + master.last(#2) (т.е. храним сумму последних двух значений исходного элемента данных). Тогда, если интервалы для обоих элементов данных будут по 30 минут, то триггерная формула окажется вполне себе простой:

calculated.last(#1) > (calculated.last(#3) * K)

[DSV12]

Константин, привет!

Понимаю и сочувствую.
Из личного опыта: 5 версия была достаточно стабильная, мне нравилась. При переходе на 6 версию поимели немного "граблей" с настройками SLA (которые были там переделаны, фактически, с нуля), но всё остальное - вполне себе ОК, особенно порадовала возможность использовать функции агрегации с переменным числом обсчитываемых элементов (указывая в формуле звёздочку вместо имени хоста или вместо параметра в ключе элемента данных). Сейчас тоже ждём релиза семёрки, но он пока что в roadmap-е сдвинут на не очень определённое "весна 2024".

Если вернуться к исходной задаче, то для версии 4.4 я могу предложить только костыль с использованием вычисляемого элемента данных. Только нужно учитывать, что у него будет своё расписание; поэтому для подстраховки можно настроить пользовательские интервалы: задать вычисление вычисляемого (извини за тавтологию) элемента данных, скажем, секунд через 10 после опроса исходного элемента данных. Для вычисляемого хранение истории сделать коротким (одни сутки), формулу - master.last(#1) + master.last(#2) (т.е. храним сумму последних двух значений исходного элемента данных). Тогда, если интервалы для обоих элементов данных будут по 30 минут, то триггерная формула окажется вполне себе простой:

calculated.last(#1) > (calculated.last(#3) * K)

Я чуть подробнее изложу историю возникновения проблемы, с утра есть полчаса более-менее свободных: речь идёт о мониторинге postfix-а. У меня несколько подопечных серверов с MTA Postfix, и только у одного, по роду службы, есть специфическая "рванная" нагрузка по отправленной почте - это сервер списков рассылки (mailman). Только для него характерна такая нагрузка, какую я приводил в примерах: долго долго ничего нет, потом - залп из нескольких десятков/сотен писем, в случае отправки сообщения в какую-нибудь рассылку. А дальше - опять тишина (особенно ночью, в нерабочее время).

Когда я настраивал мониторинг своих postfix-ов в заббиксе, наткнулся на готовый вариант в одном авторитетном (для меня) источнике - с подробным описанием, шаблоном, скриптами. Немного подрихтовал под себя, посмотрел исходники - и запустил в работу. При этом, каюсь, не сильно вникал, почему в sum() был выбран именно такой интервал/смещение - 3605 (подспудно что-то там про границы проверки в голове мелькало), но, доверяя источнику, тщательно всё не проверил (а верить нельзя никому, как известно ). В результате всё вроде как заработало, на равномерно загруженных postfix-ах ошибка с 3605 в глаза не бросалась, а вот на сервере со списками рассылки с его "рванной" нагрузкой, частое появление ITEM.VALUE=0 с диагностикой "многовато" как-то со временем стало напрягать.

Наконец, с пару пару недель назад, решил окончательно разобраться, что же там не так. Буквально сразу же пришло понимание, что в первоисточнике ошибка: вместо 1час + 5сек (3605) там должно быть 1час - 5 сек (3595). Что ты сразу же с ходу и определил . Исправил 3605 -> 3595 - и начались проблемы с "джиттером" - момент срабатывания был то через час, то через полчаса от появления порогового значения в событиях. После чего я решил перейти на .last() вместо суммы по интервалам.

Надо отдать должное авторам исходного шаблона - в имени этого триггера они не использовали ITEM.VALUE. И ошибку с 3605 в их реализации можно было выловить или порывшись в логах или более тщательно проанализировав выражение для триггера. Я же сразу у себя добавил вывод ITEM.VALUE и долгое время терпел эту ошибку. Исправив 3605 -> 3595 и устав бороться с "джиттером" - перешёл на last(). Ну и тут же упёрся в осознание факта, что в ITEM.VALUE выводится только .last() значение. Как и в варианте с sum(), безотносительно "неправильного"/"правильного" интервала суммирования. Так устроена жизнь. Ну и исключительно для решения этой проблемы - вывода в имени триггера/события суммы - я и написал сюда. Некорректно приведя пример для варианта sum(3605) (sum приводилась просто для иллюстрации факта, что item.любая_функция - это всегда один и тот же item.last()).

Варианты с вычисляемым элементом данных тоже пробовал (вычислял через пять секунд после получения значения) - но как-то не легло на душу, было полное ощущения костыля . В итоге перешёл на получасовой интервал сравнения, без всяких сумм, т.е. просто item.last(#1) > item.last(#2) * K. Не нужно править "магические" константы в скрипте (например, 1740 - CACHE_TTL), менять период опроса и т.д. Просто переписываем (упрощаем) выражение триггера.

Константин, большое спасибо за твоё, как всегда, очень полезное участие в решении проблемы!

А я, используя твою очень наглядную картинку - с твоего позволения - обращусь к автору исходного решения с указанием на ошибку/неточность в его скрипте. Насколько я в курсе, он тоже не с нуля этот скрипт сотворил, тоже где-то позаимствовал, но поиск по postfix + Zabbix приводит на его сайт в первых же строках выдачи.

P.S. Какой всё-таки у местного движка короткий таймаут - за время написания этого сообщения несколько раз коннект рвал.

[Kos]

А я, используя твою очень наглядную картинку - с твоего позволения - обращусь к автору исходного решения с указанием на ошибку/неточность в его скрипте.

Конечно, без проблем

P.S. Какой всё-таки у местного движка короткий таймаут - за время написания этого сообщения несколько раз коннект рвал.

Да, я тоже на это уже жаловался админу форума. К сожалению, пока всё так

[Alex_UUU]

Обращу внимание на формулу высчитывания превышения.
Если есть нули, то срабатывание будет всегда, ибо 1 > 0*K,
У себя это обходили дополнительным сравнением "не нуль". И расчетом превышения в процентах.

[DSV12]

Обращу внимание на формулу высчитывания превышения.
Если есть нули, то срабатывание будет всегда, ибо 1 > 0*K,
У себя это обходили дополнительным сравнением "не нуль". И расчетом превышения в процентах.

Да, про нуль всё совершенно верно. Я этот момент сразу учёл, полная формула:

{Template Postfix:postfix[delivered].last(#2)} > 0
and
{Template Postfix:postfix[delivered].last(#1)} > ({Template Postfix:postfix[delivered].last(#2)}) * {$MAIL_DELIVERYMUCH}
or
{Template Postfix:postfix[delivered].last(#2)} = 0
and
{Template Postfix:postfix[delivered].last(#1)} > {$MAIL_DELIVERYMUCH}

Т.е. в случае нуля триггер срабатывает только если last() > K.

Кстати, автор исходного шаблона вчера отреагировал: согласился, что ошибка имеет место быть, сказал, что шаблон старый, будет переделываться, он ждёт заббикс 7.