Empty WMI search result

[Whols]

Добрый день! Не могу побороть обработку данных. Есть элемент с ключом wmi.get[], отслеживающий задания на печать. Через этот же wmi запрос мы отслеживаем через powershell ошибки печати.Если ошибка печати, прилетает значение - в нашем случае SELECT значения Name (принтера). Логично, что значению присвоен тип "Text". Если ошибок нет, элемент получает пустое значение и получаем сабж. Так бы и бог с ним, пусть висит unsupported до получения данных. Но я не могу запустить выражение восстановления.

[Hamardaban]

Выражение восстановления из какого состояния? Из проблемы! А у вас проблема не генерируется . До нее не доходит дело - данных нет => нет и источника проблемы.
В новой версии 5.2 есть метод борьбы с такой ситуацией! https://www.zabbix.com/documentation...on/whatsnew520
CUSTOM HANDLING FOR ITEM ERRORS

[Whols]

Выражение восстановления из какого состояния? Из проблемы! А у вас проблема не генерируется . До нее не доходит дело - данных нет => нет и источника проблемы.
В новой версии 5.2 есть метод борьбы с такой ситуацией! https://www.zabbix.com/documentation...on/whatsnew520
CUSTOM HANDLING FOR ITEM ERRORS

Не, апдейт до 5.2 не вариант. Можно ли как то пустое row-значение для wmi обойти? Есть же функция nodata(). Но для wmi.get почему то не применима.

[Semiadmin]

А какая сейчас версия? Если хотя бы 4.2, то можно попробовать wmi.getall (агент не ниже 4.4). Получить запросом сразу все, что интересно, разобрать на зависимые через JSONPath, если чего-то нет - использовать обработку ошибок.

[Whols]

А какая сейчас версия? Если хотя бы 4.2, то можно попробовать wmi.getall (агент не ниже 4.4). Получить запросом сразу все, что интересно, разобрать на зависимые через JSONPath, если чего-то нет - использовать обработку ошибок.

Спасибо, не знал, что такое появилось на 4-ке. Но если это синоним SELECT * то там ничего путного не получаем. Нет задания на печать, нет связанной инфы.

[Whols]

Поменял на .getall - ничего не изменилось. Нет данных. Empty WMI search result. Существует ли вариант обхода этой ситуации через Preproccessing?
В целом, при появлении данных триггер отрабатывает. Закрыть алёрт можно, конечно, и вручную. Но хотелось бы автоматизировать. Проблема:
1. При появлении очереди печати wmi запрос получает данные. Срабатывает триггер.
2. При очистке очереди данных по этому запросу нет, элемент получает корявый стейт, триггер закрытия не отрабатывает. Алёрт продолжает висеть.
Может попробовать перевести в активный режим? Пусть на агенте будет кривой стейт, который он не отправит и тогда .nodata(). Или отправит?

[Whols]

Все-таки поборол я эту связку - оказалось, начиная с версии 3.2 ряд функций триггеров обрабатывают и неподдерживаемые элементы.

https://www.zabbix.com/documentation/4.4/ru/manual/appendix/triggers/functions

Начиная с Zabbix 3.2, функции nodata(), date(), dayofmonth(), dayofweek(), now() и time() вычисляются также и для неподдерживаемых элементов данных. Другие функции требуют чтобы элементы данных на которые они ссылаются были поддерживаемом состоянии.

Например, .nodata() понимает неподдерживаемый элемент как отсутствие данных. У меня оно применялось только в выражении восстановления. В связке с проверкой рядовой функцией это не работает - триггер все равно уходит в фолл если элемент не поддерживается. Теперь все четко: есть данные-триггер, пустой wmi ответ-не поддерживаемый элемент- восстановление.