Методы увеличения производительности Zabbix

Две заготовки статьи, склеенные в одну без редактирования.

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

  • Внутренний контроль Zabbix-сервера и Zabbix-прокси. По результатам мониторинга параметров производительности можно установить требуемое количество процессов, объёмов кэшей и буферов.
  • Настройка хранения таблиц MySQL в отдельных файлах, секционирование таблиц истории (history, history_uint, history_str, history_text, history_log) и тенденций (trends, trends_uint), тюнинг производительности сервера MySQL стандартными методами: изменение размеров различных буферов и файлов,
  • Изменение настроек UnreachablePeriod, UnreachableDelay, UnavailableDelay для снижения использования процессов Poller и Unreachable Poller. Если уменьшить их использование, можно уменьшить соответствующие настройки в конфигурации Zabbix-сервера или Zabbix-прокси, что повлечёт за собой уменьшение количество одновременно открытых соединений с сервером MySQL со стороны сервера Zabbix. Чем меньше одновременно открытых соединений к базе данных, тем меньше памяти удерживается каждым из подключений, тем больше памяти можно будет использовать с выгодой для производительности сервера MySQL,
  • Замена пассивных Zabbix-агентов на активных Zabbix-агентов. В случае пассивного Zabbix-агента съём значения какого-либо счётчика с наблюдаемого узла происходит по инициативе Zabbix-сервера, чем занимаются процессы Poller и Unreachable Poller. Чтобы снизить использование процессов Poller и Unreachable Poller, можно настроить Zabbix-агентов так, что бы они сами подключались к Zabbix-серверу, а на сервере заменить тип элементов данных c "Zabbix-агент" на "Zabbix-агент (активный)". В этом случае Zabbix-агент сам будет подключаться к Zabbix-серверу и узнавать у него список элементов данных, которые нужно контролировать и периодичность, с которой нужно отсылать значение каждого из элементов данных. Далее Zabbix-агент будет отправлять на Zabbix-сервер данные по мере их готовности, так что на сервере уменьшится использование процессов Poller и Unreachable Poller. Как уже было написано выше, это позволит уменьшить количество постоянно установленных соединений к серверу MySQL со стороны сервера Zabbix и освободить дополнительную оперативную память, распределив её на другие буферы сервера MySQL.
  • Переработка скриптов внешнего опроса таким образом, чтобы за один запуск скрипт собирал максимальное количество данных и отправлял их на сервер Zabbix при помощи утилиты zabbix_sender за один её запуск. По сути этот пункт копирует идею предыдущего и представляет собой попытку сэкономить процессы Poller и Unreachable Poller и далее по цепочке - процессор и оперативную память,
  • Увеличение корректности работы скриптов внешнего опроса. Небрежно написанный скрипт может не завершать самостоятельно работу по таймауту. В этом случае он бесполезно занимает процесс Poller, который за это время мог бы выполнить несколько других операций опроса. Небрежно написанный скрипт может не обрабатывать сообщения об ошибках, выдаваемых запускаемыми командами. В этом случае этот скрипт будет запускаться вновь и вновь до тех пор, пока не будет достигнуто время из настройки Unreachable Period, после чего скрипт будет занимать Unreachable Poller, хоть и в меньшей мере. Чтобы снизить бесполезное использование процессов Poller и Unreachable Poller, скрипт нужно написать максимально корректно, так чтобы он обрабатывал все возможные ошибки. Мы имеем дело с системой мониторинга, которая должна максимально корректно работать именно тогда, когда в сети возникают проблемы и вызываемая скриптом опроса команда может вернуть неожиданные данные или зависнуть. В сочетании с предыдущим вариантом скрипт опроса должен работать так: сами снимаемые значения он должен отправлять в Zabbix-сервер при помощи утилиты zabbix_sender, а в качестве результата своей работы должен возвращать признак - нормально он отработал или в процессе его работы были замечены ошибки. Этот признак можно контролировать при помощи отдельного триггера, вовремя обнаруживая те сетевые узлы, которые перестали опрашиваться.
  • Скрипт опроса может быть написан на чём угодно: на shell, на perl, на php или python. На практике оказалось, что с большинством операций по обработке данных внутри скрипта опроса может справиться awk. Он обладает очень низкой ресурсоёмкостью, но при этом в подавляющем большинстве случаев может заменить даже perl. Стандартный скрипт опроса состоит из четырёх этапов:
    • вызов утилиты для непосредственного съёма данных (ssh, curl, snmpwalk, ipmitool, telnet + expect),
    • проверка, что утилита вернула данные и завершение скрипта опроса с признаком ошибки опроса, если данные не были сняты,
    • обработка данных при помощи awk,
    • отправка данных в Zabbix при помощи zabbix_sender.

Ещё одним из возможных методов увеличения производительности системы мониторинга мог бы быть внутренний мониторинг устройств при помощи RMON. Внутренний мониторинг RMON - это функция SNMP-агента. SNMP-агенту можно указать, за значениями каких OID'ов необходимо следить и с какой периодичностью. В случае выхода наблюдаемого значения за установленные пределы или при возврате значения в нормальные пределы SNMP-агент может отправлять на сервер мониторинга SNMP-трапы. Внутри трапа имеется как минимум OID с идентификатором типа произошедшего события: перегрев устройства, превышение допустимого количества ошибок на сетевом интерфейсе, низкий уровень заряда батареи ИБП и т.п. В идеале вместе с трапом могут отправляться дополнительные OID'ы и их значения, имеющие отношение к событию: температура в цельсиях, количество ошибок, произошедших за контролируемый интервал, процент заряда батареи.

Однако, мониторинг SNMP-трапов в Zabbix по сути является разновидностью мониторинга журналов и никаким образом не пересекается с опросом по SNMP. Идеально было бы, если бы значения OID'ов из трапа могли попадать в элементы данных, контролируемые опросом по SNMP. Ещё лучше было бы, если бы недостающие OID'ы можно было бы дополнительно запросить у SNMP-агента при получении трапа определённого типа, так чтобы составить о событии целостную картину.

Оптимизация размеров кэшей

Оптимизация количества процессов

Оптимизация временных интервалов

  • Timeout
  • SNMPTimeout
  • SNMPRetries
  • VMwareTimeout
  • TrapperTimeout
  • UnreachablePeriod
  • UnavailableDelay
  • UnreachableDelay

Взаимосвязь с StartPollers, StartPollersUnreachable, StartPingers, StartTrappers

Оптимизация настроек базы данных

Оптимизация структуры базы данных

  • HousekeepingFrequency
  • MaxHousekeeperDelete
  • StartDBSyncers

Взаимосвязь с HistoryCacheSize, HistoryIndexCacheSize, TrendCacheSize

Оптимизация методов опроса

  • Активный Zabbix-агент
  • Опрос нескольких значений за один раз
    • zabbix_sender
    • зависимые элементы данных

Оптимизация выражений в триггерах

Функции nodata, avg, min, max, delta, change и их взаимосвязь с ValueCacheSize