Zabbix’овые странности

новый zabbixТолько что столкнулся с одной очень неприятной особенностью Zabbix (выявлено в версии server 1.6.5). Совершенно неожиданно перестали заноситься в базу данные от айтемов, описанных в /etc//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

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

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

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

Zabbix’овые странности: 3 комментария

    • “4-символьный агент” — дейстительно версии 1.4, на древней фряхе. Но ведь он-то отдаёт свою строчку как в zabbix_get, так и в телнет! Похоже, сервер неправильно её обрабатывает?

  1. Проблема решена: всё дело было в тюнинге нового postgres, который, судя по логам, просто не успевал обрабатывать данные от zabbix. Но почему это выразилось именно в пользовательских параметрах и External check?!

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *