В истории 2 постоянно

то есть получается, что проблема вечная? ну добавьте в триггере разрешение закрывать вручную, но это конечно фигня, может тогда поменять логику сбора элемента, либо вообще какой смысл в этом триггере

Потому что 2 - это ненормальное состояние конкретного айтема. Ведь вы так говорите триггеру: " Скажи мне, когда метрика примет значение 2". Почему по истечении 120с то же значение 2 перестает быть проблемой?

я на Python пишу, на работе теперь надо для Zabbix  скрипты писать, еще не разобрался в нем. В этой задаче, знаю что тип триггера числовой, если есть проблема, то приходит Integer = 2, условие срабатывания триггера типа, item.last() = 2 (т.е. если последнее значение равно 2, то триггер срабатывает). Если при следующих запросах не приходит 2, надо чтобы проблема исчезала. Поэтому думал, что если проверять в условии восстановления nodata(), то триггер сбросится. Но видать я чего-то недопонимаю. Т.к.      на следующем запросе уже этого элемента нет.

Т.е. nodata() и другие проверки не пройдут, значит что-то в условии срабатывания надо менять. По истории точно тоже не могу сказать, кажется, значение 2 постоянно, но завтра уточню.

Правильный вопрос 👍👍👍

Что это за элемент? Почему он так мало живёт?

Каша :)

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

Например, метрика собирает статус блока питания на железке по snmp, мы условно знаем что если с блоком питания все ок, значение snmp запроса будет всегда 1, а если что то не так, то допустим 2. Если мы настроим триггер на 2, то как только при очередном опросе snnp вернут в метрике 2, сработает триггер будет проблема

Спустя время равное апдейт интервалу, тот же snmp, собирая ту же метрику, снова опросит железку на предмет статуса блока питания, и вернет, допустим, 1. Тогда триггер уйдет сам.

Пока метрика возвращает 2, авария будет висеть.

Просто ещё вариант - человек говорит о трапах. То есть железка сама послала 2. И ушла в закат. А события на клир не шлёт априори.

Но это так, допущения из личной боли

ED, получается у вас, если элемент не равен 2, то он вообще не появляется

Приветствую, как можно повлиять на скорость разработки данной фичи https://support.zabbix.com/browse/ZBXNEXT-5166 ?

занести денег разрабам

"Просто ещё вариант - человек говорит о трапах. То есть железка сама послала 2. И ушла в закат. А события на клир не шлёт априори. ". Я думаю у меня именно этот вариант. Тогда, как я понял, надо чтобы железка постоянно слала данные, напр, 1, и если пришла 2, то авария?

А это совершенно другая история. Бери самокрутку, ща расскажу )

В случае, если сервер заббикса настроен на прием трапов, то при правильной конфигурации железок, за которыми сервер присматривает, они способны отправлять так называемые snmp-трапы, то есть сообщения о каких то событиях. Эти трапы (их обозначения), обычно описываются производителями железок в миб файлах. Есть общие трапы. Типа линк даун. То есть свитч такой увидел, что у него порт потух, а сам он работает и отправил голубем серверу трап с сообщением, что такой то порт потух.

Сервер, слушая эту железку,  отловил это трап. Заботливый администратор системы мониторинга тщательно настроил метрику, которая будет принимать определенное значение, когда придет именно этот трап. То есть last data будет по метрике пустым до тех пор, пока железка не сообщит что порт даун . Допустим, железка это сообщила, прислав условную 2 для данного порта.

Тогда да, мы получили 2. Аларма, полундра, все пропало.

Теперь надо понять, когда все стало хорошо. Есть два варианта: все стало хорошо, и тогда железка шлёт так называемый клиар трап. Это уже немного другой трап, другие цифры, но его тоже можно отличить. Второй вариан . Все стало хорошо, ну и черт бы с ним, я просто буду молчать, ага

Вот в первом случае я делала так. Срабатывает триггер, если метрика, которая ловит 2 для этого порта словила таки 2, а метрика которая clear трап ловит после этого ничего не получила, а резолв - это наличие данных во второй метрике. Ну может костыль, но так сработало.  А вот для случая когда клиры не приходят и единожды вылезший трап - либо да ручная зачистка, либо поставить поставить че та типа nodata(2min)=0, типа сработал 2 минуты повисел и потух. Но мне такая конфигурация на нравится и я ещё думаю 😔

2 вариант пробовал, завтра над 1 вариантом поработаю. Большое спасибо, теперь намного лучше стал понимать проблему.

Для сообщений в логах тоже частая ситуация, когда по проблеме что-то падает в лог, а по восстановлению ничего.

Good to make use of every opportunity that comes to your way. nice doing business with you thank you Mrs Prisca Nelson for making my life so easy with your online trade. I am so happy  to tell people about your online trade that makes me yield good profits, it feels so nice to work from home and make enough money..contact Nelson Prisca today and make nice profits for yourself. Just click her and contacts

@ForexTradeAndBinaryOption


WhatsApp +16156852469

https://t.me/joinchat/AAAAAFXmM7dD9X0lVMWdVw

А намекни, каким образом вытаскивал очереди по хостам?

Доброго дня. Кто-нибудь может показать, как выглядит пользовательский график с функцией all? У меня даже при интервале > 1 года не видно разницы между функциями avg и all, при этом метрика снимается каждую минуту. То есть явно присутствует "перегрузка данными на вертикальный пиксель графика".
Я ожидаю, что это будет выглядеть, как простой график из Latest Data, когда он показывает max/min/avg значения. Или я чего-то не понимаю, или это баг.
Версия Zabbix 4.0.17.

День добрый всем.
Подскажите, есть ли какая-нибудь статистика историческая по количеству триггеров, хостов, элементов данных добавленных в единицу времени?