Почему-то внятного описания механизма с примерами я найти нигде не смог, хотя формально отдельные части описаны в документации на Zabbix. Я же дошёл до этого совершенно случайно, когда раскуривал чужой шаблон.
Итак, проблема – иногда есть необходимость мониторить некие процессы, ответ от которых приходит с задержкой. Где-то помогает подкрутить параметр времени ожидания ответа, но это не есть хорошо. Во-первых, сильно его задирать тоже не стоит, потому что это влияет на время ожидания ответа для любых элементов данных. Соответственно, опрашивая недоступные элементы мы можем полностью забить очередь опроса. Во-вторых, и это более актуальная проблема, ответа можно не дождаться даже в до предела растянутый период ожидания.
Примеры? Легко! Впервые я столкнулся с этой бедой, когда пытался мониторить veeam. Там есть интерфейс для powershell для получения необходимых данных. Он даже работает довольно шустро. Но вот сам модуль грузится долго шокапец. Вторая задача – получение данных о доступных обновлениях Microsoft. Там вообще пока система не пересчитает всё и вся можно ждать долго. А если ещё и система не обновлена…
Решение я подсмотрел в шаблоне как раз для сбора данных об обновлениях. Есть элемент данных, который занимается только тем, что запускает процесс и рапортует, что он жив. Всё! Zabbix получил от скрипта ожидаемый ответ, причём в короткие сроки. Однако, сам скрипт на этом работу не заканчивает, а продолжает сбор данных. По мере получения результатов он дергает Zabbix sender, который и досылает собственно необходимые данные. Ну а Zabbix в свою очередь видит элементы данных типа Zabbix trapper и по ним тасует полученное.
Добыть расположение сендера и адрес сервера уже детали и мелочи. Оно работает!!