Zabbix: производительность Oleg Ivanivskyi Zabbix тренер / инженер технической поддержки Москва 2018

Типовые проблемы Подходы к решению Инструменты для поиска корневой причины 2 из 38

Размер Zabbix инсталляции имеет значение: 2GB RAM / 50GB Zabbix DB / 200 устройств 256GB RAM / 10 TB Zabbix DB / 15000 устройств Небольшая (Н) – Средняя (С) – Большая (Б) <500 – 501-8000 – >8001 NVPS 3 из 38

Типовые вопросы: Не настроен мониторинг Zabbix сервера Конфигурационные файлы не оптимизированы Не используется Zabbix документация Размер БД и частота опроса 4 из 38

Пример №1 Вопрос: Zabbix сервер не запускается Причина: на сервере нет свободного места Вопрос: "last(10m)" генерирует много проблем Причина: "last(10m)" – всегда последнее значение (а не значения за последних 10 минут) Вопрос: Я использую функцию "nodata" и "multiple problem event generation" параметр включен в триггере. Мы получаем дублирующие проблемы для каждого инцидента Причина: НЕ используйте "multiple problem event generation" вместе с "nodata" Вопрос: БД растет очень быстро после обновления с 2.4 на 3.0 Причина: housekeeper выключен по умолчанию при обновление на 3.0 5 из 38

Вопрос: загрузка процесса housekeeper больше 75% Пример №2 5 из 38

Вопрос: загрузка процесса housekeeper больше 75% Размер БД Zabbix - 1.6TB Все компоненты Zabbix установлены на одном сервере с 4CPU и 8GB RAM MySQL использует значения по умолчанию для всех параметров (например, innodb_buffer_pool_size = 128MB) Пример №2 6 из 38

Типовые вопросы: Неоптимальные настройки Zabbix Триггера из скачанного шаблона создают десятки тысяч событий 7 из 38

Типовые вопросы: Неоптимальные настройки Zabbix Триггера из скачанного шаблона создают десятки тысяч событий "Мусор" в Zabbix 45 000 устройств оказались не нужными 7 из 38

Типовые вопросы: Неоптимальные настройки Zabbix Триггера из скачанного шаблона создают десятки тысяч событий "Мусор" в Zabbix 45 000 устройств оказались не нужными Плохая оптимизация Настройки оптимизировались используя статьи из интернета 7 из 38

Типовые вопросы: Неоптимальные настройки Zabbix Триггера из скачанного шаблона создают десятки тысяч событий "Мусор" в Zabbix 45 000 устройств оказались не нужными Плохая оптимизация Настройки оптимизировались используя статьи из интернета Housekeeper Использование housekeeper для очистки большой БД 7 из 38

Во время проблемы 8 из 38

Во время проблемы 9 из 38

Высокая очередь 10 из 38

Неверно Не работает Zabbix? – Перезапустите Zabbix! Высокая очередь у многих проси – пересоздайте БД прокси, измените настройки прокси и т.п. 11 из 38

Неверно Не работает Zabbix? – Перезапустите Zabbix! Высокая очередь у многих проси – пересоздайте БД прокси, измените настройки прокси и т.п. Верно Локализируйте проблему Найдите корневую причину и устраните ее 11 из 38

Локализируйте проблему Как понять какой из них является корневой причиной медленно работающего Zabbix? 12 из 38

БД: медленные запросы (LogSlowQueries=3000) Frontend: режим отладки Zabbix: "Template App Zabbix Server" (Proxy), Очередь Локализируйте проблему 13 из 38

БД # grep slow /var/log/zabbix/zabbix_server.log slow query: 9.054528 sec, "insert into events (eventid, source, object, objectid, clock... slow query: 8.501505 sec, "update hosts set lastaccess=1421211815 where hostid... slow query: 6.754405 sec, "insert into history (itemid,clock,ns,value) values... slow query: 37.949541 sec, "select i.itemid, i.hostid, h.proxy_hostid, i.type, i.data_type... slow query: 70.877295 sec, "select distinct t.triggerid, t.description, t.expression, t.error... 14 из 38

Frontend режим отладки 15 из 38

******************** 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 Frontend режим отладки 16 из 38

******************** 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 Проблема с БД Frontend режим отладки 17 из 38

******************** 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 Проблема с Web сервером Frontend режим отладки 18 из 38

Медленный Web сервер? Apache nginx Total time: 6.47 Total time: 1.02 Оптимизируйте конфигурационный файл Попробуйте nginx 19 из 38

Zabbix сервер 20 из 38

