Тюнинг производительности Zabbix 7.0 LTS

"В этой статье рассказываю о подходах к тюнингу производительности Zabbix

Александр Романюк

автор, инженер-проектировщик систем мониторинга

Тюнинг производительности — обязательная часть работы администратора Zabbix. При росте количества узлов, количества собираемых элементов данных и снижению интервалов их сбора резко возрастает шанс столкнуться с бутылочными горлышками в производительности. Ключевые метрики, которые напрямую влияют на производительность — количество узлов (разумеется, с наполняемыми элементами данных) и количество новых значений в секунду. Чем их больше и чем меньше интервал сбора данных — тем больше нагрузка на инсталляцию Zabbix в целом. При этом, элементы данных типа Zabbix Trapper и SNMP-трап особого вклада в нагрузку не вносят.

Если быть точнее, то на нагрузку влияют:

типы элементов данных
количество триггеров и их сложность
настройки housekeeper и размер базы данных
количество пользователей, работающих с веб-интерфейсом Zabbix

Давайте посмотрим на пример в случае 60 элементов данных на хост и интервале сбора 1 раз в минуту:

И на пример в случае 300 элементов данных на хост и интервале сбора 1 раз в минуту:

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

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

Видимые проблемы производительности могут провиться в следующих местах:

Очередь Zabbix имеет очень много отложенных элементов данных (см. Administration -> Queue)
Частые разрывы на графиках, отсутствие данных по некоторым элементам
Ложные срабатывания триггеров типа nodata()
Медленная работа веб-интерфейса
Отсутствие событий или множество событий

Так выглядит представление с очередями, когда какие-то значения не пришли вовремя:

И так же оно выглядит, когда все совершенно работает:

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

Как идентифицировать проблему

Есть несколько способов провести первичную диагностику:

Использовать утилиты top, ntop, iostat, vmstat, sar
Посмотреть в веб-интерфейсе Zabbix
Использовать strace или посмотреть в логе, предварительно увеличив уровень логирования
Проверить при помощи ps aux | grep zabbix_server


# ps ax | grep sync
zabbix_server: history syncer #1 [synced 2405 items in 0.458134 sec, syncing history]
zabbix_server: history syncer #2 [synced 31 items in 0.090514 sec, idle 4 sec]
zabbix_server: history syncer #3 [synced 0 items in 0.000018 sec, idle 4 sec]
zabbix_server: history syncer #4 [synced 0 items in 0.000009 sec, syncing history]

В момент проблемы увидите примерно следующее:


# ps ax | grep sync
history syncer #1 [synced 1020 items in 311.198752 sec, syncing history]
history syncer #2 [synced 915 items in 311.177799 sec, syncing history]
history syncer #3 [synced 3401 items in 311.936376 sec, syncing history]
history syncer #4 [synced 1194 items in 311.280719 sec, syncing history]

Куда еще можно посмотреть:

Внутренняя проверка zabbix[wcache, values, all]
Внутренняя проверка zabbix[queue,1m] — очередь данных с задержкой в 1 минуту
Проверить утилизацию процессов Alerter, Configuration syncer, DB watchdog, discoverer, escalator, history syncer, http poller, housekeeper, icmp pinger, ipmi poller, poller, trapper, и других
Проверить утилизацию кэшей history write cache, value cache, trend write cache, vmware cache и других
Посмотреть последние данные в шаблонах Template App Zabbix Server, Template App Zabbix Proxy, Template App Zabbix Agent
Установить LogSlowQueries=3000 и посмотреть на возможные проблемы с базой данных (grep slow /var/log/zabbix/zabbix_server.log)
Включить режим Debug для пользователя в веб-интефейсе Zabbix
Проверить производительность базы данных при помощи innotop или pg_top

После подключения режима Debug для своего пользователя можно увидеть, что у вас все хорошо с базой данных и веб-сервером:


******************** Script profiler ********************
Total time: 0.960905
Total SQL time: 0.749027
SQL count: 5636 (selects: 4065 | executes: 1571)
Peak memory usage: 180.5M
Memory limit: 2G

А если что-то не так с веб-сервером будет такая картина:


******************** Script profiler ********************
Total time: 10.960905
Total SQL time: 0.749027
SQL count: 5636 (selects: 4065 | executes: 1571)
Peak memory usage: 180.5M
Memory limit: 2G

Если что-то не то с базой данных будет так:


******************** Script profiler ********************
Total time: 10.960905
Total SQL time: 10.749027
SQL count: 5636 (selects: 4065 | executes: 1571)
Peak memory usage: 180.5M
Memory limit: 2G

Что можно затюнить

Первое и самое очевидное — увеличить количество процессов Zabbix. Это в случае, если вы обнаружили, что какие-то из них уходят в полку. Если такого не наблюдается — лишние процессы плодить не нужно. Ниже просто для примера:


StartPollers=80
StartPingers=10
StartPollersUnreachable=80
StartIPMIPollers=10
StartTrappers=20
StartDBSyncers=6

Если обнаружили проблемы с базой данных, можно затюнить и её. Пример для InnoDB ниже. Важно также отключить Query history, который может вносить знатную нагрузку на производительность базы.


innodb_file_per_table = 1
innodb_buffer_pool_size=<large> (~75% от общего объема RAM)
innodb_buffer_pool_instances = 8
innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
innodb_log_file_size = 256M

Если увидели, что есть проблема с производительностью веб-сервера, затюньте и его. Если это Apache, желательно переехать на Nginx.

Что ещё можно улучшить

Напоследок, предложу еще несколько способов улучшений:

подключить партиционирование для MySQL, а для PostgreSQL использовать TimescaleDB
разнести компоненты Zabbix на отдельные серверы
весь сбор данных вынести на прокси-серверы

Надеюсь, что статья была вам полезна. Некоторые из пунктов могут показаться очевидными, однако, об этом чаще всего как раз и забывают. Производительного вам Zabbix!

Что дальше

Приглашаем наши тренинги по Zabbix, OpenSearch, ElasticSearch

Максимум знаний за короткое время

Посмотреть расписание