Недавно стало очевидно, что наш заббикс не справляется с нагрузкой. Появились частые ложные срабатывания, в графиках появились провалы. Причина оказалась простой, очередь в 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. По результатам мы обязательно поделимся с вами, как мы это делали и какие результаты получили.
