Когда я только внедрял мониторинг на Zabbix+Grafana остро стоял вопрос о требуемой производительности серверов мониторинга. К сожалению информации в интернетах на эту тему не много. Сейчас я более-менее уже могу ответить на этот вопрос, о чем поведу Вам.

Поскольку обычно такие вопросы возникают только в начале пути, то для масштаба возьмем небольшую систему: 50 узлов на мониторинге из из которых 25 Linux сервера с Zabbix-агентом а еще 25, это всевозможные IPMI и метрики хостов виртуализации без агентов, эдакий типичный мини зоопарк. Сама система мониторинга у нас будет для примера состоять из одного Zabbix-сервера и одного Zabbix-прокси.

Прикидки можно почитать под катком.

В связке Zabbix-сервер + Grafana-сервер получается примерно следующее:

• По процессорам Zabbix сам по себе совсем не требователен, в любой конфигурации(с прокси или без) он потребляет не более 30% одного ядра. На редких пиках, которые даже сложно заметить, Zabbix может очень непродолжительно сжирать целиком все ядро, видимо это процедуры самообслуживания. Ситуация кардинально меняется при добавлении к Zabbix’у Grafan’ы, отображение полутра-десятка графиков на 7 дней, и десятка индикаторов сжирает целиковое ядро, при этом система начинает стучать ложкой по столу и требовать еще ядра. А при добавлении второго ядра система сжирает и его без остатка. Можно добавить еще 1-2 ядра, но большого профита это уже не даст. Делаем вывод – 2-3 ядра, это оптимально.
• По памяти – Тут все зависит от размера БД в большей степени. Заббиксу без графаны при должной настройке БД, за глаза хватит 256Мб на InnoDB Pool Buffer и 200Мб на прочие накладные расходы, при этом Zabbix не будет испытывать никаких проблем. При добавлении Grafan’ы аппетиты серьезно растут, системе нужен уже куда более значительный InnoDB Pool Buffer, поскольку Grafan’а очень активно поднимает с диска тонны данных из базы Zabbix’а и буфер очень спасает. В таких конфигурациях на буфер, кеши и треды БД я отдаю где-то 2.3Гб памяти. С учетом прочих накладных расходов, оптимально в целом на всю систему давать 4Гб памяти.
• По дискам – Касательно IOPS’ов ситуация аналогичная, Zabbix’у много не надо, до 50-100 иопсов будет достаточно, но при наличии Grafan’ы уже неплохо иметь более-менее полноценный NVMe диск, или хотя-бы SSD. На обычном HDD вся эта “балалайка” беспощадно помирает при отображении даже 2-х дневного набора графиков. Что-же касается объема, рассчитывайте что указанное количество хостов на мониторинге потребит гигабайт 15-20 места, и лучше соотв. диска выделять хотя-бы 40Гб, чтоб с запасом.

Качественно отличается ситуация с Zabbix-proxy, он весьма легковесен, при 22-25 хостах потребляет менее 10% от одного ядра, пару десятков IOPS(даже не смотя на то что база в SQLite), 5Гб диска(вместе с системой и запасом) и ему за глаза хватает 512 Мб памяти. А чтоб не быть голословным, я даже приведу скриншот потребления проксика:

Но при наличии метрик веб-мониторинга, как я и писал ранее, он критичен к задержке до наблюдаемого хоста. Так-что на это стоит обратить особое внимание.

Значит из всего этого делаем вывод что самое зло, это Grafana. Ей можно слегка помочь, если пустить часть запросов в обход Zabbix API, ибо в свежих плагинах заббикса появился функционал прямых запросов к БД. Для этого создаем в Grafan’е новый дата-сорс прямиком указывающий на Zabbix DB:

Обратите внимание, что подключение желательно делать через сокет, а указанному юзеру кроме команды SELECT ничего разрешать нельзя.

Потом в Zabbix-плагине подключаем этот дата-сорс.

Но спешу Вас огорчить, графана от этого не станет намного менее бруттальной , она так-же продолжит сжирать все что ей дают, хотя безусловно ей при этих настройках будет полегче, это замеченный мною факт.

Обратите внимание, что включен “Trends” и установлен Range на 7 дней, это позволяет использовать усредненные данные трендов Zabbix’а а не истории, при отображении больших временных шкал. Да из за этого графики длительностью более 7-ми дней перестают быть столь детальными, но зато они отрисовываются мгновенно и не убивают систему.

Само ядро InnoDB можно настроить примерно так:

[mysqld]
skip-external-locking
skip-name-resolve
performance_schema = off

sync_binlog=0

default-storage-engine = innodb
innodb_file_per_table

innodb_buffer_pool_size = 1500M

query_cache_size=0
query_cache_type=0

query_cache_size    = 10M
join_buffer_size    = 1M
tmp_table_size      = 24M
max_heap_table_size = 24M

table_open_cache=4000

innodb_log_file_size=64M

innodb_flush_log_at_trx_commit = 2
innodb_flush_method = O_DIRECT
transaction-isolation = READ-COMMITTED

Вот пример потребления Zabbix+Grafana. По пикам нагрузки на проц, можно легко понять когда открывался интерфейс Графаны

Только благодаря лимиту на запрос истории в 7 дней, и памяти выделенной для БД  удается более-менее избежать массивных запросов к диску(как на скриншоте выше). Но это я-бы сказал… баланс на грани. По этому на NVMe тут скупится не стоит, если Графане нужен будет диск, обычные HDD она убивает мгновенно, в этом я убедился уже не раз. Как альтернатива диску – монструозные объемы памяти, чтобы гарантированно вся БД в нее влезла, хотя этот вариант мне не нравится. Тут приходится искать некоторый баланс…

Итого, рекомендуемые сервера, которые мне кажутся более-менее сбалансированными для конфигурации с 50-ю наблюдаемыми хостами:

• Zabbix+Grafana – Hetzner CX21 (€ 5.88 в месяц) 2 vCPU, 4 ГБ RAM, 40 ГБ NVMe(хотя я там не увидел реальных NVMe скорее SSD-шки да еще и с приличной конкуренцией, но это совсем другая история )
• Zabbix-proxy – Selectel Cloud (671руб. в месяц) 1 vCPU, 512 МБ RAM, 5 ГБ Local Disk, 1 IPv4.