Zabbix сервер 21 из 38

Поиск корневой причины БД: медленные запросы (LogSlowQueries), SQL запросы Zabbix: "Template App Zabbix Server" (Proxy) Frontend: debug Утилиты командной строки: innotop/pg_top, atop, ps, tcpdump, debug/strace 22 из 38

innotop / pg_top Анализ в режиме реального времени для MySQL/PostgreSQL 23 из 38

atop CPU сильно загружен на Прокси 1: 550 NVPS, 2 CPU, ~10 CPU load (1min avg) Прокси 2: 1000 NVPS, 2 CPU, ~0.2 CPU load (1min avg) 24 из 38

atop Запускаем "atop" в фоновом режиме с целью записи активности процессов в файл (например, каждые 2 секунды на протяжении 5 минут): # atop -w /tmp/atop.raw 2 150 Читаем лог # atop -r /tmp/atop.raw 25 из 38

atop Уменьшить количество процессов (750 -> 500) Увеличить количество CPU

ps С помощью "ps" получаем информацию о загрузке процессов Zabbix: # ps ax | grep sync zabbix_server: history syncer #1 [synced 1845 items in 0.257111 sec, syncing history] zabbix_server: history syncer #2 [synced 24 items in 0.060314 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] 26 из 38

ps С помощью "ps" получаем информацию о загрузке процессов Zabbix: # ps ax | grep sync zabbix_server: history syncer #1 [synced 1845 items in 0.257111 sec, syncing history] zabbix_server: history syncer #2 [synced 24 items in 0.060314 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] Во время проблемы: zabbix_server: history syncer #1 [synced 1000 items in 285.198752 sec, syncing history] zabbix_server: history syncer #2 [synced 1000 items in 285.177799 sec, syncing history] zabbix_server: history syncer #3 [synced 1000 items in 284.936376 sec, syncing history] zabbix_server: history syncer #4 [synced 1000 items in 285.280719 sec, syncing history] 26 из 38

tcpdump Вопрос: загрузка процессов data sender и heartbeat резко меняется каждые несколько минут 27 из 38

Используем "tcpdump" чтобы записать коммуникацию: tcpdump -w proxy.pcap host and port 10051 Анализируем данные tcpdump 28 из 38

Нет проблемы SYN – запрос на подключение к серверу (10051) PSH – отправка данных серверу FIN – закрытие соединения tcpdump 29 из 38

Во время проблемы SYN – запрос на подключение к серверу (10051) PSH – отправка данных серверу FIN – закрытие соединения 30-90 секунд чтобы установить соединение tcpdump 30 из 38

Исходный код Zabbix В сети с высоким временем ожидания на коммуникацию между прокси и сервером уходит какое то время (например, ~250ms). Иногда, прокси не хватает пропускной способности сети чтобы отправлять все полученные значения вовремя. Попробуйте 3.4 – 4.0 Возможное обходное решение – отправка больше 1000 значений за одно подключение #define ZBX_MAX_HRECORDS 10000 Клиент: хорошие новости! Количество значений на отправку уменьшилось с нескольких миллионов до 3-х тысяч 31 из 38

SQL mysql> select max(id)-(select nextid from ids where table_name = "proxy_history" limit 1) from proxy_history; +----------------+ +----------------+ | 825 | | 16825939 | +----------------+ +----------------+ Как читать результат: Прокси отправляет до 1000 значений за одно соединение 0 - 5000 - отлично > 100 000 и растет - плохо > 100 000, но уменьшается - подождите (похоже что была проблема, но сейчас все ок и прокси отправляет данные) 32 из 38

Отладочная информация Вопрос: alerter загружен на 100 % Включаем режим отладки для нужного процесса: # zabbix_server -R log_level_increase=alerter Ищем в лог файле полезную информацию: # grep 23153 /var/log/zabbix/zabbix_server.log 33 из 38

Пример: 23153:20171229:004407.963 In zbx_popen() command:'/usr/local/share/zabbix/alertScripts/ZBX_Notific ations_1.0.sh 'ZBX' 'PROBLEM 23153:20171229:004407.964 End of zbx_popen():6 23153:20171229:004428.873 In zbx_waitpid() Отладочная информация 34 из 38

Пример: 23153:20171229:004407.963 In zbx_popen() command:'/usr/local/share/zabbix/alertScripts/ZBX_Notific ations_1.0.sh 'ZBX' 'PROBLEM 23153:20171229:004407.964 End of zbx_popen():6 23153:20171229:004428.873 In zbx_waitpid() alerter ждал 21 секунду Отладочная информация 34 из 38

