Как избавиться от "дребезга" триггеров?

[Harlan]

Ситуация следующая: У меня есть несколько машин, которые мониторятся средствами Zabbix (Агент запускает приложение возвращающее значение) Буквально, каждые две-три минуты прилетает нотификация "Проблема" и тут же (с точностью до секунды) "Решено". В панели веб-интерфейса никаких проблем не фиксируется. В "железе", такая ситуация называется "дребезг контактов".
Подскажите, пожалуйста, как можно избавиться от подобного "дребезга"?

[dedy]

Как вариант поставить проверку этих данных реже, раз в минуту например.

[Kos]

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

Типичной ситуацией является неверно написанное условие триггера.

Например, когда возвращаемое значение (скажем, для такого параметра как свободное место на диске) колеблется вокруг порогового значения, пересекая его то в одну, то в другую сторону, а в триггере используется единственное условие с триггерной функцией last(). В таком случае возможными решениями могут быть: а) использование другой триггерной функции, учитывающей не одно, а несколько последних значений (min(), max(), avg() и т.п.); б) разные пороговые значения для возникновения проблемы и для её закрытия (см. раздел "Гистерезис" сейчас и в прежних версиях).

Или использование функции nodata() с плохо подобранным пороговым значением и/или сочетанием плохой синхронизации времени между агентом и сервером и работой агента в активном режиме либо через Zabbix-прокси.

Для полее предметного разговора нужно видеть (можно на скриншотах):
а) определение соответствующего элемента данных;
б) определение проблемного триггера;
в) пример возникновения и закрытия проблемы;
г) какие данные реально приходили по этому элементу данных (ряд значений из истории за указанное время и немного перед ним, взятых с экрана Latest data, вместе с их временнЫми отметками).

[Harlan]

Не видя ни вашего триггера, ни ваших данных, ни версии Zabbix - можно говорить только самыми общими словами.

Вы несомненно правы, однако, часто, просто не знаешь,к акие данные могут потребоваться для решения проблемы. Поэтому, по вашей просьбе отправляю Вам свои настройки триггеров и данных.
Zabbix 4.0.6 установлен на CentOS 7
Агенты 4.2.1 на ОС Windows 7, Windows 10 32 и 64 битных.

---

В конфигурационных файлах агентов есть строчки:
UserParameter=SB.State[*], D:\SB\SBZabix4Mnt.exe State4$1
UserParameter=SB.Count[*], D:\SB\SBZabix4Mnt.exe Cnt4$1
В зависимости от параметров он возвращает то или иное значение. Например, D:\SB\SBZabix4Mnt.exe State4Srvc1 возвращает 1, если сервис Srvc1 работает и 254, если не работает.
D:\SB\SBZabix4Mnt.exe Cnt4Srvc1 возвращает число, показывающее, сколько раз было обращение к сервису Srvc1 за некоторый период (сутки).

---

Шаблон SBT:
Элементы данных:
AgentPing Ключ: Agent.Ping Интервал: 10 секунд
CountSrv1 Ключ: SBT.Count[Srv1] Интервал: 30 секунд
StateSrv1 Ключ: SBT.State[Srv1] Инетрвал: 30 секунд
...
CountSrv5 Ключ: SBT.Count[Srv5] Интервал: 30 секунд
StateSrv5 Ключ: SBT.State[Srv5] Инетрвал: 30 секунд

Триггеры:
AgentReachable Выражение: {SBT:agent.ping.nodata(60)}=1 Зависимостей нет
ServiceError Выражение: {SBT:SBT.State[Srv1].last()}>128 or {SBT:SBT.State[Srv2].last()}>128 or {SBT:SBT.State[Srv3].last()}>128 or {SBT:SBT.State[Srv4].last()}>128 or {SBT:ST.State[Srv5].last()}>128 Зависит от SBT:AgentReachable

---

Определены узлы сети к которым применён шаблон SBT

В результате, на почту летят нотификации:
Problem: ServiceError
Problem started at 19:50:46 on 2019.05.21 Problem name: ServiceError Host: Host1 Severity: High Original problem ID: 4414 И следом:
Resolved: ServiceError
Problem has been resolved at 19:50:46 on 2019.05.21 Problem name: ServiceError Host: Host1 Severity: High Original problem ID: 4414

---

Про гистерезис прочитал, но не совсем понял, как можно задать значение так, чтобы опрашивать датчик каждую секунду в течение, например, десяти секунд и если он хоть раз ответил 1, то всё хорошо, но если всё время 254 или nodata то тогда триггер срабатывает?

[DSV12]

Вы несомненно правы, однако, часто, просто не знаешь,к акие данные могут потребоваться для решения проблемы. Поэтому, по вашей просьбе отправляю Вам свои настройки триггеров и данных.
Zabbix 4.0.6 установлен на CentOS 7
Агенты 4.2.1 на ОС Windows 7, Windows 10 32 и 64 битных.

---

В конфигурационных файлах агентов есть строчки:
...

А как же?:

Note that Zabbix 4.2 agent cannot be used with Zabbix server older than 4.2.

[Kos]

Готового рецепта у меня нет, но есть некоторые соображения.

1. У вас метрики получаются через UserParameter, т.е. через вызов внешней программы. Для нормальной работы эта программа должна отрабатывать быстро (не больше пары секунд), т.к. иначе может не укладываться в отведённый тайм-аут (навскидку - на агенте в версиях 4.х он 4 секунды). Если программа запускается и работает дольше, то могут быть неприятности в виде пропусков значений, перехода метрик в неподдерживаемое состояние и т.п.

2. Просто ради интереса: проверки (и agent.ping, и через UserParameter) выполняются агентом в активном или в пассивном режиме?

3. Для меня несколько сомнительна необходимость такого частого опроса (чаще чем раз в минуту). Впрочем, если это действительно надо, то ладно.

3. Условие триггера выглядит достаточно простым: если хоть одно из последних значений каждой из пяти метрик строго больше 128, то тревога. Правда, так и остаётся неясным, было ли на самом деле таким хоть одно из полученных значений. Надо смотреть по истории (Latest data по каждому из пяти элементов данных на этом хосте), какие данные были перед этим и в тот момент. В любом случае - для меня неясно: а) почему триггер сработал; б) почему тут же закрылся.

4. Я обычно стараюсь избегать подобных условий, если только между ними нет взаимозависимостей. Скажем, для данного случая я бы сделал 5 отдельных триггеров, каждый для своей метрики (с именем сервиса в имени триггера). По крайней мере, при срабатывании триггера было бы понятно, на какой именно сервис он среагировал; не говоря уже о более сложных ситуациях вроде "два сервиса упало, потом один из них поднялся, зато упал третий".

5. Гистерезис нужен для немного другой ситуации: когда возвращаемое значение колеблется около единственного порогового значения в триггере. На примере свободного места на диске: допустим, триггер бы срабатывал при заполненности диска более 80%, но закрывался бы при заполненности менее 75% (т.е. когда его уже немного почистили).

6.

как можно задать значение так, чтобы опрашивать датчик каждую секунду в течение, например, десяти секунд и если он хоть раз ответил 1, то всё хорошо, но если всё время 254 или nodata то тогда триггер срабатывает?

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

{Host.metric.min(#10)}>1

будет проверять десять последних значений и срабатывать только в том случае, если все 10 больше единицы.

[Harlan]

Kos, огромное Вам спасибо за помощь!

[Kos]

Удалось ли разобраться? Если да - то в чём именно была проблема?
Да, и замечание Сергея (DSV12) немного выше - тоже весьма по делу.

[Harlan]

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

[Andrey123987456]

Добрый день всем! Помогите пожалуйста. У меня возникла проблема с триггером, есть узел сети, когда он работает триггер в норме, когда пропадает из сети он мне сигнализирует проблему. {Obnaruhenie Mikrotik:icmppingsec.last()}=0 . А мне нужно сделать, что бы триггер реагировал не сразу, а если узел сети не в сети больше 5 часов. как это сделать я не пойму. Я пробовал и с count и с nodata играться, но не выходит. Сейчас я пришел к такому решению, но оно тоже не верно работает {Obnaruhenie Mikrotik:icmpping.max(18000)}=0 так же пробовал {Obnaruhenie Mikrotik:icmppingsec.count(18000)}=0 и {Obnaruhenie Mikrotik:icmppingsec.count(18000,0)}