Сегодня я хочу продолжить тему оптимизации производительности Zabbix. На это раз пройдемся по разделам книги «Zabbix Performance Tuning» от Luciano Alves, издательство Packt Publishing, 2015. Это материал подготовил Евгений Каменев три года тому. С тех пор ничего более подробного на эту тему я не встречал. Так что продолжим.
Zabbix - это платформа, которая состоит из трех компонентов:
1.Сервер Zabbix.
2.База данных Zabbix.
3.Фронтенд Zabbix.
Но в тему оптимизации следует включить еще два дополнительных пункта:
4.Оптимизация операционной системы Linux.
5. Мониторинг состояния Zabbix.
Далее рассмотрим каждый пункт последовательно.
1.Оптимизация Zabbix-сервера.
Использование активных Zabbix-agent проверок вместо пассивных Zabbix-agent проверок (уменьшает нагрузку на Zabbix-сервер и количество TCP-соединений).
При этом на Zabbix-агенте, возможно,есть смысл увеличить дефолтные значения параметров.
Ниже приведены дефолтные значения
BufferSend=5
BufferSize=100
На Zabbix-сервере необходимо увеличить количество процессов Zabbix-trapper, которые принимают входящие соединения активных агентов, Zabbix-sender и активных прокси.
Использование наименее дорогого с точки зрения чтения/записи базы данных типа элемента данных - (numeric(unsigned),numeric (float), character, text, log).
Каждый элемент данных записывается в отдельную таблицу history, в которой содержится разный тип и длина полей для хранения одного значения.
Использовать наименее дорогого с точки зрения нагрузки процессора триггера - (функции last(), nodata(), min(), max(), avg())
Например, функции min/max/avg сильнее нагружают процессор в отличии от функций last и nodata.
Время хранения данных в таблицах history,trends,events.
Уменьшаем время хранения истории с дефолтных 90 дней на 7 дней (при создании элемента данных)
Время хранения в таблице trends оставляем дефолтное 365 дней (при создании триггера)(если нет необходимости в просмотре информации за год,то сокращаем время хранения тенденций)
Время хранения событий, генерируемых триггерами, можно уменьшить с дефолтных 365 дней, чтобы не увеличивать размер таблицы events при частых колебаниях/срабатывании триггеров.