Триггер в рабочее время

[Tallo23]

Добрый день, требуется помощь в создании триггер, который в рабочее время срабатывает, если средний трафик через сетевой интерфейс меньше 5 Mbps в течении 15 мин.

так выглядит Expression на постоянной основе

{ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].avg(15m)}<5000000

все работает, но мешает в нерабочее время

а нужно чтоб срабатывал только с понедельника по пятницу и с 4:30 до 16:30, чувствую что нужно использовать функции dayofweek и time, но опыта не хватает все это в один триггер соединить!

[Kos]

Как-то так:

{ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].avg(15m)}<5000000 and ( {TRIGGER.VALUE}=1 or ({TRIGGER.VALUE}=0 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].dayofweek()}<6 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].time()}>=043000 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].time()}<=163000) )

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

[Tallo23]

большое спасибо, будем учиться)

[Tallo23]

Хочу доработать ваш триггер, чтоб еще и по праздникам не срабатывал, хочу дописать условия типа

...({TRIGGER.VALUE}=0 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20181231 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190101 and ...)

и возник вопрос, нет ли ограничения на количество этих условий, т.к. я хочу вписать все праздники до конца 2019 года?

{ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].avg(15m)}<5000000 and ( {TRIGGER.VALUE}=1 or ({TRIGGER.VALUE}=0 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20181231 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190101 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190102 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190103 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190104 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190107 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190108 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190308 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190501 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190502 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190503 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190509 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190510 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190612 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20191104 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].dayofweek()}<6 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].time()}>=043000 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].time()}<=150000) )

такой получается у меня триггер.

[Tallo23]

Как-то так:

{ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].avg(15m)}<5000000 and ( {TRIGGER.VALUE}=1 or ({TRIGGER.VALUE}=0 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].dayofweek()}<6 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].time()}>=043000 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].time()}<=163000) )

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

только что триггер сработал, как положено, еще раз спасибо, очень помогли!

[NvAriec]

Добрый день.
Похожая задача. Необходимо посчитать сколько раз за месяц падал маршрутизатор в филиалах.
В расчёт должны попасть рабочие дни с 9:00 до 18:00, понедельник - пятница. Длительность недоступности должна быть более 30 минут. При чём если например филиал недоступен с 8, а в 9:15 стал доступен - не считать его в аварию, а так же, если стоит авария, то при переходе граничных меток времени 18:00 - не сбрасывать проблему, и сбрасывать только тогда, когда филиал станет доступен.

[Kos]

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

Длительность недоступности должна быть более 30 минут

Тогда в качестве первого критерия avg(15) не очень подходит - лучше будет что-нибудь вроде min(30m), max(30m), count(30m,...); точнее можно сказать, зная тот параметр, который Вы анализируете.

при переходе граничных меток времени 18:00 - не сбрасывать проблему, и сбрасывать только тогда, когда филиал станет доступен

Приведённый пример именно так и работает:

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

Тогда само срабатывание такого триггера будет означать наличие проблемы. А вот дальше уже нужно что-то придумывать. Если интересует именно количество, то это не так просто. Наверное, можно сделать какой-нибудь элемент данных типа "trapper", в который при срабатывании триггера засылать единицу, а при восстановлении - ноль, а поверх него навязать ещё один (вычисляемый), который будет увеличиваться при изменении первого на единицу. Только его ещё надо как-то в ноль сбрасывать в начале месяца. Либо использовать API, с помощью которого раз в месяц вытаскивать историю проблем и обсчитывать отдельно.
Но, на мой взгляд, "сколько раз" - так себе параметр. Скажем, один месяц срабатывало трижды, каждый раз филиал был недоступен 35 минут. А в другой месяц - только один раз, но недоступно было три недели. И что? Более объективный параметр - SLA, который можно собирать штатными средствами (в разных версиях Zabbix называется либо "IT Services", либо просто "Services").

[NvAriec]

Про SLA знаю, но решили считать количество падений у провайдера. Количество считать можно просто отчётом по триггеру. Сколько было его срабатываний и длительность - это не проблема.
min(30m) и т.д. не подходят.. Сейчас покажу почему:
Ситуация, что офис не доступен с 8:00. Расчётное время когда начинает срабатывать триггер - 9:00. Если мы добавляем min(30m) или даже avg(30), то по факту триггер сработает уже в 9:00. Но по факту, у него есть запас до 9:30, и если филиал поднимется в 9:29, то аварии не было.

[Tallo23]

Kos, добрый день

Хочу доработать ваш триггер, чтоб еще и по праздникам не срабатывал, хочу дописать условия типа

...({TRIGGER.VALUE}=0 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20181231 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190101 and ...)

и возник вопрос, нет ли ограничения на количество этих условий, т.к. я хочу вписать все праздники до конца 2019 года?

{ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].avg(15m)}<5000000 and ( {TRIGGER.VALUE}=1 or ({TRIGGER.VALUE}=0 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20181231 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190101 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190102 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190103 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190104 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190107 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190108 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190308 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190501 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190502 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190503 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190509 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190510 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20190612 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].date()}<>20191104 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].dayofweek()}<6 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].time()}>=043000 and {ROUTER:net.if.in[Microsoft Hyper-V Network Adapter].time()}<=150000) )

такой получается у меня триггер.

[Kos]

min(30m) и т.д. не подходят.. Сейчас покажу почему:
Ситуация, что офис не доступен с 8:00. Расчётное время когда начинает срабатывать триггер - 9:00.

Делов-то - ну так поставьте "расчётное время когда начинает срабатывать триггер" не 09:00, а 09:30, если до этого времени всё равно беспокоиться не надо.
Под "min(30) и т.д." я имел в виду такие функции, которые будут возвращать какое-то значение, однозначно говорящее о том, что все предыдущие 30 минут авария была. Но это зависит от того, что за метрика у вас собирается и что именно она возвращает. Скажем, если используется Simple check "icmpping", который возвращает единицу при успехе и ноль в случае проблемы, то вполне себе годится сравнение "max(30m)=0" (будет срабатывать только в случае, если за последние 30 минут были одни нули и ни одной единицы).

[Kos]

и возник вопрос, нет ли ограничения на количество этих условий, т.к. я хочу вписать все праздники до конца 2019 года?

Добрый день!

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

[NvAriec]

Делов-то - ну так поставьте "расчётное время когда начинает срабатывать триггер" не 09:00, а 09:30, если до этого времени всё равно беспокоиться не надо.

Гениально. Как сам не додумался %) Упёрся в различные логические выражения и т.д. %) Спасибо большое.

[Tallo23]

Добрый день!

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

т..е. если в поле условий влезет , значит норм?) ок, попробую. ну а так внешне вроде правильно составил?

[Kos]

т.е. если в поле условий влезет , значит норм?) ок, попробую. ну а так внешне вроде правильно составил?

Ну, вроде бы - формально верно; насколько эффективно это будет работать - отдельный вопрос