Недавно стало очевидно, что наш заббикс не справляется с нагрузкой. Появились частые ложные срабатывания, в графиках появились провалы. Причина оказалась простой, очередь в zabbix выросла до неприличных размеров и составляла порядка 2000. Было очевидное решение — увеличение инстансов, но ресурсы не позволяли сделать этого и как стало очевидно в дальнейшем это было бы плохим решением. О том как мы решили эту проблему ниже. Забегая вперед: проблема удачно решена и очередь сократилась до 30-40 в среднем.





Как видно на картинке было 3 переломных момента, собственно как и две проблемы. Вот о них подробнее:
1 проблема, это хосты которые уже давно не активны, но не удалены. Их опрос занимает время и ресурсы. Выявить их было несложно. У нас мониторятся хосты только с агентами. Все хосты у которых агент был недоступен, были помечены как проблемные. Дальше проведен анализ и удаленные хосты были удалены до конца, а для остальных исправлены правила firewall. Но оказалось не все так просто. В процессе поиска устаревших хостов было замечено несколько дублирующихся хостов. Под дублирующимися хостами мы понимаем, полностью идентичные хосты, с одним ID в базе. Причину дублирования так и не удалось выяснить, был создан баг в zabbix, но, к сожалению, реакции на момент написания статьи не последовало. А вот для поиска дублирующихся хостов был сделан запрос прямо в базу:

select host, Count(host) as Count  from hosts  group by host having count(host)>1;

Данный запрос возвращает список идентичных хостов, которых более одного.

2 проблема была из той же области. Она заключалась в большом количестве уже не актуальных items, оставшихся от старых шаблонов. Для решения этого момента, были проанализированы все items со статусом not supported и удалены лишние.

Ну и 3 финальный аккорд — это шаблон Linux. Типы проверок были настроены на использование zabbix active agent. Чем он отличается от обычных проверок хорошо описано в документации. Когда проверок очень много, они начинают потреблять ресурсы сервера. Для шаблона оперативно был изменен c zabbix agent (active) на zabbix agent.

В итоге этих трех простых действий очередь была сокращена с более чем 3 К до 30-40.

P.S.: Еще одним удобным инструментом анализа нагрузки на zabbix оказался встроенный в zabbix, анализатор времени получения данных. Посмотреть его можно: Администрирование -> Очередь. Логика простая: чем больше время получения данных, тем больше нагрузка на сервер.

В дальнейших планах есть изменение СУБД с mysql на postgresql. По результатам мы обязательно поделимся с вами, как мы это делали и какие результаты получили.

Автор: системный администратор компании Magvai69