Ускорение работы фронтенда Zabbix при мониторинге 20 000 хостов.

[bjornskau]

Добрый день уважаемые коллеги!
Стоит задача мониторинга приблизительно 20к хостов. Если быть точным хосты: 18454, элементы данных 20889651 , триггеры - 964722 версия Zabbix 3.2.11. Архитектура решения следующая: СУБД развернута на двух узлах
MariaDB Galera Cluster 10. Подключение к ним происходит через HAProxy в свою очередь развернутого на кластере Pacemaker в качеств еразделяемого ресурса, практическая роль которого - фейловер прокси. Фронтенд развернут в качестве разделяемого Apache там же где и HAPRoxy. Вся инфраструктура живет в виртуальных машинах Hyper-V 2016.
Фронтенд работает крайне медленно. Раздел Мониторинг->Графики /Триггеры открывается по 15-20 минут. Очередь элементов данных выглядит как на картинке.
В чем тут может быть проблема?.. Может кто поделиться опытом аналогичных развертываний?

Конфигурация ВМ:
СУБД:
16 CPU
72GB RAM
300 GB статические VHD.

HAProxy + Frontend:
8 CPU
16GB RAM
50 GB динамический VHD.
Конфиг httpd и папка с фронтендом (/usr/share/zabbix) синхронизируется между узлами через GlusterFS, используется XCache.

Zabbix Сервер:
12 CPU
32GB RAM
50 GB динамический VHD.

Конфиг mysql (идентичен на обоих узлах):

[client-server]

[mysqld]
general_log_file = /var/log/mysqld.log
general_log = 1
log-error = /var/log/mysqld.error.log
wsrep_on=ON
wsrep_node_name=<name>
wsrep_node_address="10.xx.xx.xx"
wsrep_provider=/usr/lib64/galera/libgalera_smm.so
wsrep_provider_options="gcache.size=10G;gcache.rec over=yes"
wsrep_cluster_name="zabbix"
wsrep_cluster_address="gcomm://10.xx.xx.xx,10.xx.xx.xx"
wsrep_sst_method=rsync
wsrep_slave_threads=32

max_connections=3000
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
user=mysql
binlog_format=ROW
default_storage_engine=innodb
innodb_autoinc_lock_mode=2
innodb_flush_log_at_trx_commit=0
innodb_buffer_pool_size=49152M
innodb_buffer_pool_instance=64
innodb_old_blocks_time=1000
query_cache_size = 32M
innodb_file_per_table = 1
sync_binlog=0
optimizer_switch = 'index_condition_pushdown=off'

slow_query_log = 1
slow_query_log_file = /var/lib/mysql/slow_queries.log
long_query_time = 0.05
log-queries-not-using-indexes = 1
max_allowed_packet=64M
character_set_server=utf8
collation-server=utf8_bin
init_connect="SET NAMES utf8 collate utf8_bin"

[mysql_safe]
log-error = /var/log/mysqld.error.log
pid-file=/var/run/mysqld/mysqld.pid

!includedir /etc/my.cnf.d

Конфиг HAProxy:
global
log 127.0.0.1 local0 notice
user haproxy
group haproxy
defaults
log global
retries 2
timeout connect 5000
timeout server 480m
timeout client 480m

listen mysql-cluster
bind 10.xx.xx.xx:3306
mode tcp
option httpchk
balance leastconn
default-server port 50005 inter 5000 rise 3 fall 2 slowstart 60s maxconn 1024 maxqueue 512 weight 100
server zabbixdb01 10.xx.xx.xx:3306 check backup
server zabbixdb02 10.xx.xx.xx:3306 check

Конфиг Zabbix Сервера:

