high error rate zabbix что значит
Заббикс внезапно перестает заполнять график данными.
Через snmpget устройство отвечает всегда, т.е. проблема, скорее всего, на стороне мониторинга.
Кто-нибудь сталкивался с таким поведением?
Не помогло. После активации мониторинга (enable), данные с хоста некоторое время накапливаются, но потом перестают. https://habrastorage.org/webt/ok/bd/kk/okbdkkzeiw8uiaiaxuglrsf35s4.png Фиолетовый график это ifHCInOctets (множитель подобран неверно, но это неважно).
Смотреть графики загрузки poller’ов, очереди.
UPD. Полностью удалил хост из заббикса и создал его снова. Данные пошли. Прошла ночь. Утром обрыв: https://habrastorage.org/webt/ha/hz/kl/hahzklkzwhvwab9eneui-oknj-y.png
Черт, а действительно Zabbix unreachable poller processes more than 75% busy
О, эта вечное SNMP + Zabbix равно любовь.
1. Посмотри очередь. Бывает, что эта дурилка встает на каком-то одном ключе и перестает опрашивать все остальные ключи на хосте, при свободных поллерах. Отличался этим ключ типа ntptime. 2. Подними до приличных цифр обычные поллеры, unreachable поллеры и snmp-трапперы, если используешь. У меня сейчас стартует 100 unreachable на
20 хостов*30 ключей. 3. Проверь, нет ли пересечений в авторизации у хостов: одинаковые ключи, одинаковые имена, одинаковые SNMP Engine ID. Оно какое-то время работает, потом внезапно помирает при таком мерже. 4. Посмотри, нет ли в логах сообщений про недоступность хостов по SNMP. Если их много, то это косвенно похоже на п.3. Сделай маленький тайм-аут переопроса, помониторь ситуацию.
Я вот смотрю на нее (в первый раз) и не знаю, нормально это или нет, лол. В пиках бывает и по 12к. Но судя по статистике, сейчас с очередью все относительно нормально https://habrastorage.org/webt/7z/bg/ex/7zbgexav1cpbykcpjcuvp1o3dy4.png
У меня сейчас стартует 100 unreachable на
А есть какая-нибудь методика по расчету количества потоков? В зависимости от железа и количества хостов. Или методом тыка?
Посмотри, нет ли в логах сообщений про недоступность хостов по SNMP
Просто вагон и маленькая тележка ошибок про несоответствие имени хоста в агенте и на сервере
1927:20180720:101449.560 cannot send list of active checks to «10.46.45.138»: host [VDB2-187700] not found
Я правильно понимаю, что они не особо важны? А про SNMP нет.
NVPS 710 для новичка не мало, это нагрузка на БД. Очереди должны быть почти всегда на нуле, либо запоздание не больше 10 секунд. Тут определённо проблемы с производительностью, с таким NVPS тут нужно железо по приличнее и хороший тюнинг БД.
Ошибки из-за некорректных имён надо исправлять. Лучше использовать авторегистрацию хостов. Для снижения нагрузки на zabbix сервер хорошо использовать активные проверки и прокси.
Выкручивание poller’ов не всегда хорошо. В качестве отправной точки предлагаю посмотреть видео от инженера тех.поддержки zabbix https://www.youtube.com/watch?v=BglZLJQOEa0 где разбираются типичные проблемы.
Я вот смотрю на нее (в первый раз) и не знаю, нормально это или нет, лол
А есть какая-нибудь методика по расчету количества потоков?
И смотри графики zabbix gathering и zabbix perfomance.
Просто вагон и маленькая тележка ошибок про несоответствие имени хоста в агенте и на сервере
Вот они вроде бы и не влияют ни на что, т.к. у тебя не эктивчекс, а snmp, но как показала практика, отнимают время у поллеров. Лучше наведи в этом деле порядок, как верно советуют, через автодискавери.
В общем, судя по состоянию процессов, Zabbix был изначально сконфигурирован неправильно. Например, unreachable poller были всегда забиты на 100%, обычных поллеров тоже иногда не хватало.
Но потери на графиках возникли относительно недавно. Возможно, дело в том, что количество хостов все-таки увеличивается, а не уменьшается и заббикс достиг некой грани, когда просто стал терять данные.
В общем, было 20 unreachable poller. При этом, почему-то крайне медленных:
Насколько нормальна ситуация, когда поллер got 1 values in 60 sec?
Я увеличил количество unreachable poller с 20 до 60 (ну да, разогнался) и перезапустил сервис. Нагрузка на ядра заметно возросла. Если раньше в логе не было медленных запросов, то теперь проскакивают. Полагаю, что теперь не справляется база.
Не понимаю одного: почему с измененным количеством unreachable poller, они все равно остаются медленными. Буду рад, если кто-нибудь объяснит логику процесса
linux-notes.org
Стандартные настройки в zabbix, не всегда хорошо работают и их необходимо тюнить под свои нужды. Я собрал в данной статье, основные параметры для оптимизации. Возможно, — это не все и вы знаете больше, но я постараюсь максимизировать.
Настройка кеша
Для оптимизации заббикс сервера, стоит увеличить размер кеша, для этого — открываем:
Находим строку «CacheSize» и увеличиваем его.
Я увеличил до 256M. При надобности, можно добавить.
Zabbix discoverer processes more than 75% busy
Недавно получил алерт в заббиксе:
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Ищем строку с опцией «StartDiscoverers» и увеличиваем данный параметр:
Я, опцию StartDiscoverers увеличил до 5. На этом настройка заканчивается, нужно сохранить конфиг и перезагрузить zabbix сервер:
Можно увидеть мой наглядный пример:
Если после добавления хостов ( с разными подсетями) вы увидите что снова сработал этот триггер, то нужно увеличить StartDiscoverers.
Zabbix icmp pinger processes more than 75% busy
Недавно получил алерт в заббиксе:
Данное сообщение, говорит — что процесс(ы) выполняющие ping по хостам, перегружены.
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Ищем строку с опцией «StartPingers» и увеличиваем данный параметр:
Я, опцию StartPingers увеличил до 5, тем самым — я увеличил количество процессов выполняющих ICMP Ping.
На этом настройка заканчивается, нужно сохранить конфиг и перезагрузить zabbix сервер:
Zabbix poller processes more than 75% busy
poller — это процесс который опрашивает агентов.
Данный параметр стоит увеличивать в 2- случаях:
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Ищем строку с опцией «StartPollers» и увеличиваем данный параметр:
Я установил данный параметр в 5. Если очень будет худо, то увеличиваем его до 20. Ничто не приходит бесследно, увеличение процессов ведет к увеличение потребления ресурсов.
После этого, вы можете получить:
Если видите у себя данное сообщение ( алерт, сработанный триггер), открываем конфиг:
Ищем строку с опцией «StartPollersUnreachable» и увеличиваем данный параметр:
PS: У меня данный параметр используется по умолчанию и я его не трогал ( не было ошибок).
Имеется вероятность того, что перестанет хватать коннекщенов для БД, то надо увеличивать лимит подключений.
Zabbix housekeeper processes more than 75% busy
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Сохраняем файл и перезагружаем zabbix:
Zabbix busy timer processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Переменную укажу позже (не знаю какая)!
Сохраняем файл и перезагружаем zabbix:
Zabbix busy escalator processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Переменную укажу позже (не знаю какая)!
Сохраняем файл и перезагружаем zabbix:
Zabbix busy alerter processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Переменную укажу позже (не знаю какая)!
Сохраняем файл и перезагружаем zabbix:
Zabbix busy configuration syncer processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Находим и изменяем:
Сохраняем файл и перезагружаем zabbix:
Zabbix busy db watchdog processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Переменную укажу позже (не знаю какая)!
Сохраняем файл и перезагружаем zabbix:
Zabbix busy history syncer processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Находим и изменяем:
Сохраняем файл и перезагружаем zabbix:
Zabbix busy self-monitoring processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Переменную укажу позже (не знаю какая)!
Сохраняем файл и перезагружаем zabbix:
Zabbix busy http poller processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Находим и меняем параметр:
Сохраняем файл и перезагружаем zabbix:
Zabbix busy java poller processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Находим и меняем параметр:
Сохраняем файл и перезагружаем zabbix:
А на этом, у меня все и статья «Оптимизация настроек Zabbix» завершена.
6 thoughts on “ Оптимизация настроек Zabbix ”
первый раз пишу комент на сайте за лет 5 ))) аж не по себе ))
в общем респект и уважуха!
housekeeper processesMaxHousekeeperDelete=5000 поменял на 100
но не помогло, все ровно так же высвечивает Zabbix housekeeper processes more than 75% busy. Перезагружал железо не помогло. Что делать?
Нужно не уменьшать, а увеличивать!
Но нужно чтобы хватило ресурсов на сервере.
Может RAM, CPU мало для Докер контейнера выделил. Так же, может стоит увеличить значения в 2-3 раза:
ZBX_VALUECACHESIZE=512M
ZBX_CACHESIZE=512M
ZBX_STARTDISCOVERERS=10
Благодарность за хороший Материал и Работу!
Столкнулся с сообщением вида:
Zabbix server is not running: the information displayed may not be current
Правка /etc/zabbix/zabbix_server.conf
Изменил значение параметра CacheSize=512M (было 8)
и перезапустил zabbix
service zabbix-server restart
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте, как обрабатываются ваши данные комментариев.
Оптимизация настроек Zabbix
Стандартные настройки в zabbix, не всегда хорошо работают и их необходимо изменить под свои нужды. Я собрал в данной статье, основные параметры для оптимизации. Возможно, — это не все и вы знаете больше, но я постараюсь максимизировать.
Настройка кеша
Для оптимизации zabbix сервера, стоит увеличить размер кеша, для этого — открываем:
Находим строку «CacheSize» и увеличиваем его.
Я увеличил до 256M. При надобности, можно добавить.
Zabbix discoverer processes more than 75% busy
Недавно получил алерт в заббиксе:
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Ищем строку с опцией «StartDiscoverers» и увеличиваем данный параметр:
Я, опцию StartDiscoverers увеличил до 5. На этом настройка заканчивается, нужно сохранить конфиг и перезагрузить zabbix сервер:
Если после добавления хостов ( с разными подсетями) вы увидите что снова сработал этот триггер, то нужно увеличить StartDiscoverers.
Zabbix icmp pinger processes more than 75% busy
Недавно получил алерт в заббиксе:
Данное сообщение, говорит — что процесс(ы) выполняющие ping по хостам, перегружены.
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Ищем строку с опцией «StartPingers» и увеличиваем данный параметр:
Я, опцию StartPingers увеличил до 5, тем самым — я увеличил количество процессов выполняющих ICMP Ping.
На этом настройка заканчивается, нужно сохранить конфиг и перезагрузить zabbix сервер:
Zabbix poller processes more than 75% busy
poller — это процесс который опрашивает агентов.
Данный параметр стоит увеличивать в 2- случаях:
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Ищем строку с опцией «StartPollers» и увеличиваем данный параметр:
Я установил данный параметр в 5. Если очень будет худо, то увеличиваем его до 20. Ничто не приходит бесследно, увеличение процессов ведет к увеличение потребления ресурсов.
После этого, вы можете получить:
Если видите у себя данное сообщение ( алерт, сработанный триггер), открываем конфиг:
Ищем строку с опцией «StartPollersUnreachable» и увеличиваем данный параметр:
PS: У меня данный параметр используется по умолчанию и я его не трогал ( не было ошибок).
Имеется вероятность того, что перестанет хватать коннекщенов для БД, то надо увеличивать лимит подключений.
Zabbix housekeeper processes more than 75% busy
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Сохраняем файл и перезагружаем zabbix:
Zabbix busy timer processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Переменную укажу позже (не знаю какая)!
Сохраняем файл и перезагружаем zabbix:
Zabbix busy escalator processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Сохраняем файл и перезагружаем zabbix:
Zabbix busy alerter processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Переменную укажу позже (не знаю какая)!
Сохраняем файл и перезагружаем zabbix:
Zabbix busy configuration syncer processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Находим и изменяем:
Сохраняем файл и перезагружаем zabbix:
Zabbix busy db watchdog processes, in %
Начиная с Zabbix 3.4 alpha, нет необходимости в мониторинге процесса db watchdog, так как он был удален. Шаблон приложения Zabbix сервер не должен иметь этот элемент.
Zabbix busy history syncer processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Находим и изменяем:
Сохраняем файл и перезагружаем zabbix:
Zabbix busy self-monitoring processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Переменную укажу позже (не знаю какая)!
Сохраняем файл и перезагружаем zabbix:
Zabbix busy http poller processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Находим и меняем параметр:
Сохраняем файл и перезагружаем zabbix:
Zabbix busy java poller processes, in %
Это можно исправить, откроем zabbix_server.conf конфиг-файл:
Находим и меняем параметр:
Сохраняем файл и перезагружаем zabbix
А на этом, у меня все и статья «Оптимизация настроек Zabbix» завершена.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Высокая производительность и нативное партиционирование: Zabbix с поддержкой TimescaleDB
Zabbix — это система мониторинга. Как и любая другая система, она сталкивается с тремя основными проблемами всех систем мониторинга: сбор и обработка данных, хранение истории, ее очистка.
Этапы получения, обработки и записи данных занимают время. Немного, но для крупной системы это может выливаться в большие задержки. Проблема хранения — это вопрос доступа к данным. Они используются для отчетов, проверок и триггеров. Задержки при доступе к данным также влияют на производительность. Когда БД разрастаются, неактуальные данные приходится удалять. Удаление — это тяжелая операция, которая также съедает часть ресурсов.
Проблемы задержек при сборе и хранении в Zabbix решаются кэшированием: несколько видов кэшей, кэширование в БД. Для решения третьей проблемы кэширование не подходит, поэтому в Zabbix применили TimescaleDB. Об этом расскажет Андрей Гущин — инженер технической поддержки Zabbix SIA. В поддержке Zabbix Андрей больше 6 лет и напрямую сталкивается с производительностью.
Как работает TimescaleDB, какую производительность может дать по сравнению с обычным PostgreSQL? Какую роль играет Zabbix для БД TimescaleDB? Как запустить с нуля и как мигрировать с PostgreSQL и производительность какой конфигурации лучше? Обо всем этом под катом.
Вызовы производительности
Каждая система мониторинга встречается с определенными вызовами производительности. Я расскажу о трех из них: сбор и обработка данных, хранение, очистка истории.
Быстрый сбор и обработка данных. Хорошая система мониторинга должна оперативно получать все данные и обрабатывать их согласно триггерным выражениям — по своим критериям. После обработки система должна также быстро сохранить эти данные в БД, чтобы позже их использовать.
Хранение истории. Хорошая система мониторинга должна хранить историю в БД и предоставлять удобный доступ к метрикам. История нужна, чтобы использовать ее в отчетах, графиках, триггерах, пороговых значениях и вычисляемых элементах данных для оповещения.
Очистка истории. Иногда наступает день, когда вам не нужно хранить метрики. Зачем вам данные, которые собраны за 5 лет назад, месяц или два: какие-то узлы удалены, какие-то хосты или метрики уже не нужны, потому что устарели и перестали собираться. Хорошая система мониторинга должна хранить исторические данные и время от времени их удалять, чтобы БД не разрослась.
Очистка устаревших данных — острый вопрос, который сильно отражается на производительности базы данных.
Кэширование в Zabbix
В Zabbix первый и второй вызовы решены с помощью кэширования. Для сбора и обработки данных используется оперативная память. Для хранения — истории в триггерах, графиках и вычисляемых элементах данных. На стороне БД есть определенное кэширование для основных выборок, например, графиков.
Кэширование на стороне самого Zabbix-сервера это:
ConfigurationCache
Это основной кэш, в котором мы храним метрики, хосты, элементы данных, триггеры — все, что нужно для PreProcessing и для сбора данных.
Все это хранится в ConfigurationCache, чтобы не создавать лишних запросов в БД. После старта сервера мы обновляем этот кэш, создаем и периодически обновляем конфигурации.
Сбор данных
Схема достаточно большая, но основное в ней — это сборщики. Это различные «pollers» — процессы сборки. Они отвечают за разные виды сборки: собирают данные по SNMP, IPMI, и передают это все на PreProcessing.
Сборщики обведены оранжевой линией.
В Zabbix есть вычисляемые агрегационные элементы данных, которые нужны, чтобы агрегировать проверки. Если у нас они есть, мы забираем данные для них напрямую из ValueCache.
PreProcessing HistoryCache
Все сборщики используют ConfigurationCache, чтобы получать задания. Дальше они передают их на PreProcessing.
PreProcessing использует ConfigurationCache, чтобы получать шаги PreProcessing. Он обрабатывает эти данные различными способами.
После обработки данных с помощью PreProcessing, сохраняем их в HistoryCache, чтобы обработать. На этом заканчивается сбор данных и мы переходим к главному процессу в Zabbix — history syncer, так как это монолитная архитектура.
Примечание: PreProcessing достаточно тяжелая операция. С v 4.2 он вынесен на proxy. Если у вас очень большой Zabbix с большим количеством элементов данных и частотой сбора, то это сильно облегчает работу.
ValueCache, history & trends cache
History syncer — это главный процесс, который атомарно обрабатывает каждый элемент данных, то есть каждое значение.
History syncer берет значения из HistoryCache и проверяет в Configuration наличие триггеров для вычислений. Если они есть — вычисляет.
History syncer создает событие, эскалацию, чтобы создать оповещения, если требуется по конфигурации, и записывает. Если есть триггеры для последующей обработки, то это значение он запоминает в ValueCache, чтобы не обращаться в таблицу истории. Так ValueCache наполняется данными, которые необходимы для вычисления триггеров, вычисляемых элементов.
History syncer записывает все данные в БД, а она — в диск. Процесс обработки на этом заканчивается.
Кэширование в БД
На стороне БД есть различные кэши, когда вы хотите смотреть графики или отчеты по событиям:
Производительность БД критически важна
Zabbix-сервер постоянно собирает данные и записывает их. При перезапуске он тоже читает из истории для наполнения ValueCache. Скрипты и отчеты использует Zabbix API, который построен на базе Web-интерфейса. Zabbix API обращается в базу данных и получает необходимые данные для графиков, отчетов, списков событий и последних проблем.
Для визуализации — Grafana. Среди наших пользователей это популярное решение. Она умеет напрямую отправлять запросы через Zabbix API и в БД, и создает определенную конкурентность для получения данных. Поэтому нужна более тонкая и хорошая настройка БД, чтобы соответствовать быстрой выдаче результатов и тестирования.
Housekeeper
Третий вызов производительности в Zabbix — это очистка истории с помощью Housekeeper. Он соблюдает все настройки — в элементах данных указано, сколько хранить динамику изменений (трендов) в днях.
TrendsCache мы вычисляем на лету. Когда поступают данные, мы их агрегируем за один час и записываем в таблицы для динамики изменений трендов.
Housekeeper запускается и удаляет информацию из БД обычными «selects». Это не всегда эффективно, что можно понять по графикам производительности внутренних процессов.
Красный график показывает, что History syncer постоянно занят. Оранжевый график сверху — это Housekeeper, который постоянно запускается. Он ждет от БД, когда она удалит все строки, которые он задал.
Когда стоит отключить Housekeeper? Например, есть «Item ID» и нужно удалить последние 5 тысяч строк за определенное время. Конечно, это происходит по индексам. Но обычно dataset очень большой, и БД все равно считывает с диска и поднимает в кэш. Это всегда очень дорогая операция для БД и, в зависимости от размеров базы, может приводить к проблемам производительности.
Housekeeper просто отключить. В Web-интерфейсе есть настройка в «Administration general» для Housekeeper. Отключаем внутренний Housekeeping для внутренней истории трендов и он больше не управляет этим.
Housekeeper отключили, графики выровнялись — какие в этом случае могут быть проблемы и что может помочь в решении третьего вызова производительности?
Partitioning — секционирование или партиционирование
Обычно партиционирование настраивается различным способом на каждой реляционной БД, которые я перечислил. У каждой своя технология, но они похожи, в целом. Создание новой партиции часто приводит к определенным проблемам.
Обычно партиции настраивают в зависимости от «setup» — количества данных, которые создаются за один день. Как правило, Partitioning выставляют за один день, это минимум. Для трендов новой партиции — за 1 месяц.
Значения могут изменяться в случае очень большого «setup». Если малый «setup» — это до 5 000 nvps (новых значений в секунду), средний — от 5 000 до 25 000, то большой — выше 25 000 nvps. Это большие и очень большие инсталляции, которые требуют тщательной настройки именно базы данных.
На очень больших инсталляциях отрезок в один день может быть не оптимальным. Я видел на MySQL партиции по 40 ГБ и больше за день. Это очень большой объем данных, который может приводить к проблемам, и его нужно уменьшать.
Что дает Partitioning?
Секционирование таблиц. Часто это отдельные файлы на диске. План запросов более оптимально выбирает одну партицию. Обычно партиционирование используется по диапазону — для Zabbix это тоже верно. Мы используем там «timestamp» — время с начала эпохи. У нас это обычные числа. Вы задаете начало и конец дня — это партиция.
Заметно ускоряет выборку данных SELECT — использует одну или более партиций, а не всю таблицу. Если вы обращаетесь за данными двухдневной давности, они выбираются из БД быстрее, потому что нужно загрузить в кэш и выдать только один файл, а не большую таблицу.
Зачастую многие БД также ускоряет INSERT — вставки в child-таблицу.
TimescaleDB
Для v 4.2 мы обратили внимание на TimescaleDB. Это расширение для PostgreSQL с нативным интерфейсом. Расширение эффективно работает с time series данными, при этом не теряя преимуществ реляционных БД. TimescaleDB также автоматически партицирует.
В TimescaleDB есть понятие гипертаблица (hypertable), которую вы создаете. В ней находятся чанки — партиции. Чанки — это автоматически управляемые фрагменты гипертаблицы, который не влияет на другие фрагменты. Для каждого чанка свой временной диапазон.
TimescaleDB vs PostgreSQL
После 200 млн строк PostgreSQL обычно начинает сильно проседать и теряет производительность до 0. TimescaleDB позволяетэффективно вставлять «inserts» при любом объеме данных.
Установка
Установить TimescaleDB достаточно просто для любых пакетов. В документации все подробно описано — он зависит от официальных пакетов PostgreSQL. TimescaleDB также можно собрать и скомпилировать вручную.
Для БД Zabbix мы просто активируем расширение:
Вы активируете extension и создаете его для БД Zabbix. Последний шаг — создание гипертаблицы.
Миграция таблиц истории на TimescaleDB
Для этого есть специальная функция create_hypertable :
У функции три параметра. Первый — таблица в БД, для которой нужно создать гипертаблицу. Второй — поле, по которому надо создать chunk_time_interval — интервал чанков партиций, которые нужно использовать. В моем случае интервал это один день — 86 400.
Конфигурация железа
Я использовал два сервера. Первый — VMware-машина. Она достаточно маленькая: 20 процессоров Intel® Xeon® CPU E5-2630 v 4 @ 2.20GHz, 16 ГБ оперативной памяти и SSD-диск на 200 ГБ.
Я установил на ней PostgreSQL 10.8 с ОС Debian 10.8-1.pgdg90+1 и файловой системой xfs. Все минимально настроил, чтобы использовать именно эту базу данных, за вычетом того, что будет использовать сам Zabbix.
Изначально конфигурация содержала 5 000 элементов данных на каждый хост. Почти каждый элемент содержал триггер, чтобы это было схоже с реальными инсталляциями. В некоторых случаях было больше одного триггера. На один узел сети приходилось 3 000-7 000 триггеров.
Интервал обновления элементов данных — 4-7 секунд. Саму нагрузку я регулировал тем, что использовал не только 50 агентов, но добавлял еще. Также, с помощью элементов данных я динамических регулировал нагрузку и снижал интервал обновления до 4 с.
PostgreSQL. 35 000 nvps
Первый запуск на этом железе у меня был на чистом PostgreSQL — 35 тыс значений в секунду. Как видно, вставка данных занимает фракции секунды — все хорошо и быстро. Единственное, что SSD диск на 200 ГБ быстро заполняется.
Это стандартный dashboard производительности Zabbix — сервера.
Первый голубой график — количество значений в секунду. Второй график справа — загрузка процессов сборки. Третий — загрузка внутренних процессов сборки: history syncers и Housekeeper, который здесь выполнялся достаточное время.
Четвертый график показывает использование HistoryCache. Это некий буфер перед вставкой в БД. Зеленый пятый график показывает использование ValueCache, то есть сколько хитов ValueCache для триггеров — это несколько тысяч значений в секунду.
PostgreSQL. 50 000 nvps
Дальше я увеличил нагрузку до 50 тыс значений в секунду на этом же железе.
При загрузке с Housekeeper вставка 10 тыс значений записывалась 2-3 с.
Housekeeper уже начинает мешать работе.
По третьему графику видно, что, в целом, загрузка трапперов и history syncers пока еще на уровне 60%. На четвертом графике HistoryCache во время работы Housekeeper уже начинает достаточно активно заполняться. Он заполнился на 20% — это около 0,5 ГБ.
PostgreSQL. 80 000 nvps
Дальше я увеличил нагрузку до 80 тыс значений в секунду. Это примерно 400 тыс элементов данных и 280 тыс триггеров.
Вставка по загрузке тридцати history syncers уже достаточно высокая.
Также я увеличивал различные параметры: history syncers, кэши.
На моем железе загрузка history syncers увеличивалась до максимума. HistoryCache быстро заполнился данными — в буфере накопились данные для обработки.
Все это время я наблюдал, как используется процессор, оперативная память и другие параметры системы, и обнаружил, что утилизация дисков была максимальна.
Я добился использования максимальных возможностей диска на этом железе и на этой виртуальной машине. При такой интенсивности PostgreSQL начал сбрасывать данные достаточно активно, и диск уже не успевал работать на запись и чтение.
Второй сервер
Я взял другой сервер, который имел уже 48 процессоров и 128 ГБ оперативной памяти. Затюнинговал его — поставил 60 history syncer, и добился приемлемого быстродействия.
Фактически, это уже предел производительности, где необходимо что-то предпринимать.
TimescaleDB. 80 000 nvps
Моя главная задача — проверить возможности TimescaleDB от нагрузки Zabbix. 80 тыс значений в секунду — это много, частота сбора метрик (кроме Яндекса, конечно) и достаточно большой «setup».
На каждом графике есть провал — это как раз миграция данных. После провалов в Zabbix-сервере профиль загрузки history syncer очень сильно изменился — упал в три раза.
TimescaleDB позволяет вставлять данные практически в 3 раза быстрее и использовать меньше HistoryCache.
Соответственно, у вас своевременно будут поставляться данные.
TimescaleDB. 120 000 nvps
Дальше я увеличил количество элементов данных до 500 тыс. Главная задача была проверить возможности TimescaleDB — я получил расчетное значение 125 тыс значений в секунду.
Это рабочий «setup», который может долго работать. Но так как мой диск был всего на 1,5 ТБ, то я его заполнил за пару дней.
Самое важное, что в это же время создавались новые партиции TimescaleDB.
Для производительности это совершенно незаметно. Когда создаются партиции в MySQL, например, все иначе. Обычно это происходит ночью, потому что блокирует общую вставку, работу с таблицами и может создавать деградацию сервиса. В случае с TimescaleDB этого нет.
Для примера покажу один график из множества в community. На картинке включен TimescaleDB, благодаря этому загрузка по использованию io.weight на процессоре упала. Использование элементов внутренних процессов тоже снизилось. Причем это обычная виртуалка на обычных блинных дисках, а не SSD.
Выводы
TimescaleDB хорошее решение для маленьких «setup», которые упираются в производительность диска. Оно позволит неплохо продолжать работать до миграции БД на железо побыстрее.
TimescaleDB прост в настройке, дает прирост производительности, хорошо работает с Zabbix и имеет преимущества по сравнению с PostgreSQL.
Если вы применяете PostgreSQL и не планируете его менять, то рекомендую использовать PostgreSQL с расширением TimescaleDB в связке с Zabbix. Это решение эффективно работает до средних «setup».
Говорим «высокая производительность» — подразумеваем HighLoad++. Ждать, чтобы познакомиться с технологиями и практиками, позволяющими сервисам обслуживать миллионы пользователей, совсем недолго. Список докладов на 7 и 8 ноября мы уже составили, а вот митапы еще можно предложить.
Подписывайтесь на нашу рассылку и telegram, в которых мы раскрываем фишки предстоящей конференции, и узнайте, как извлечь максимум пользы.