Только что столкнулся с одной очень неприятной особенностью zabbix (выявлено в версии zabbix server 1.6.5). Совершенно неожиданно перестали заноситься в базу данные от айтемов, описанных в /etc/zabbix/zabbix_agentd.conf как пользовательские параметры. Дело было так: возникла необходимость мониторить нагрузку на CPU у процесса natd. Был написан такой пользовательский параметр:

UserParameter=natd,/bin/ps axu | /usr/bin/grep "natd -f" | /usr/bin/head -1 | /usr/bin/awk '{print $3}'

Но он, проработав некоторое время (!!!), почему-то ушёл в состояние No data. Отладка, включённая на сервере и на агенте, показала, что агент исправно отдаёт данные, а сервер не может их принять:

17258:20090310:184226 Timeout while answering request
17258:20090310:184226 Get value from agent failed. Error: ZBX_TCP_READ() failed [Interrupted system call]

При этом сеть работала нормально. Дальнейшие исследования лишь подтвердили первоначальный диагноз: консольная команда

zabbix_get -s 10.10.10.10 -k natd

с сервера выполнялась, получая данные, а вот до базы они так и не доходили. Поиск по форуму zabbix вывел на похожие симптомы и подсказал решение. Проблема снялась переименованием айтема из natd в natdstatus.

Но на этом злоключения не закончились. После перехода на последнюю версию Postgres (8.4) похожие проблемы появились с данными, получаемыми по External check. Но они вышеописанными телодвижениями не лечатся! В некоторых случаях (закономерность пока не выявил) помогает удаление айтема и создание его заново.

Так что будьте бдительны! Проверьте свой мониторинг: такое “залипание” может привести к тому, что контролируемый параметр выйдет за границу, а триггер не сработает. Могу порекомендовать хотя бы бегло просмотреть Latest data на предмет давно не обновлявшихся айтемов. Также советую ввести дополнительные проверки особенно критичных параметров на состояние No data.