Zabbix увеличение оперативной памяти
Настройте используемую память zabbix для более точного и доступного использования памяти
Описание:
Доступная память: доступная память = свободная + буферы + кэшированные, т.е. 308 = 209 + 6 + 92
Используемая память: Used memory = used-buffers-cached, то есть 686 = 785-6-92
При использовании собственного шаблона Linux Template OS для zabbix для мониторинга сервера было обнаружено, что используемая память полностью заполнена. Это потому, что zabbix получает используемую память сервера через ключ vm.memory.size [used]. Но значение, полученное с помощью vm.memory.size [used] (используется 785, как показано ниже), также включает буферы и кэширование.
Буферы и кэширование также доступны серверу. Просто Linux сам использует как можно больше памяти и освобождает буферы и кешированное пространство только тогда, когда памяти недостаточно.
Доступная память, полученная с помощью vm.memory.size [available], довольно точна. Таким образом, мы изменим ключевое значение Используемой памяти, чтобы получить точное значение используемой памяти, вычтя доступную память из общей памяти.
конкретный:
1. Настроить | Шаблоны | Шаблон ОС Linux, выберите Элементы, щелкните Используемая память, чтобы ввести конфигурацию, как показано ниже, перед изменением.
Ввод формулы (last ("vm.memory.size [total]") - last ("vm.memory.size [available]")), вычтите доступную память из общей памяти, чтобы получить точную используемую память.
Ввод формулы (100 * last ("vm.memory.size [available]") / last ("vm.memory.size [total]")), разделите доступную память на общую память, чтобы получить коэффициент использования памяти.
Посмотреть:
спусковой крючок:
1. Configuration-->Templates-->Template OS Linux-->Triggers-->create trigger
Name: free mem less 10%
Expression:
Если состояние элементов или триггера не поддерживается, возможно, возникла проблема с выражением, и вам необходимо проверить и протестировать
Память меньше 10%. В настоящее время ресурсы памяти сервера фактически ограничены. Вы можете использовать этот триггер для запуска сценария для перезапуска служб, которые занимают больше памяти. Как правило, службы на сервере относительно фиксированы. Те, кто потребляет больше памяти, - это те , Вы можете выбрать несколько перезапусков (один экземпляр с осторожностью), и лучше всего контролировать службу, чтобы избежать сценария автоматического перезапуска службы, не запускающего службу.
В этом разделе представлена более подробная информация, а также специфичная информация по разным платформам, по параметрам vm.memory.size[] элемента данных агента.
Параметры
В этом элементе данных разрешены следующие параметры:
- active - память, используемая в данный момент или была совсем недавно в использовании, и поэтому ещё находится в RAM.
- anon - память, не связанная с файлами (повторное чтение из них невозможно).
- available - доступная память, вычисляется в зависимости от платформы (смотрите таблицу ниже).
- buffers - кэш для таких вещей, как метаданные файловой системы.
- cached - кэш для различных вещей.
- exec - исполняемый код, в основном из (программ) файлов.
- file - кэш содержимого наиболее часто используемых файлов.
- free - память, которая доступна без каких-либо проблем любому объекту, запрашивающему память.
- inactive - память, помеченная, как неиспользуемая.
- pavailable - 'available' память в процентах по отношению к 'total' (рассчитывается как available / total *100)
- pinned - то же, что и 'wired'.
- pused - 'used' память в процентах по отношению к 'total' (рассчитывается как used / total *100)
- shared - память, которая может быть доступна сразу нескольким процессам.
- slab - общий объем памяти, которая используется ядром для кэширования структур данных для собственного использования
- total - общий объем доступной физической памяти.
- used - используемая память, вычисляется в зависимости от платформы (смотри таблицу ниже).
- wired - память, помеченная всегда оставаться в RAM. Она не может быть перемещена на диск.
Некоторые из этих параметров работают только для конкретных платформ и могут быть недоступны на вашей платформе. См. Поддерживаемые элементы данных по платформам.
Вычисления available и used в зависимости от платформы:
Платформа | "available" | "used" |
---|---|---|
AIX | free + cached | реальное использование памяти |
FreeBSD | inactive + cached + free | active + wired + cached |
HP UX | free | total - free |
Linux | free + buffers+cached | total - free |
Linux 3.14+ (также перенесен на 3.10 на RHEL 7) | /proc/meminfo, см. описание "MemAvailable" в документации ядра Linux (en). Обратите внимание, что free + buffers + cached больше не равняется 'available' так как не весь кеш страницы может быть свободен и минимальный объем свободной памяти, зарезервированной системой (low watermark) используется в расчетах. | total - free |
NetBSD | inactive + execpages + file + free | total - free |
OpenBSD | inactive + free + cached | active + wired |
OSX | inactive + free | active + wired |
Solaris | free | total - free |
Win32 | free | total - free |
Сумма vm.memory.size[used] и vm.memory.size[available] не обязательно равна общему количеству памяти. Например, в FreeBSD:
* Активная, неактивная, wired, кэшируемая памяти считаются использованными, так как содержат некоторую полезную информацию.
* В то же время неактивная, кэшируемая, свободная памяти считаются доступными, так как такая память может быть незамедлительно освобождена процессу, который запросил больше памяти.
Так неактивная память помечается как занятая, так и как свободная, одновременно. В связи с этим, элемент данных vm.memory.size[used] предназначен исключительно в информационных целях, тогда как элемент данных vm.memory.size[available] предназначен для использования в триггерах.
Смотрите также
Except where otherwise noted, Zabbix Documentation is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
Очень важно, чтобы система Zabbix была оптимизирована для получения максимальной производительности.
Аппаратное обеспечение
Типовые советы по выбору аппаратной конфигурации:
- Используйте самый быстрый процессор из доступных
- SCSI или SAS лучше чем IDE (производительность IDE дисков может быть значительно улучшена с помощью утилиты hdparm) и SATA
- 15К RPM лучше чем 10К, которые в свою очередь лучше чем 7200 RPM
- используйте быстрое RAID хранилище
- используйте быстрый Ethernet адаптер
- большее количество ОЗУ всегда лучше
Операционная система
- Используйте последнюю (стабильную!) версию ОС
- Отключите ненужный функционал в ядре
- Оптимизируйте настройки ядра
Параметры конфигурации Zabbix
Многие из параметров можно оптимизировать для получения оптимальной производительности.
Для получения наилучшей производительности (например, когда поллеры не конкурируют с history syncers за общие ресурсы доступные в кэше конфигурации) рекомендуется сохранять небольшое количество процессов history pollers, pollers, unreachable pollers, Java pollers, ODBC pollers на Zabbix сервере освобождая их настолько, насколько возможно, делегируя сбор данных Zabbix прокси.
zabbix_server
StartPollers
Основное правило - использовать как можно меньшее значение. Каждый дополнительный процесс zabbix добавляет определенную нагрузку, в то же время, распараллеливание увеличивается. Оптимальное количество процессов достигается, когда очередь элементов данных, в среднем, содержит минимальное количество параметров (идеально, 0 в любой момент времени). За этим значением можно следить, используя внутренний элемент данных zabbix[queue].
Смотрите раздел "смотрите также" внизу этой страницы, чтобы понять как настроить оптимальное количество процессов zabbix.
StartHistoryPollers
Для данного параметра необходимо использовать минимально возможное значение, чтобы избежать ненужных подключений к базе данных. Каждому history poller требуется подключение к базе данных.
DebugLevel
Оптимальное значение - 3.
DBSocket
Только для MySQL. Рекомендуется использовать DBSocket для подключения к базе данных. Это самый быстрый и безопасный способ.
Движок базы данных
Это возможно наиболее важная часть оптимизации Zabbix. Zabbix сильно зависит от доступности и производительности базы данных.
Отладка GUI
Проблемы связанные с производительностью веб-интерфейса можно диагностировать при помощи режима отладки веб-интерфейса.
Общая рекомендация
- наблюдайте только необходимые параметры
- оптимизируйте "Интервал обновления" по всем элементам данных. Использование небольшого интервала обновления может быть полезно для красивых графиков, но небольшой интервал обновления может перегрузить Zabbix
- оптимизируйте параметры шаблонов доступных по умолчанию
- оптимизируйте параметры очистки истории
- не наблюдайте параметры возвращающие одни и те же значения
- избегайте использования триггеров с большими периодами в функциях. Например, max(/host/key,1h) будет вычисляться намного медленнее, чем max(/host/key,1m).
Наблюдайте за производительностью Zabbix процессов с помощью утилит "ps" и "top"
Начиная с Zabbix 2.2, процессы отображают в командной строке текущую активность и значимую статистику, примерно так:
Основной процесс является исключением. Вместо текущей активности отображается изначальная командная строка. Такое поведение помогает разделять в системе процессы с несколькими экземплярами Zabbix.
Такая возможность не реализована на платформах Microsoft Windows.
Linux
В системах Linux команда ps может использоваться с командой watch для наблюдения, что делает Zabbix. Например, запуска команды ps 5 раз в секунду для наблюдения за активностью процессов:
Наблюдение только за процессами Zabbix прокси и агента:
Наблюдение только за процессами history syncer:
для отображения только полезной информации без UID, PID, времени старта и прочего.
Можно также использовать команду top для наблюдения за производительностью Zabbix. Нажатие клавиши 'c' в команде top отобразит процессы с их командами строками. В наших тестах в Linux top и atop отображают корректно изменения активности процессов Zabbix, но в htop смена активности не отображалась.
BSD systems
Если команда watch не установлена, подобный вывод можно получить следующим способом:
AIX, HP-UX
Если команда watch не доступна, можно использовать следующий метод:
Solaris
По умолчанию команда ps не отображает изменения активности. Вместо этой команды можно использовать /usr/ucb/ps . Если команда watch не установлена, периодическое обновление списка процессов может выполнить следующим сособом:
- /usr/ucb/ps по умолчанию не установлен. Вам возможно потребуется установить ucb пакет, т.е. pkg install compatibility/ucb ,
- если демон Zabbix запускается от привилегированного пользователя, его активность не отображается непривилегированному пользователю.
- команда sleep принимает не только секунды, но также и дроби секунд (т.е. sleep 0.2 ).
Смотри также
Except where otherwise noted, Zabbix Documentation is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
Zabbix требуется как физическая память, так и память на диске. Отправной точкой могут быть 128 МБ оперативной памяти и 256 МБ свободного места на жестком диске. Впрочем, очевидно, что объем необходимой памяти на диске зависит от количества наблюдаемых узлов сети и наблюдаемых параметров. Если вы планируете достаточно долгосрочное хранении истории наблюдаемых параметров, то потребуется по крайней мере несколько гигабайт для хранения данных истории в базе данных. Каждый из процессов демона Zabbix требует несколько подключений к серверу базы данных. Объем памяти требуемый на каждое из подключенией к базе данных зависит от настроек базы данных.
Чем больше оперативной памяти вам доступно, тем быстрее работает база данных (а следовательно, и Zabbix)!
Zabbix и особенно база данных могут потребовать значительных ресурсов процессора в зависимости от количества наблюдаемых параметров и выбранного типа базы данных.
Другое оборудование
Для использования встроенных в Zabbix SMS уведомлений потребуется последовательный порт передачи данных и GSM модем. Конвертер USB-to-serial также будет работать.
Примеры конфигураций оборудования
В таблице приводятся несколько вариантов аппаратных конфигураций:
Название | Платформа | CPU / Память | База данных | Количество наблюдаемых хостов |
---|---|---|---|---|
Маленькая | CentOS | Виртуальная машина | MySQL InnoDB | 100 |
Средняя | CentOS | 2 CPU ядер/2GB | MySQL InnoDB | 500 |
Большая | RedHat Enterprise Linux | 4 CPU ядер/8GB | RAID10 MySQL InnoDB or PostgreSQL | >1000 |
Очень большая | RedHat Enterprise Linux | 8 CPU ядер/16GB | Быстрый RAID10 MySQL InnoDB или PostgreSQL | >10000 |
Фактические параметры конфигурации зависят от количества активных элементов данных и частоты обновления этих элементов (ознакомьтесь с разделом размер базы данных этой страницы). Настоятельно рекомендуется запускать базу данных на отдельном сервере для крупных инсталляций.
Поддерживаемые платформы
В связи с требованиями безопасности и критически важным характером работы системы мониторинга, единственной операционной системой, которая может обеспечить необходимую производительность, отказоустойчивость и гибкость является операционная система UNIX. Zabbix работает на лидирующих на рынке версиях.
Компоненты Zabbix доступны и протестированы на следующих платформах:
Платформа | Сервер | Агент | Агент 2 |
---|---|---|---|
Linux | x | x | x |
IBM AIX | x | x | - |
FreeBSD | x | x | - |
NetBSD | x | x | - |
OpenBSD | x | x | - |
HP-UX | x | x | - |
Mac OS X | x | x | - |
Solaris | x | x | - |
Windows | - | x | x |
Также Zabbix сервер/агент может работать и на других Unix-подобных операционных системах. Zabbix агент поддерживается на всех версиях Windows для рабочих станций и серверов начиная с XP.
Zabbix отключает дампы памяти, если скомпилирован с шифрованием и не запустится, если система не позволяет отключение дампов памяти.
Требуемое программное обеспечение
Zabbix использует современные веб-сервера, ведущие СУБД, и язык сценариев PHP.
Системы управления базами данных
Программное обеспечение | Поддерживаемые версии | Комментарии |
---|---|---|
MySQL/Percona | 8.0.X | Требуется, если MySQL (или Percona) используется основной базой данных Zabbix. Требуется InnoDB engine. Мы рекомендуем использовать библиотеку MariaDB Connector/C при сборке сервера/прокси. |
MariaDB | 10.5.00-10.6.X | Требуется InnoDB engine. Мы рекомендуем использовать библиотеку MariaDB Connector/C при сборке сервера/прокси. |
Oracle | 19c - 21c | Требуется, если используется Oracle основной базой данных Zabbix. |
PostgreSQL | 13.0 - 14.X | Требуется, если используется PostgreSQL основной базой данных Zabbix. |
TimescaleDB для PostgreSQL | 2.0.1-2.3 | Требуется, если используется TimescaleDB основной базой данных Zabbix. Убедитесь, что установленая версия Timescale DB c поддержкой сжатия. |
SQLite | 3.3.5-3.34.X | SQLite поддерживается только на стороне Zabbix прокси. Требуется, если используется SQLite основной базой данных Zabbix прокси. |
Не смотря на, что Zabbix может работать с базами данных, поставляемыми в операционных системах, мы рекомендуем всегда использовать базы данных установленные из официальных репозиториев разработчика.
Веб-интерфейс
Минимально поддерживаемая ширина экрана для Zabbix - 1200px.
Приложение | Версия | Комментарии |
---|---|---|
Apache | 1.3.12 или новее | |
PHP | 7.2.5 или новее | PHP 8.0 не поддерживается. |
Расширения PHP: | ||
gd | 2.0.28 или новее | Расширение PHP GD должно поддерживать изображения PNG (--with-png-dir), JPEG (--with-jpeg-dir) и FreeType 2 (--with-freetype-dir). |
bcmath | php-bcmath (--enable-bcmath) | |
ctype | php-ctype (--enable-ctype) | |
libXML | 2.6.15 или новее | php-xml, если поставляется как отдельный пакет от поставщика. |
xmlreader | php-xmlreader, iесли поставляется как отдельный пакет от поставщика. | |
xmlwriter | php-xmlwriter, если поставляется как отдельный пакет от поставщика. | |
session | php-session, если поставляется как отдельный пакет от поставщика. | |
sockets | php-net-socket (--enable-sockets). Требуется для поддержки пользовательских скриптов. | |
mbstring | php-mbstring (--enable-mbstring) | |
gettext | php-gettext (--with-gettext). Требуется для работы переводов. | |
ldap | php-ldap. Требуется только, если в веб-интерфейсе используется LDAP аутентификация. | |
openssl | php-openssl. Требуется только, если в веб-интерфейсе используется SAML аутентификация. | |
mysqli | Требуется, если MySQL используется в качестве базы данных Zabbix. | |
oci8 | Требуется, если Oracle используется в качестве базы данных Zabbix. | |
pgsql | Требуется, если PostgreSQL используется в качестве базы данных Zabbix. |
Также Zabbix может работать и с предыдущими версиями Apache, MySQL, Oracle, и PostgreSQL.
Для шрифтов помимо используемого по умолчанию DejaVu, может потребоваться функция PHP imagerotate. Если функция отсутствует, при отображении графиков шрифты могут отображаться некорректно. Эта функция доступна только если PHP скомпилирован вместе с GD, что не относится к Debian и некоторым другим дистрибутивам.
Веб-браузер на стороне клиента
Cookies и JavaScript должны быть включены.
Поддерживаются последние версии Google Chrome, Mozilla Firefox, Microsoft Edge, Apple Safari, и Opera.
Реализована политика одного источника для IFrames, что означает, что Zabbix веб-интерфейс нельзя поместить во фреймы на другом домене.
Сервер
Обязательные требования всегда нужно соблюдать. Опциональные требования нужно соблюдать для поддержки отдельных функций.
Агент
Требование | Признак | Описание |
---|---|---|
libpcre | Обязательно | Библиотека PCRE требуется для поддержки Perl совместимых регулярных выражений (PCRE). Наименование может отличаться в зависимости от дистрибутива GNU/Linux, например 'libpcre3' или 'libpcre1'. Поддерживаются библиотеки PCRE v8.x и PCRE2 v10.x (начиная с Zabbix 6.0.0). |
GnuTLS, OpenSSL или LibreSSL | Опционально | Требуется при использовании шифрования. На системах Microsoft Windows требуется версия OpenSSL 1.1.1 или выше. |
Начиная с версии 5.0.3, Zabbix агент не будет работать на платформах AIX с версией ниже 6.1 TL07 / AIX 7.1 TL01.
Агент 2
Требование | Признак | Описание |
---|---|---|
libpcre | Обязательно | Библиотека PCRE требуется для поддержки Perl совместимых регулярных выражений (PCRE). Наименование может отличаться в зависимости от дистрибутива GNU/Linux, например 'libpcre3' или 'libpcre1'. Поддерживаются библиотеки PCRE v8.x и PCRE2 v10.x (начиная с Zabbix 6.0.0). |
OpenSSL | Опционально | Требуется при использовании шифрования. На платформах UNIX требуется версия OpenSSL 1.0.1 или выше. В библиотеке OpenSSL должна быть включена поддержка PSK. LibreSSL не поддерживается. На системах Microsoft Windows трубется версия OpenSSL 1.1.1 или выше. |
Java gateway
Если вы получили Zabbix из репозитория исходных кодов или скачали архив, то необходимые зависимости уже включены в дерево исходного кода.
Если вы получили Zabbix из пакетов вашего дистрибутива, то необходимые зависимости обеспечиваются системой управления пакетами.
В обоих вышеупомянутых случаях, программное обеспечение готово к использованию и скачивать какие-либо дополнительные файлы не нужно.
Однако, если вы хотите использовать другие версии этих зависимостей (например, если вы готовите пакет для определенного дистрибутива Linux), ниже приведен список версий библиотек, для которых подтверждена работоспособность Java gateway. Zabbix также может работать с другими версиями этих библиотек.
Следующая таблица содержит список JAR файлов, которые поставляются вместе в Java gateway в оригинальном коде:
Java gateway может быть скомпилирован с использованием Oracle Java или с использованием OpenJDK (версия 1.6 или новее) с открытым исходным кодом. Пакеты поставляемые Zabbix скомпилированы с использованием OpenJDK. Таблица приведённая ниже, содержит информацию о версиях OpenJDK использованных для сборки пакетов Zabbix в зависимости от дистрибутива:
Дистрибутив | Версия OpenJDK |
---|---|
RHEL/CentOS 8 | 1.8.0 |
RHEL/CentOS 7 | 1.8.0 |
SLES 15 | 11.0.4 |
SLES 12 | 1.8.0 |
Debian 10 | 11.0.8 |
Ubuntu 20.04 | 11.0.8 |
Ubuntu 18.04 | 11.0.8 |
Размер базы данных
Данные конфигурации Zabbix требуют фиксированное количество дискового пространства и сильно не увеличиваются.
Размер базы данных Zabbix в основном зависит от следующих переменных, которые определяют объем хранимых исторических данных:
- Количество обрабатываемых значений в секунду
Это среднее количество новых значений, которые Zabbix сервер получает каждую секунду. Например: Если имеется 3000 элементов данных с интервалом проверки 60 секунд, то количество обрабатываемых запросов за секунду рассчитывается 3000/60 = 50.
Это означает, что каждую секунду в базу данных Zabbix добавляется 50 новых записей.
Zabbix хранит значения определенный период времени, обычно несколько недель или месяцев. Каждое новое значение требует определенный объем дискового пространства для данных и индексов.
Таким образом, если требуется хранение 30 дней истории и каждую секунду мы получаем 50 новых значений, общее количество значений будет равно примерно (30*24*3600)* 50 = 129.600.000 или около 130М значений.
В зависимости от типа базы данных, типа полученных значений (с плавающей точкой, целое число, строки, файлы журналов и т.д.) может потребоваться от 40 байт до сотен байт дискового пространства для хранения одного значения. Обычно одно значение занимает около 90 байт для числового элемента данных 2 . В нашем случае это означает, что 130М значений потребуют 130M * 90 байт = 10.9ГБ дискового пространства.
Размер значений текстовых/журнальных элементов данных невозможно предугадать, но вы можете ожидать около 500 байт на значение.
Zabbix хранит ежечасную статистику значений max/min/avg/count для каждого элемента данных в таблице trends. Эти данные используются для отслеживания динамики изменений и для графиков при отображении большого периода времени. Период в 1 час не является настраиваемым.
Базе данных Zabbix, в зависимости от типа базы данных, требуется около 90 байт на один элемент динамики изменений. Предположим, что если требуется хранить динамику изменений в течении 5 лет. Значения 3000 элементов данных потребуют 3000*24*365* 90 = 2.2ГБ за год, или 11ГБ за 5 лет.
Каждое событие требует около 250 байт дискового пространства 1 . Сложно точно оценить количество событий, ежедневно генерируемых Zabbix сервером. В самом худшем случае, мы можем предположить, что Zabbix генерирует одно событие в секунду.
По каждому событию восстановления создается запись в event_recovery. Обычно большая часть событий восстанавливается, поэтому мы можем предположить, что в event_recovery будет по одной записи по каждому событию. Это означает дополнительные 80 байт по каждому событию.
1 Больше, когда имеются не-ASCII имена событий, тегов и значения.
2 Приблизительные размеры основаны на MySQL и могут отличаться для других баз данных.
Представленная ниже таблица содержит формулы для расчета требуемого пространства жесткого диска для системы мониторинга Zabbix:
Параметр | Формула для расчета занимаемого места(в байтах) |
---|---|
Конфигурация Zabbix | Фиксированный размер. Ориентировочно 10МБ или меньше. |
История | дней*(элементов данных/частота обновления)*24*3600*байт элементы данных : количество элементов данных дней : количество дней хранения истории частота обновления : среднее значение периода проверки элементов данных байт : количество байт, требуемых для одного значения, зависит от типа базы данных, около 90 байт |
Динамика изменений | дней*(элементов данных/3600)*24*3600*байт items : number of items дней : количество дней хранения динамики изменений байт : количество байт, требуемых для одного значения, зависит от типа базы данных, около 90 байт. |
События | дней*событий*24*3600*байт событий : количество событий в секунду. Одно (1) событие в худшем случае. дней : количество дней хранения событий байт : количество байт, требуемых для одного значения, зависит от типа базы данных, обычно примерно 330 + среднее количество тегов по каждому событию * 100 байт. |
И так, общее количество требуемого места на жестком диске рассчитывается:
Конфигурация + История + Динамика изменений + События
Дисковое пространство НЕ будет зарезервировано незамедлительно после установки Zabbix. Размер базы данных будет постепенно увеличиваться и остановится по достижении определенного момента, зависящего от настроек очистки базы данных.
Синхронизация времени
Очень важно иметь точную дату и время системы на сервере с запущенным Zabbix. ntpd один из самых популярных демонов синхронизации времени узла с временем на остальных серверах. Настоятельно рекомендуется поддерживать синхронизированное время на всех системах, где работают Zabbix компоненты.
Except where otherwise noted, Zabbix Documentation is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
Когда я только внедрял мониторинг на Zabbix+Grafana остро стоял вопрос о требуемой производительности серверов мониторинга. К сожалению информации в интернетах на эту тему не много. Сейчас я более-менее уже могу ответить на этот вопрос, о чем поведу Вам.
Поскольку обычно такие вопросы возникают только в начале пути, то для масштаба возьмем небольшую систему: 50 узлов на мониторинге из из которых 25 Linux сервера с Zabbix-агентом а еще 25, это всевозможные IPMI и метрики хостов виртуализации без агентов, эдакий типичный мини зоопарк. Сама система мониторинга у нас будет для примера состоять из одного Zabbix-сервера и одного Zabbix-прокси.
Прикидки можно почитать под катком.
- По процессорам 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 можно настроить примерно так:
Вот пример потребления Zabbix+Grafana. По пикам нагрузки на проц, можно легко понять когда открывался интерфейс Графаны
Только благодаря лимиту на запрос истории в 7 дней, и памяти выделенной для БД удается более-менее избежать массивных запросов к диску(как на скриншоте выше). Но это я-бы сказал… баланс на грани. По этому на NVMe тут скупится не стоит, если Графане нужен будет диск, обычные HDD она убивает мгновенно, в этом я убедился уже не раз. Как альтернатива диску – монструозные объемы памяти, чтобы гарантированно вся БД в нее влезла, хотя этот вариант мне не нравится. Тут приходится искать некоторый баланс…
Итого, рекомендуемые сервера, которые мне кажутся более-менее сбалансированными для конфигурации с 50-ю наблюдаемыми хостами:
Читайте также: