Тюнинг производительности Zabbix02.07.2024 06:30

Когда пора тюнить Zabbix

Когда кажется, что Zabbix может работать быстрее — вам не кажется. Видимые проблемы производительности могут проявиться в следующих местах:

• Очередь Zabbix имеет очень много отложенных элементов данных (см. Administration → Queue)

• Частые разрывы на графиках, отсутствие данных по некоторым элементам

• Ложные срабатывания триггеров типа nodata ()

• Медленная работа веб-интерфейса

• Отсутствие событий или множество событий

• Подозрительные сообщения в логах

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

Что будем тюнить в Zabbix

Сразу начнем с того, куда нужно смотреть для понимания точек оптимизации:

• количество элементов данных и интервал их сбора

• типы информации и элементов данных

• количество триггеров и их сложность

• настройки housekeeper и размер базы данных

• настройки низкоуровневого обнаружения

• количество пользователей, работающих с веб-интерфейсом Zabbix

Разберемся как меняется нагрузка в с разным количеством узлов и элементов данных. Чтобы не усложнять примем интервал сбора данных за константу. Давайте посмотрим на пример в случае 60 элементов данных на хост и интервале сбора 1 раз в минуту:

А вот как будет выглядеть картина в случае 300 элементов данных на хост и интервале сбора 1 раз в минуту:

Обратите внимание как изменится количество новых значений в секунду (NVPS), если изменить, например, интервал сбора или количество элементов данных.

Следующее место куда нужно посмотреть — типы информации. Numeric с точки зрения хранения и работы более эффективен, чем String. Обращаем внимание на то, что по большей части вы можете избавиться от значений типа String, преобразовав их в числовые значения на этапе предобработки. Чтобы добавить человекочитаемости — используйте Value Mapping. Числовые значения еще хороши тем, что Zabbix рассчитывает их них тренды для оптимального хранения на долгой дистанции.

Посмотрим на типы элементов данных глобально: активные и пассивные. С точки зрения эффективности активный тип сбора более предпочтителен. Все просто: при пассивном формате сбора поллеры Zabbix-сервера или прокси вынуждены ждать получения данных. Если что-то где-то медленно отдает данные — будут медленнее собираться и остальные элементы данных. Не спорим, что в 7 версии Zabbix появились асинхронные поллеры, но тем не менее активный формат работает быстрее. В идеале вынесите весь сбор данных на прокси.

Количество триггеров и их сложность играет немаловажную роль в производительности. Чтобы понять где тут оптимизация, давайте посмотрим на две функции расчета триггеров: avg и trendavg.

Начнем с avg. Чтобы ускорить вычисление выражений триггеров, вычисляемых элементов и некоторых макросов, в Zabbix есть опция кэширования значений (она же value vache). Этот кэш используется для доступа к историческим данным вместо SQL-запросов к БД. Если исторические значения отсутствуют в кэше, недостающие значения запрашиваются из БД, и кэш соответствующим образом обновляется. Очевидно, что если у вас много вычисляемых штук, то и кэш нужно держать большим. В конфиге Zabbix-сервера есть параметр ValueCacheSize (по умолчанию он 8Мб, задавать можете от 128K до 64G).

Значения элементов остаются в Value Cache до тех пор, пока:

• элемент удаляется (кэшированные значения удаляются после следующей синхронизации конфигурации)

• значение элемента находится за пределами диапазона времени или количества, указанного в выражении триггера/вычисляемого элемента (кэшированное значение удаляется при получении нового значения)

• диапазон времени или счетчика, указанный в выражении триггера/вычисляемого элемента, изменяется так, что для расчета требуется меньше данных (ненужные кэшированные значения удаляются через 24 часа).

А теперь перейдем к trendavg. Если value vache используется для расчетов по кратковременным периодам, то trend function cache для вычислений за значительно более длительные интервалы времени. С точки зрения накладных расходом вычисления по трендам менее ресурсоемкие, но и менее точные, т.к. для расчетов используются часовые значения вычисленных трендов.

Этот вид кэша управляется параметром Zabbix-сервера TrendFunctionCacheSize (по умолчанию он 4Мб, задавать можете от 128K до 2G).

Вывод: в каждой ситуации используйте правильный тип функции.

Настройки housekeeper и размер базы данных — следующий пункт на нашем пути. Housekeeper — это инструмент, который подчищает устаревшие данные. Если это делать штатными средствами Zabbix (SQL-запросами) да ещё со стандартными настойками (1 раз в час), будете регулярно получать нагрузку на БД. Точка для оптимизации — настройка партиционирования в MySQL и использование TimescaleDB для PostgreSQL. В первом случае удалять партиции, во втором чанки и будем вам счастье.

Никак не можем не напомнить про настройки троттлинга, что позволит не записывать в Zabbix повторяющиеся значения. Это те самые шаги препроцессинга, которые Discard unchanged и Discard unchanged with heartbeat. А ещё есть Custom interval и Scheduled interval, чтобы не собирать данные, когда они не нужны.

Подход «кто не спрятался — я не виноват» не очень эффективен относительно низкоуровневого обнаружения. Ключевая мысль — чем реже, тем лучше. Проведите инвентаризацию самых распространенных шаблонов и проверьте так ли нужно проверять наличие новых объектов с той частотой, что настроена сейчас.

Само количество пользователей мы затюнить не сможем, поэтому просто подстроим конфигурацию Zabbix под требуемую нагрузку. Ключевое — количество подключений к БД.

Инструменты для диагностики

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

• Использовать утилиты top, ntop, iostat, vmstat, sar

• Посмотреть в веб-интерфейсе Zabbix на метрики утилизации процессов в шаблонах Template App Zabbix Server, Template App Zabbix Proxy, Template App Zabbix Agent (наподобие процессов Alerter, Configuration syncer, DB watchdog, discoverer, escalator, history syncer, http poller, housekeeper, icmp pinger, ipmi poller, poller, trapper, и других)

• Посмотреть в веб-интерфейсе Zabbix на метрики утилизации кэшэй (history write cache, value cache, trend write cache, vmware cache и других)

• Использовать strace или посмотреть в логе, предварительно увеличив уровень логирования

• Проверить при помощи ps aux | grep zabbix_server

• Установить LogSlowQueries=3000 и посмотреть на возможные проблемы с базой данных (grep slow /var/log/zabbix/zabbix_server.log)

• Включить режим Debug для пользователя в веб-интефейсе Zabbix

• Проверить производительность базы данных при помощи innotop или pg_top

Мы подготовили несколько примеров для понимания плохой ситуации и хорошей.

Пример неприятной ситуации с очередями, но не критичной:

Пример хорошей ситуации с очередями:

Пример вывода команды ps ax | grep sync в проблемной ситуации:

# 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]

Пример вывода команды ps ax | grep sync когда всё хорошо:

# 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]

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

******************** 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

Теперь посмотрим на момент проблемы с веб-сервером:

******************** 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: 0.960905
Total SQL time: 0.749027
SQL count: 5636 (selects: 4065 | executes: 1571)
Peak memory usage: 180.5M
Memory limit: 2G

Какие можно сделать выводы

В статье мы постарались разобрать наиболее эффективные точки для оптимизации производительности Zabbix. Их больше, но именно на эти стоить обратить внимание в первую очередь. Надеемся, что статья была полезна и помогла посмотреть на вашу инсталляцию под другим углом. Большое спасибо за внимание!

© Habrahabr.ru