Повторный триггер того же элемента, но с другим условием.

[Diesel315]

Всем добрый день!
Zabbix 7.2.2

Что-то затроил, подскажите. Есть элементы данных которые опрашивают (каждые 10m) доступность SNMP агента на устройстве (орг.техника). История 1h.
Если последние две попытки были 0 (max #2 = 0), то отображается триггер в дашборде, что устройство не доступно.

Задача настроить, чтобы срабатывал триггер, если устройство недоступно более 90d.
Вот тут и застрял...

Если просто второй триггер написать, то как я понимаю он не будет срабатывать, так как история всего 1h (больше и не надо). Или будет? Можете просто нужно выбрать верную функцию триггера, а я не знаю?
Или можно как-то настроить оповещение на основе уже висящего (первого) триггера?

[Kos]

Если просто второй триггер написать, то как я понимаю он не будет срабатывать, так как история всего 1h (больше и не надо).

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

[Diesel315]

Ну видите - всё-таки вас интересуют данные больше чем за один час.

Было предположение, что можно как-то использовать уже висячий триггер.

Наверное надо было чуть подробнее пояснить задачу:
Вся орг.техника опрашивается. В том числе опрашивается доступность SNMP агента самой техники. Есть отдельный дашборд со страницами для орг.техники. Одна из страниц, как раз показывает доступность этих SNMP агентов, что очень удобно использовать применительно к актуализации данных в Zabbix, чтобы не накапливались "мертвые души". Стали замечать, что появляется техника с большими значениями недоступности. Иными словами людям выдали орг.технику, а они "тупо" её не используют)))
Вот и и родилась идея триггериться на устройства, которые больше 90 дней не доступны. Далее должен срабатывать триггер и отправлять в ITSM сообщение/обращение с задачей проверить. Ответственные проверяют, изучают и при необходимости изымают технику.

По идее можно было бы задействовать функционал экскалации, но там максимум 7 дней. То есть повторное уведомление по триггеру на другой почт.ящик можно отослать с максимальным лагом через 7 дней. А мне нужно 90 дней.
Получается остается только смотреть в сторону трендов, тоже задумывался уже о них...

Спасибо.

[Diesel315]

Хммм. Что-то не могу разобраться в синтаксисе trendmax - time period:time shift
Мне надо отследить за последние 90 дней. Правильно ли я понимаю, что синтаксис будет выглядеть так: trendmax(/Template.CSTM.Printers.HP.Black/zabbix[host,snmp,available],90d:now)=0 ?

Что-то примеров мало и они однотипные в инструкции.
Например там приводят такой пример - 1h:now/h, а можно написать 1h:now/M? Если да, то что это будет значить?

[Kos]

Хммм. Что-то не могу разобраться в синтаксисе trendmax - time period:time shift

Посмотрите перевод на русский язык документации по версии 7.0 (ссылка) - там эта часть уже описана.
Но для вашей задачи ("надо отследить за последние 90 дней") вам сдвиг времени (time shift) использовать не надо, достаточно просто указать "30d".

[Diesel315]

Но для вашей задачи ("надо отследить за последние 90 дней") вам сдвиг времени (time shift) использовать не надо, достаточно просто указать "30d".

Если использовать trendmax, то time shift является обязательным параметром. Нельзя триггер без него создать.
К сожалению так и не разобрался в этом синтаксисе, так как примеры однотипные и примитивные. Что опять же не дает понимание, как выше указывал, возможно ли например написание такого выражения и что при этом оно будет значить - 1h:now/M

Думал может такое выражение поможет - max(/Template.CSTM.Printers.HP.Black/zabbix[host,snmp,available],90d)=0 но нет. Работает не правильно.
Вернее, насколько я понял пока неправильно. Через 90 дней заработает правильно) Потому что сейчас он анализирует все имеющие данные по элементу данных. А так как тренды только начали копиться, то триггер срабатывает на большее количество устройств, которые не доступны...

Если все же подскажете касательно trendmax - time period:time shift то буду благодарен.

[Kos]

Если использовать trendmax, то time shift является обязательным параметром. Нельзя триггер без него создать.

