Сегодня я хочу продолжить тему оптимизации производительности 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 при частых колебаниях/срабатывании триггеров.
Оптимизация параметров Zabbix-кеша.
Проверяем результаты мониторинга Zabbix самого себя с помощью внутренних проверок.
И обращаем внимание на процент использования/свободного кеша.
При необходимости увеличиваем значение параметров в конфигурационном файле Zabbix-сервера:
CacheSize
HistoryCacheSize
TrendCacheSize
HistoryTextCacheSize
ValueCacheSize
2.Оптимизация базы данных Zabbix.
Например, используется MySQL в качестве СУБД и общий размер всех innodb-таблиц базы данных zabbix равен 1,8Gb)
innodb_buffer_pool_size = 2048M
innodb_buffer_pool_instances = 2
(один пул на каждый 1GB памяти в innodb_buffer_pool_size)
innodb_log_buffer_size = 16M
innodb_flush_log_at_trx_commit = 1
(если допускается потеря данных при аварийном прекращении работы MySQL, то для оптимизации производительности рекомендуется установить значение в 0)
innodb_flush_method = O_DIRECT
innodb_file_per_table = 1
innodb_log_file_size = 256M
Произведение innodb_log_file_size(256M) и innodb_log_files_in_group (2)должно бать примерно равно ¼ значения innodb_buffer_pool_size(2048M))
innodb_io_capacity=200 (дефолтное значение)
На SSD-дисках необходимо увеличить до 2000.
Отключение кеша:
Query_cache_type =0
query_cache_size=0
3.Оптимизация фронтенда Zabbix (GUI).
1) оптимизация Web-сервера Apache
Включение поддержки сжатия т.е. установить и активировать модули mod_deflate и/или mod_gzip:
Добавить в виртуальный хост Zabbix в Apache
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/ x-javascript AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE application/xml AddOutputFilterByType DEFLATE application/xml+rss AddOutputFilterByType DEFLATE text/javascript
# Don't compress images
SetEnvIfNoCase Request_URI .(?:gif|jpe?g|png)$ no-gzip dont-vary
2) оптимизация Web-сервера Nginx
# nano /etc/nginx/nginx.conf
gzip on;
gzip_comp_level 5;
gzip_proxied any;
gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
3) включение поддержки PHP-кеширования средствами OpCache
# nano /etc/php5/mods-available/opcache.ini
; configuration for php ZendOpcache module
; priority=05
zend_extension=opcache.so
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=1000
opcache.revalidate_freq=0
opcache.fast_shutdown=1
opcache.enable_cli=1
4. Оптимизация операционной системы
Оптимизация файловой системы.
Для нагруженных Zabbix-серверов на уровне userspace (пользовательского пространства) проверить и увеличить лимит на количество открытых файлов для пользователя, под которым работает Zabbix-сервер (например для пользователя zabbix до 100000)
# su -l zabbix -s /bin/bash -c "ulimit -n" 1024
# nano /etc/security/limits.d/zabbix.conf
zabbix - nofile 100000
На уровне kernelspace (пространства ядра).
Проверить/увеличить лимит на кол-во открытых файлов
# sysctl -a | grep fs.file-max
# nano /etc/sysctl.conf
fs.file-max = 100000
# sysctl -p
Изменение политики использования SWAP.
Переменная ядра vm.swappiness, установка высоких значений будет приводить к более частому использованию SWAP-раздела/файла, в отличии от низких значений.
По умолчанию используется 60, т.е. операционная система выгружает данные при заполнении ОЗУ на 60%
# sysctl vm.swappiness
vm.swappiness = 60
Необходимо изменить до значения 5-10.
Так мы вынуждаем операционную систему использовать больше физической памяти прежде чем задействовать виртуальную память (swap-раздел/файл)
# nano /etc/sysctl.conf
vm.swappiness = 5
# sysctl –p
Два других параметра ядра должны быть оценены и, при необходимости, изменены для уменьшения тенденции свопинга. Эти значения напрямую влияют на ввод-вывод.
Эти параметры следующие:
vm.dirty_ratio
максимальный объем системной памяти, которую можно заполнить dirty pages;
vm.dirty_background_ratio
процент системной памяти, который можно заполнить dirty pages до того, как фоновые процессы pdflush/flush/kdmflush запишут их на диск;
vm.dirty_ratio = 5
vm.dirty_background_ratio = 20
Оптимизация сетевых параметров.
# sysctl -a | grep -E 'net.ipv4.tcp_max_syn_backlog|net.ipv4.tcp_rmem|net.ipv4.tcp_wmem|net.ipv4.tcp_fin_timeout|net.ipv4.tcp_keepalive_time|net.core.rmem_max|net.core.wmem_max'
5. Мониторинг состояния Zabbix.
Метрики как элементы данных для диагностики Zabbix-сервера
Метрики как элементы данных для диагностики производительности Zabbix-proxy
Метрики как элементы данных для диагностики производительности Zabbix-базы данных
1)Мониторинг медленных запросов
2)Мониторинг DELETE, INSERT, UPDATE, SELECT-запросов (для этого хорошо подходит встроенный в Zabbix шаблон Template App MySQL)
Дальнейшая оптимизация производительности Zabbix может быть связана с разделением некоторых компонентов Zabbix-сервера и Zabbix-базы данных на отдельные сервера. Например, на одном сервере размещать Zabbix-сервер и GUI, а базу данных вынести на отдельный сервер. Также для разгрузки Zabbix-сервера и мониторинга териториально распределенных сетей есть смысл устанавливать и использовать Zabbix-proxy.
1 comment:
Считается, что для мониторинга сервиса достаточно следить всего за 4-мя параметрами:
Latency. Время, которое занимает обработка запроса. Неплохо бы разделять время для корректных ответов и ошибок.
Traffic. Количество запросов, приходящих к сервису. Например, rps для http-сервисов или bandwidth для стриминга.
Errors. Запросы, обработанные с ошибками.
Saturation. Насколько заполнен сервис. Например, для диска это общий объем и занятое место.
Post a Comment
А что вы думаете по этому поводу?