LogFile=/var/log/zabbix/zabbix_server.log
LogFileSize=0
DebugLevel=3
PidFile=/var/run/zabbix/zabbix_server.pid
DBHost=10.xx.xx.xx
DBName=zabbix
DBUser=zabbix
DBPassword=zabbix
DBPort=3306
StartPollers=100
StartPollersUnreachable=100
StartTrappers=300
StartDiscoverers=250
StartEscalators=10
SNMPTrapperFile=/var/log/snmptrap/snmptrap.log
ListenIP=0.0.0.0
HousekeepingFrequency=1
MaxHousekeeperDelete=100000
CacheSize=8G
CacheUpdateFrequency=120
StartDBSyncers=50
HistoryCacheSize=512M
HistoryIndexCacheSize=512M
TrendCacheSize=512M
ValueCacheSize=1G
Timeout=4
AlertScriptsPath=/usr/lib/zabbix/alertscripts
ExternalScripts=/usr/lib/zabbix/externalscripts
LogSlowQueries=0

[astrix89]

есть инсталяция с 20792 хостов, 4048827 метрик, 1821013 триггеров, ~15k nvps, проблема аналогичная, правда все метрики снимаются через 8 прокси серверов(хотя это не столь значимо).
перемещение базы в раздел в оперативной памяти на ситуацию не влияет.

[bjornskau]

есть инсталяция с 20792 хостов, 4048827 метрик, 1821013 триггеров, ~15k nvps, проблема аналогичная, правда все метрики снимаются через 8 прокси серверов(хотя это не столь значимо).
перемещение базы в раздел в оперативной памяти на ситуацию не влияет.

Если не секрет, можете поделиться архитектурой? И есть ли идеи что именно вызывает такие тормоза фронта?

По ссылке на гугл на всякий случай выдержка из slow queries log:

https://drive.google.com/file/d/1kN4giaFLsP1X2myNDvFXooZsQQXFP5MJ/view?usp=sharing

[Viks]

Добрый вам всем,
скажу по опыту и вставлю своих 5 копеек.

Ой, тут я вижу много проблем, да именно проблем а не косяков или багов,
одна из самих существенных это неправильный выбор элементов и архитектуры, данная связка компонентов не подходит для таких объёмов, а то что правильно то неразвёрнутое и несконфигурено в нужном образе.

У меня недавно надо било опять сконструировать и поднимать большую мониторинг ферму и подключать туда несколько точек по миру, "зная всю глубину всех глубин", первым делом я вычеркнул из списка любую имплементацию MYSQL, это тут самая большая проблема, а то что это в любых DOCs как самая простая дБ это назначит что ee можно использовать в любых масштабах, да нет жe можно использовать но потом вот появляются во такие вот записи в форумах, тут конечно разработчики будут оппонировать, но не стоит, можем за кофе в другом месте об этом побеседовать.
Значит по делу,
тут я невижу Load Balancing не для DB, таки и не для Frontend, дальше я боюсь даже спросить сколько записей находится внутри HISTORY and TREND таблес and file size on disk, не ну небоюс просто знаю что д@^&я.

Скажу так, АН-2 можно красить в цвета истребителя МИГ-29, но из-за этого он не будет летать как истребитель,

надо в корне менять архитектуру, я очень тепло рекомендую переехать на PostgreSQL;

дальше отказаться от ACTIVE-ACTIVE Databases (любых - это самое страшное по перформанце что может только бить, детали почему я шас пропускаю, это другой топик), и перейти на Master-Slave-Slave Databases;
я подозреваю что переехать на PostgreSQL сразу не получится, люди будут сопротивляться (пока сами не погуляют по полю с граблями и не отобьют сами себе весь лоб), значит будут пробовать шото чинит в этой имплементации, ну ладно, мои рекомендации поэтому такие:

1. в USER PROFILE всем USERS убрать “Refresh” time на минимум "2 мин", люди любят там ставить 30 сек, так как если кто-то у себя в компе в нескольких tabs открыл какой-то screen с time scale 1 дай, а таких screens несколько, и таких чуваков тоже несколько, и они оставили комп и ушли дамой или обедать, то всё это время идёт очень большой и ненужный оверлоад на Zabbix Web server + DB;
   тут вообще то надо зделать запрос девелоперам переделать и ограничить это и жёстко контролировать только с разрешение Админов;
