zabbix-agentd - Потери метрик

[aleksandr.lesovoy]

Привет, коллеги. Столкнулся со следующей проблемой:
При мониторинге хоста, на котором находится userparameter который тормозит и периодически отваливается по таймауту (например выполнение lsof), начинают страдать и остальные айтемы: например на графиках свободного дискового места появляются провалы. При отключении проблемного айтема, работа остальных нормализуется. Пробовал менять количество StartAgents, но это ничего не дает. Отсюда вопрос, есть ли решение этой проблемы? Версия агента 3.4.15, но и на других версиях проблема сохраняется.

[sadman]

Типы проверок (айтемов) какие?

[max.ch.88]

Типы здесь не имеют значения. Так же как и версии Zabbix.
Лечится двумя шагами, применимыми к любой версии Zabbix:
1.чтобы получать результат через ожидаемое время, а не уходить в бесконечность, запускайте всё через команду timeout с последующей обработкой.
2.в конфиге zabbix-сервера устанавливайте значение параметра timeout больше, чем в конфигах zabbix-агентов. я ставлю 30 и 25 соответственно.
Большое пожелание к разработчикам включить второй пункт в документацию. Думаю многие ломали голову почему из-за одного сбойного item'ма появляются дыры в данных по живым item'ам того же хоста.

[aleksandr.lesovoy]

Спасибо за ответ, буду работать в этом направлении

[sadman]

Типы здесь не имеют значения. Так же как и версии Zabbix.

Т.е. вы хотите сказать, что ваши способы позволяют обойти проблему пропуска запусков активных проверок при одной тормозной?

[max.ch.88]

Да,позволяют.

[sadman]

А не дадите ссылку на "команду timeout"?

[max.ch.88]

man timeout
NAME
timeout - run a command with a time limit

SYNOPSIS
timeout [OPTION] DURATION COMMAND [ARG]...
timeout [OPTION]

DESCRIPTION
Start COMMAND, and kill it if still running after DURATION.

Mandatory arguments to long options are mandatory for short options too.

[sadman]

Так это способ с забросом информации самим скриптом, так? Тогда можно system.run[команда,nowait] использовать. Или вообще по крону работать.

[max.ch.88]

Никаких забросов и кронов. Абсолютно штатный функционал агента. Например, так я проверяю состояние смонтированных по сети разделов: nfs.check[<точка монтирования>]
UserParameter=nfs.check[*], res=$(timeout -s 9 10 stat -f -c %T $1); if [[ $res = 'nfs' ]] || [[ $res = 'cifs' ]]; then echo 1; else echo 0; fi

[sadman]

Что-то я, наверное, перестал понимать Zabbix

keeper:~$ time `timeout 9 sleep 10`

real    0m9.002s
user    0m0.000s
sys     0m0.000s

Т.е. никакой разницы между блокирующим вызовом через timeout и блокирующим вызовом без timeout я пока не наблюдаю. Ладно бы всё это дело отфоркивалось в отдельный тред, но тут я совершенного этого не наблюдаю. Стало быть, будучи активным айтемом, данный вызов имеет все шансы прибить все последующие активные проверки, которые по расписанию должны будут запуститься в течении 10 сек после вызова timeout.

[max.ch.88]

"userparameter который тормозит и периодически отваливается по таймауту (например выполнение lsof), начинают страдать и остальные айтемы: например на графиках свободного дискового места появляются провалы" вот какую проблему решает вызов системных команд через timeout. Когда zabbix-сервер не дожидается от хоста нового значения любого из item'ов хоста за указанный в своём конфиге timeout, сервер пишет в лог событие network error и откладывает хост в сторону минимум на минуту.
https://www.zabbix.com/documentation...unreachability
Чтобы хост не отваливался по таймауту, следует ограничить время на item(userparameter). Я сделал это с помощью вызова timeout.
Конечно, если нужно получить данные от тупенького api, который в принципе за 30 секунд не успевает, то это через crontab и zabbix_sender.

[sadman]

Ну, вобщем, что-то мы спорим не о том.

Активные проверки выполняются в один поток. Если одна из них выполняется достаточно долго, то запуски всех остальных, должные произойти в то же время, будут пропущены. До тех пор, пока Вы запускаете активную проверку каким угодно, но блокирующим способом, проблема принципиально не будет решаться, но может быть замаскирована. Единственный логично выглядящий выход - произвести запуск максимально быстро, снизив вероятность перекрытия временем выполнения текущей проверки момента запуска следующей. Т.е. отфоркнуть процесс с расчётом на то, что он сам вернёт результат в Zabbix server.

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

[aleksandr.lesovoy]

Дело в том, что данная проблема наблюдается у пассивных проверок.

[max.ch.88]

Есть описание от разработчика о таком поведении агента в активном режиме?

[sadman]

Ну, вот, к примеру.

https://www.zabbix.com/forum/in-russian/45335-%D0%9F%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D0%BD%D1%8B%D0%B5-%D0%B0%D0%BA%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B5-%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA%D0%B8-%D0%B8-%D1%80%D0%BE%D1%81%D1%82-%D0%BE%D1%87%D0%B5%D1%80?p=267910#post267910

glebs ivanovskis из команды Zabbix, как я помню.

Так же, подтверждение или опровержение можно получить из исходных текстов Zabbix agent.