Вы правы, я просто этими функциями сам ещё не пользовался
Видимо, это связано с тем, что сами тренды вычисляются раз в час - в начале каждого часа (ну, и ещё в некоторых случаях, которые сейчас несущественны).
Поэтому указывать период "по текущий момент" смысла нет, последнее посчитанное значение тренда всё равно будет за предыдущий час. Наверное, поэтому и "сдвиг времени" является для функций с трендами обязательным параметром, минимальный сдвиг (на начало текущего часа) обозначается как ":now/h".

Соответственно, "1h:now/M" - это будет один час, который заканчивается началом текущего месяца, т.е. последний час предыдущего месяца, а "90d:now/d" - это 90 дней, предшествующих сегодняшнему дню.

И ещё меня немного смущает вот это замечание:

Triggers that reference trend functions only are evaluated once per the smallest time period in the expression.

Т.е. если понимать буквально, то "time period" в данном случае - это 90 дней, и тогда такой триггер будет пересчитываться раз в 90 дней. Если это действительно так, то к условию триггера нужно ещё добавить какое-то фиктивное условие с нужным периодом, например, в сутки, чтобы получилось что-то вроде:

trendmax(/Template.CSTM.Printers.HP.Black/zabbix[host,snmp,available],90d:now/d)=0 and trendmax(/Template.CSTM.Printers.HP.Black/zabbix[host,snmp,available],1d:now/d)=0

Вторая часть ничего не добавит к логике условия (понятно, что если за последние 90 дней максимум был нулём, то и за вчера он тоже будет нулём), но обеспечит нужный период пересчёта триггера (раз в сутки, а не в 90 дней).

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

trendmax(/Template.CSTM.Printers.HP.Black/zabbix[host,snmp,available],90d:now/d)=0
and
trendcount(/Template.CSTM.Printers.HP.Black/zabbix[host,snmp,available],90d:now/d)>=N
and
trendmax(/Template.CSTM.Printers.HP.Black/zabbix[host,snmp,available],1d:now/d)=0

Например, если /Template.CSTM.Printers.HP.Black/zabbix[host,snmp,available] опрашивается с интервалом 5 минут, то за час таких значений будет 12, за сутки - (12*24), а за 90 суток - (12*24*90).

[Diesel315]

Ого, большое спасибо за такой развернутый ответ.

Например, если /Template.CSTM.Printers.HP.Black/zabbix[host,snmp,available] опрашивается с интервалом 5 минут, то за час таких значений будет 12, за сутки - (12*24), а за 90 суток - (12*24*90).

Тут думаю чуть не так. В моем случае опрос каждые 10 минут c историей в 1 час + тренды 91 дней.
Исходя из этого по факту за час будет 1ч*6раз значений, за сутки - (23ч*1раз+1ч*6раз)=29 (он же хранит только последний час, а потом тренды. То есть 23 час это тренды, а последний 1 час как раз каждые 10 минут)
За 90 суток соответственно - (90дн*24ч -1ч) + 1ч*6раз =2165
Вроде так)

Пойду пробовать...

Хммм. Хотел уточнить также. Если перейти в график данного элемента (Latest data --> Item --> Graph), то по графику тренд виден. Но при выборе (правый верхний угол) View as Values , данные только показываются из истории. Из трендов нет значений. Это нормально?

[Diesel315]

В общем что-то все равно не так.
Настроил триггер - max(/Template.CSTM.Printers.HP.Black/zabbix[host,snmp,available],90d)=0 and count(/Template.CSTM.Printers.HP.Black/zabbix[host,snmp,available],90d)>=2160
То есть как я понимаю (ну вернее как я вкладывал смысл) логика следующая:
1 часть триггера закладывает логику проверки данных на отрезке не более 90 дней, но не закладывает логику, что проверять нужно при наличии этих данных длинной в 90 дней. Иными словами первая часть сработает и на условно 5 днях, да хоть 1-го дня. Что в целом и логично. Здесь нет как бы предусловия, что нужно сперва накопить данные за 90 дней.
логика - "И"
2 часть как раз вроде бы и говорит, что помимо первого условия нужно еще и накопить эти данные, то есть как быть получить данные (количество) за 90 дней. Как выше и говорил формула счетчика будет примерно следующей -
(23ч*1раз+1ч*6раз)=29 (он же хранит только последний час, а потом тренды. То есть 23 час это тренды, а последний 1 час как раз каждые 10 минут)
За 90 суток соответственно - (90дн*24ч -1ч) + 1ч*6раз =2165
Но триггер почему-то сработал раньше. Например он сработал на устройство которое недоступно 1 месяц 10 дней 15 часов. По логике это всего (1мес.(30дн.)+10дн)*24зн + (14зн+1ч*6зн)=980

[Kos]

История и тренды хранятся в разных таблицах.
Функция max() обращается к таблице истории, а trendmax() - к таблице трендов. Если вы храните историю всего один час, то для функции max() будет без разницы, какой интервал вы укажете - один час, один день или один месяц; в любом случае будут обсчитываться только данные из таблицы истории, которых там имеется за один час.

Вашей математики с количеством значений я не понял. Если у вас интервал опроса 10 минут, то за один час будет собираться 6 значений, а за сутки - 6*24=144 значения. Независимо от того, как долго они будут храниться в таблице истории, в таблице трендов (если она обсчитывается корректно) будет записано, что в течение каждого часа поступало по 6 значений. Соответственно, 2160 значений наберётся за 15 суток (2160=144*15).

Я не знаю, "заглядывает" ли функция count() в таблицу трендов, если в таблице истории за указанный интервал данных нет (об этом в документации ничего не говорится), но если вы историю так долго не храните и хотите извлекать статистику из таблицы трендов, то следует использовать функцию trendcount() (ссылка).

И да, через Latest data можно посмотреть только данные истории, тренды в веб-интерфейсе напрямую недоступны.

[Diesel315]

Вашей математики с количеством значений я не понял. Если у вас интервал опроса 10 минут, то за один час будет собираться 6 значений, а за сутки - 6*24=144 значения.

Почему за сутки будет 144 значений, если история всего 1 час? Опрос раз в 10 минут, хранить историю 1 час. Далее идут тренды.
Исходя из этого я и предположил - 6 значений в последний час + 23 часа это тренд. Итого за сутки 1ч*6раз+ 23ч*1раз=29 значений
Не так понимаю тренды, разве они не хранят одно усредненное значение за 1 час?

[Kos]

Если у вас интервал опроса 10 минут, то за один час будет собираться 6 значений, а за сутки - 6*24=144 значения.

Почему за сутки будет 144 значений, если история всего 1 час? Опрос раз в 10 минут, хранить историю 1 час. Далее идут тренды.
Исходя из этого я и предположил - 6 значений в последний час + 23 часа это тренд. Итого за сутки 1ч*6раз+ 23ч*1раз=29 значений
Не так понимаю тренды, разве они не хранят одно усредненное значение за 1 час?

Если у вас за час собирается 6 значений, то за сутки собирается 6*24=144 значения. Храниться может и меньше (в зависимости от настроек истории), но собрано будет именно столько (если ничего не пропадёт).
Тренды, как описано в упомянутой мною ссылке (ещё раз, ссылка) хранят 4 значения за каждый час, обсчитанных из истории: минимум, максимум, среднее и то самое количество собранных за этот час значений (в данном примере это количество будет 6 за каждый час).
Функция count(), как и trendcount(), не считает, сколько данных хранится в трендах, она считает количество значений из истории, удовлетворяющих неким условиям.
В описании же функции trendcount() сказано буквально следующее:

The number of successfully retrieved history values used to calculate the trend value within the defined time period.

То есть, количество успешно собранных значений истории, использованных для обсчёта трендов за определённый период. В отличие от функции count(), здесь уже нельзя указывать никаких дополнительных условий (вроде "больше чем" или "содержащих подстроку"), поскольку в трендах не хранятся значения истории, а хранится только обобщённая за час статистика - в том числе и количество собранных значений истории (те самые 6 штук за каждый час, которые будут просуммированы за весь указанный период).