strace Вопрос: alerter загружен 100 % С помощью "ps" получаем ID alerter: # ps aux | grep alerter С мощью "strace" подключаемся к процессу и пишем системные вызовы в файл: # strace -tt -s 256 -p -o debug.txt 35 из 38

strace 04:06:48.506607 alarm(0) = 28 04:06:48.506662 poll([{fd=5, events=POLLIN|POLLPRI}], 1, 0) = 0 (Timeout) 04:06:48.506697 write(5, ";\0\0\0\3update alerts set status=1,error='' where alertid=13373979", 63) = 63 04:06:48.506759 read(5, "0\0\0\1\0\1\0\2\0\0\0(Rows matched: 1 Changed: 1 Warnings: 0", 16384) = 52 04:06:48.507468 access("/usr/local/share/zabbix/alertScripts//ZBX_Notifications_1.0.sh", X_OK) = 0 04:06:48.507562 alarm(40) = 0 04:06:48.507620 pipe([6, 7]) = 0 04:06:48.507685 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f4ff677f9f0) = 8712 04:06:48.509574 close(7) = 0 04:06:48.509636 read(6, "", 4095) = 0 04:06:58.998277 — SIGCHLD (Child exited) @ 0 (0) — alerter ждет 10 секунд 36 из 38

strace Вопрос: pollers загружены на ~100 %

strace С помощью "ps" получаем ID и запускаем strace: # ps aux | grep poller # strace -tt -s 256 -p -o debug.txt 20:26:56.006121 connect(7, {sa_family=AF_INET, sin_port=htons(10050), sin_addr=inet_addr("10.10.10.10")}, 16) = 0 <0.000126> 20:26:56.006280 write(7, "users.online[onlineUsers,server-1]\n", 38) = 38 <0.000024> 20:26:56.006345 read(7, "ZBXD\1", 5) = 5 <23.254467> 20:27:19.260890 read(7, "\1\0\0\0\0\0\0\0", 8) = 8 <0.000019> 20:27:19.260963 read(7, "0", 2047) = 1 <0.000017> poller ждал 25 секунд 38 из 38

Оптимизация настроек на примере сервера БД MySQL 39 из 38

local_infile = 0 symbolic_links = 0 skip-name-resolve key_buffer_size = 32M max_allowed_packet = 128M table_open_cache = 1024 table_definition_cache = 1024 max_connections = 2000 join_buffer_size = 1M sort_buffer_size = 2M read_buffer_size = 256K read_rnd_buffer_size = 256K myisam_sort_buffer_size = 1M thread_cache_size = 512 query_cache_type = 0 open_files_limit = 65535 wait_timeout = 86400 optimizer_switch=index_condition_pushdown=off tmp_table_size = 64M max_heap_table_size = 64M large-pages Оптимизация настроек innodb_buffer_pool_size = 64G innodb_log_file_size = 4G innodb_log_buffer_size = 128M innodb_file_per_table = 1 innodb_flush_method = O_DIRECT innodb_buffer_pool_instances = 8 innodb_write_io_threads = 8 innodb_read_io_threads = 8 innodb_adaptive_flushing = 1 innodb_lock_wait_timeout = 50 innodb_flush_log_at_trx_commit = 2 innodb_io_capacity = 2000 innodb_io_capacity_max = 2500 innodb_flush_neighbors = 0 innodb_checksums = 1 innodb_doublewrite = 1 innodb_support_xa = 0 innodb_thread_concurrency = 0 innodb_purge_threads = 4 innodb_lru_scan_depth = 512 innodb_stats_on_metadata = 0 innodb_stats_sample_pages = 32 40 из 38

/etc/sysctl.d/zabbix.conf vm.swappiness = 0 vm.nr_hugepages = 26624 vm.hugetlb_shm_group = 499 kernel.shmmax = 1073741824 kernel.shmall = 13631488 /etc/fstab /dev/mapper/mysql_database /var/lib/mysql none noatime,nosuid,noexec,nodev 0 0 innodb_numa_interleave=1 в конфигурационном файле MySQL (>=5.7.9) ИЛИ "ExecStart=/usr/bin/numactl --interleave all /usr/sbin/mysqld ..." в mysqld.service (<5.7.9) echo 'noop' > /sys/block/DEVICE/queue/scheduler malloc-lib=/usr/lib64/libjemalloc.so.1 в конфигурационном файле MySQL Оптимизация настроек 41 из 38

Вопросы?

Спасибо!