2. зделать UPGRADE на Zabbix 3.4.х, хотя пока соберётесь будет уже 4.0.х;
3. "СУБД развернута на двух узлах MariaDB Galera Cluster 10" - это по определению неправильно, 2 машины нельзя никак, минимум это 3 машины;
4. • а) дальше "MariaDB Galera Cluster" убираем, и оставляем Master-Slave-Slave можете оставить на MariaDB (Pacemaker etc все делала конечно тоже) но между DB и Zabbix (SRV and WEB) ставим посередине "MariaDB MaxScale" штоби зделать horizontal scale на SELECT;
   • б) если не захотите ставить "MariaDB MaxScale" и не будите убирать "Galera Cluster", то надо переделать " "Galera Cluster" как полноценный ACTIVE-ACTIVE-ACTIVE, а именно используя "FLOATING-IP" которую будут иметь все 3 nodes одновременно, и на которую будут настроены Zabbix Сервер и Веб морда, так будет распределятся нагрузка на несколько ДБ серверов одновременно, это немножко ускорит, но основные проблемы остаются:
     • где практически невозможно зделать грамотный backup, потому что на долго будет LOCK на TABLES и не только в одном ДБ сервере а во всём CLUSTERE одновременно, из за чего мониторинг проста остановится и станет бесполезным на долго, на час а то и 2 и 3, правда можно замутить backup с параметрами штоби наделал LOCK но там другие проблемы, штоби этого избежать лучше всего подцепить одну СЛАВЕ ДБ и от нею забирать backup;
     • ну а OPTIMIZE TABLE and/or ALTER TABLE с этом вообще страшно, от этого не избежать, если запустить, то тоже всё накроется медным тазом, вот и одно из преимуществ PostgreSQL с его autovakuum;
5. обязательно зделать “Database Partitioning” это существенно поднимет перформанце и частично по решает приведшие проблемы, а также решит HouseKeeping проблемы, которые у вас должны бить большие;
6. в вашей ситуации подозреваю что стоит активизировать ElecticSearch функционал, тут разработчики может бить что-то скажут, но по теории выглядит как полезная и очень нужная штука;
7. переделать Zabbix Server на Active-Passive cluster;
8. всю вашу инфраструктуру разбить так сказать на несколько секторов и каждый сектор штоби работал через свой Zabbix-Proxy (каждый притом Active-Passive инсталляция), и таких Zabbix-Proxy парочек в вашем случае, например, где-то 8-10, это сильно разгрузит Zabbix сервер, и зделает вашу жизнь по легче и спокойнее, можно будет делать маинтенанце прямо по середине дня и это не будет мешать работе мониторинга;
9. переделать HAProxy на ACTIVE-ACTIVE для Frontend + checks ет (для ДБ HAProxy не нужен тут), убрать APACHE, а за ним поставить несколько машин с WebFrontend на Nginx + PHP-FPM + Memcached Cluster, и это всё очей хорошо будет снимать нагрузку на WebMordu и самое главное меньше один USER будет мешать другим;
10. “DB disks space” использовать Host Local Disk storage na SSD, и для этого НЕ использовать Shared Network storage (NFS, ISCSI, ...).

После всего этого получится хороший такой Бомбардировщик, надёжный и выносливый, какой вам шас и нужен, правда на не большие расстояния, но Истребитель тут никак не получится, особенно с MySQL на борту.

Можно также и ПМ,
если есть какие-то вопросы не для всех ушей и штоби меньше спам....

[bjornskau]

Добрый вам всем,
скажу по опыту и вставлю своих 5 копеек.

Спасибо вам. Очень полезный опыт. Уход от MySQL сейчас для нас маловероятен, а вот MaxScale Partitioning, nginx + php-fpm и Zabbix Proxy попробуем внедрить.)

[Viks]

Да не за что, пожалуйста.

Как говорится обращайтесь.