busy poller process и недоступный сервер [расколбас zabbix-server]

[sudoRoman]

Хотелось бы сказать, что на этом busy poller process я уже съел всех собак в своей округе, но нет. Даже не сильно гуглящиеся статьи писал, как с этим бороться, но... никогда не было и вот опять)

Короче. Имеется Zabbix 5.0.27. Нагрузка для некоторых смешная, около 60-65 значений в секунду. Пять баре металлюг серверов и порядка 60 виртуалок. Не буду подробно разукрашивать все случаи, но суть одна. Когда на сети начинаются проблемы и из-за этого отваливается куча (кучка) метрик, то busy poller process начинает уходить выше и выше, доходит до 100%. Чтобы понимать, что это проблемы на сети, у меня вот такой модный график уже есть давно.



Так вот в итоге недоступна может быть всего одна машина, а расколбас начинает затрагивать всех и вся, zabbix-сервер встаёт раком, куча алертов, в общем картина неприятная. Суть в том, что живые сервера, которые могут слать нормально метрики, перестают мониторится, заббикс не успевает по ним отрабатывать, что порождает новые алерты, нагрузку на pollers и дальнейший уход zabbix-сервера в себя.

Что-то с этим придумали в заббиксе или кто как с этим борется? Увеличение кол-ва pollers на старте в конфиге заббикса проблему не решает. Разве что может отсрочить уход в аут заббикс сервера или, если проблемы на сети быстро закончатся (3-5 минут), то шторм пройдёт мимо. Но и увеличение этих poller до любого значения тоже не есть хорошо.

В спокойном состоянии картина вот такая по занятости процессов:



Буду раз обсудить любой опыт в этом вопросе. Может кому будет интересно как я пришёл к мониторингу конкретных событий в логи, показанных на первом графике - тыц.

[teddy]

Я бы вычислил какие из метрик начинают "зависать" при проблемах по сети - скорее всего это определенный тип метрик и перевести их в режим Активного агента. насколько я понимаю, тут проблема в том что из-за ошибок по сети запрос некоторых метрик начинает уходить в таймаут и накапливаться в очередях И быстро забивает ресурсы сервера заббикса. А переход в режим активного агента для таких метрик - уберет первопричину. если с сетью напряг - то агент не сможет отправить метрику. но это будет проблема агента. а сервер просто не получит вовремя ожидаемое, но это уже не так страшно. Архитектурно эта проблема еще решается через заббикс-прокси, но строить прокси ради десятка пк - неоправдано.

С этой точки зрения кстати я большинство метрик, если возможно, перевожу в активный режим. После тестирования ( т.к тестировать удобнее в пассивном ). Исключение если на целевой машине и так проблема с ресурсами. помним что активный режим агента увеличивает нагрузку на сам удаленный ПК. Не так чтоб уж сильно, но прирост есть.

[Alex_UUU]

УРА!!!!!!!!!!!
Наконец-то еще у кого-то такая же проблема.

ЗЫ. Это я не злорадствую, это я к тому, что может найдем причину. Описывало и спрашивал уже несколько раз (поиском можно найти). Пока пришел к такой причине: Если просто вырубить узел - никаких проблем. Проблема возникает, если что-то случилость на сети и сервер считает, что связность пропала, а агент - что нет (или наоборот).
Лечили или перезагрузкой сервера, или №само рассосется" И рассасывалось. Но приходилось отрубать уведомления, чтобы не спамили
У меня основная масса ЭД - активные. Даже сделал через прокси. Пофигу.

[teddy]

Ну у меня не рассосалось само.
Но. У меня был заббикс на MySQL точнее MariaDB. Я долго тюнил БД для уменьшения нагрузки на БД, которая не успевала за потоком датчиков. С трудом добился сравнительно приемлемого уровня. но при работе хаускипера все равно была беда.
Поэтому я принял решение перенести все на Postgres.Без timescale. Я потерял накопленную историю, но на это я был готов.
И произошла таки чудо )) На тех же ресурсах у меня на Postgres все летает с нагрузкой не выше 10-15% на диск. Редкие датчики, которые застревали как я описал выше - перевел на Активный режим и сейчас у меня нет проблем. При переходе я поднял версию заббикса с 5.что-то до 6.2. но не думаю что именно это дало то самое чудо. Сегодня у меня поток данных ~600 значений в секунду - метрика самого заббикса. Я понимаю что это на самом деле не так уж и много, но судя по загрузке я сейчас имею запас где то в два раза по потоку данных.
Дальше либо наращивать ресурсы либо строить прокси для сглаживания. Кстати на мускуле поток был того же уровня но система категорически не успевала.
Выводы делайте сами.

[teddy]

да. еще один момент. я последнее время слишком часто наблюдаю что сервер пишет что поетрял связь с агентом. хотя с сетью все ок, и агент запущен. я решил это так - обвесил этот триггер рюшечками - action который, скриптом запущенным на сервере ( это важно, т.к скрипт на клиенте не запустится - связи с агентом же нет ), перезапускает агента на клиенте. для linux по ssh, для windows средствами /usr/bin/net rpc service.
решение не самое лучшее но работает.