Триггер со сложным условием

[Shurman]

Здравствуйте.
Столкнулся со странной проблемой при создании сложного условия в триггере (ИЛИ).
Вот как выглядит условие:

{PushWCS:WcsPing.nodata(120)}=1 | {PushWCS:jmx["WCS:group=Modules,instance-type=Manager,name=manager1","Status"].count(120,"OK","eq")}=0

Первый элемент - типа "траппер". Так вот, триггер срабатывает.

При этом я сделал ещё два триггера -

{PushWCS:WcsPing.nodata(120)}=1

и, соответственно,

{PushWCS:jmx["WCS:group=Modules,instance-type=Manager,name=manager1","Status"].count(120,"OK","eq")}=0

Ну, то есть просто два триггера сделал из двух частей условия. Так ни один из них - не срабатывает (что правильно). Почему при объединении по условию ИЛИ - срабатывает?

[ableev]

Так ни один из них - не срабатывает (что правильно).

Почему правильно-то?

Приведите значения из latest data, что ли.

[Shurman]

Почему правильно-то?

Приведите значения из latest data, что ли.

Да, разобрался - несколько дней не приходили значения по второму ключу (который JMX). Вот вам и надёжность мониторинга... Значения не приходят несколько дней, а ключ активен, не пишется "не поддерживается". Соответственно и триггер не срабатывает. Родовая травма заббикса - ты думаешь, что count(120,"OK","eq")}=0 означает "за последние 120 секунд не было ни одного ОК" - а это совершенно не так. :-( Забываю об этом периодически.

Попробую по логам JMX-мониторинга посмотреть, что за ерунда - должен или ключ переходить в "не поддерживается", или значения должно приходить.

[Shurman]

Тааак... Это, похоже, баг в jmx-gateway.

Сервер на запрос по JMX получает

2014-06-11 11:54:36.387 [pool-1-thread-6] WARN com.zabbix.gateway.SocketProcessor - error processing request
com.zabbix.gateway.ZabbixException: java.io.IOException: Failed to retrieve RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is java.rmi.ConnectException: Connection refused to host

А элемент данных - Активен. Ну и, соответсвенно, имеем то что имеем - триггер не срабатывает.

[Shurman]

Да, забыл добавить - версии всего - последние стабильные (ставил вчера из исходников, обновив 2.0.2 до 2.2.3).

[aib]

Кажется мне, что здесь прийдется контролировать .nodata() не только для WCSping, но и для jmx[...]

[Shurman]

Кажется мне, что здесь прийдется контролировать .nodata() не только для WCSping, но и для jmx[...]

nodata() - она же только для элементов типа траппер.

Да и вопрос шире: при запросе элемента данных возвращается exception, по-моему это ZBX_NOT_SUPPORTED в чистом виде!

Хотя и этот ZBX_NOT SUPPORTED жутко мешает. Я использую много юзер-скриптов, для мониторинга оракла и подобного. Если что-то ломается - элемент данных становится неподдерживаемым, а я об этом не узнаю. Нет аларма типа "Элемент такой-то стал неподдерживаемым!!!" Или есть, а я о таком не знаю?

[ableev]

nodata() - она же только для элементов типа траппер.

Это не так. nodata - для любых элементов.
В том числе, если он станет неподдерживаемым, вы сможете узнать это по nodata.

[yukra]

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

Мне дали молоток, я ударил им себе по пальцу, молоток плохой инструмент.

nodata() - она же только для элементов типа траппер.

Пруф или небыло.

Нет аларма типа "Элемент такой-то стал неподдерживаемым!!!" Или есть, а я о таком не знаю?

Колво unsupported отображается на дашборде и дергается легко из базы простым селектом

[ableev]

Вместо дашборда - проще замонтиторить на zabbix сервере ключ

 zabbix[items_unsupported]

Поставить триггер на "> 0" + наблюдать за картинкой.

https://www.dropbox.com/s/ytwbodoj9ir9nm6/Screenshot%202014-06-11%2020.25.39.png

[Shurman]

Это не так. nodata - для любых элементов.
В том числе, если он станет неподдерживаемым, вы сможете узнать это по nodata.

Значит баг - в документации.

https://www.zabbix.com/documentation/2.2/manual/config/triggers/expression

Цитата:

Use of function nodata():

{zabbix.zabbix.com:tick.nodata(3m)}=1
'tick' must have type 'Zabbix trapper'. In order to make this trigger work, item 'tick' must be defined. The host should periodically send data for this parameter using zabbix_sender. If no data is received within 180 seconds, the trigger value becomes PROBLEM.

Хотя мне казалось, что я пробовал nodata() с обычными элементами данных, не получил желаемого эффекта, полез в документацию - и вот выяснил процитированное.

[Shurman]

Мне дали молоток, я ударил им себе по пальцу, молоток плохой инструмент.

Мои соболезнования...

Пруф или небыло.

Привёл цитату из документации.

Колво unsupported отображается на дашборде и дергается легко из базы простым селектом

А зачем вообще тогда все средства доставки, зачем мне получать письмо и смс - ведь всё можно посмотреть на дашборде, да? Прелестно.

[Shurman]

Вместо дашборда - проще замонтиторить на zabbix сервере ключ

 zabbix[items_unsupported]

Поставить триггер на "> 0" + наблюдать за картинкой.
https://www.dropbox.com/s/ytwbodoj9i...2020.25.39.png

Спасибо, это вот самая реальная идея.
Хотя именно вот процитированная картинка - как раз очень характерна. На ней количество неподдерживаемых элементов скачет постоянно. При 50+ серверах это меня завалит смсками, и при этом надо будет просматривать каждый раз все 50+, чтобы понять - а где именно они появились. И при этом помнить, какие были уже неподдерживаемые до этого... Или я не допонимаю что то?

[Shurman]

Хотя мне казалось, что я пробовал nodata() с обычными элементами данных, не получил желаемого эффекта, полез в документацию - и вот выяснил процитированное.

Кстати, надо проверить, действительно. Если функция не работает для данного типа элементов данных - так надо не давать её использовать.

[ableev]

Спасибо, это вот самая реальная идея.
Хотя именно вот процитированная картинка - как раз очень характерна. На ней количество неподдерживаемых элементов скачет постоянно. При 50+ серверах это меня завалит смсками, и при этом надо будет просматривать каждый раз все 50+, чтобы понять - а где именно они появились. И при этом помнить, какие были уже неподдерживаемые до этого... Или я не допонимаю что то?

Расскажу наш воркэраунд. Так как айтемов у нас ~350k, то на каждый чих по неподдерживаемым айтемам слать алерт - бесполезно. Как видно из графика - если неподдерживаемых айтемов становится больше 500 - загорается красная лампочка. Этого достаточно, если сломать что-то глобально, например, одну проверку на всех хостах (хостов больше 500).
А для всего остального - приходит отчёт по тем айтемам, которые в течение суток постоянно отваливаются и восстанавливаются (типа, не очень хорошо, починить бы надо) и которые совсем не работают. Вот по нему уже можно судить, сломали что-то недавно, отломалось случайно или ещё что.

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

Кстати, надо проверить, действительно. Если функция не работает для данного типа элементов данных - так надо не давать её использовать.

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