Как я устраняю рост очереди Zabbix server и загрузку poller-процессов

С чего началась реконструкция очереди

В наших внедрениях поводом к разбору обычно становится не красный индикатор сам по себе, а изменение поведения: свежие данные приходят неровно, в Queue overview накапливаются элементы старших интервалов, а занятость отдельных процессов долго не возвращается к обычному профилю. Я начинаю с временной линии и не называю ненулевую очередь отказом. Планировщик имеет право кратковременно держать проверки в ожидании; обслуживание, перезапуск удалённого узла или сетевой всплеск тоже оставляют след. Проблемой очередь становится, когда растёт её возраст, сохраняется один и тот же состав и это отражается на актуальности значений. Поэтому первым делом я фиксирую, какие типы элементов и какие группы узлов формируют хвост, а не пытаюсь немедленно изменить конфигурацию сервера.

Внутренние ключи как карта процессов

Для наблюдения изнутри я применяю zabbix[queue] и показатели занятости процессов. zabbix[process,poller,avg,busy] показывает среднюю долю времени, когда обычные poller-процессы заняты работой; zabbix[process,unreachable poller,avg,busy] отдельно характеризует повторные обращения к недоступным целям. zabbix[process,preprocessing manager,avg,busy] помогает увидеть, успевает ли управляющий процесс предобработки распределять поступившие значения. Эти internal items удобны тем, что описывают состояние самого Zabbix, но они не равны производительности сервера. Рядом я смотрю CPU, память, дисковую задержку, соединения и состояние базы данных. Низкая системная нагрузка не доказывает свободную очередь, а высокий busy конкретного процесса не означает исчерпание процессора: процесс способен проводить время в ожидании ответа внешней системы.

Разбор Queue overview по происхождению проверок

Queue overview превращает общий счётчик в список причин для проверки. Я группирую задержанные элементы по proxy, типу item, хост-группе и возрасту, затем открываю несколько характерных элементов и сверяю их расписание, интерфейс и последнее получение данных. Если хвост образован SNMP или agent checks одной площадки, это отличается от равномерного отставания всех пассивных проверок. Если задержаны только длинные внешние или HTTP-проверки, вероятен медленный target либо дорогая проверка, а не нехватка процессов как таковая. Важно не запускать массовое Execute now: оно искажает исходную картину и создаёт дополнительную конкуренцию. Мне нужна последовательность наблюдений на обычном расписании, чтобы отделить разовый сдвиг планировщика от устойчивого накопления долга.

Медленная цель и недоступная цель — разные ветви

Медленная цель отвечает, но тратит почти весь допустимый timeout; недоступная цель уходит в специальный цикл повторных попыток. В первом случае высокая zabbix[process,poller,avg,busy] часто совпадает с ограниченным набором проверок, которые ждут сеть, устройство или удалённый API. Я проверяю сам check с безопасной стороны: разрешение имени, маршрут, время установления соединения и корректность типа элемента, не извлекая секреты. Во втором случае растёт zabbix[process,unreachable poller,avg,busy], а в очереди заметна группа узлов с общей причиной доступности. StartPollers задаёт число обычных poller-процессов, StartPollersUnreachable — число процессов для недоступных целей. Поднимать один параметр вместо другого бессмысленно; сначала я устраняю маршрут, интерфейс, firewall или ошибочную привязку, если именно они удерживают проверки.

Когда задержка появляется после получения значения

Отдельная картина возникает, когда сеть и poller-процессы выглядят спокойно, но зависимые элементы обновляются с задержкой. Тогда я сопоставляю поток master items с zabbix[process,preprocessing manager,avg,busy] и правилами preprocessing. Большие JSON-документы, длинные цепочки JSONPath, регулярные выражения, JavaScript и массовые dependent items способны перенести узкое место за границу опроса. Добавление StartPollers здесь не ускоряет разбор уже полученного значения. Я ищу повторяющиеся преобразования, ненужные шаги, чрезмерно объёмный ответ и возможность оставить одно получение с разумным набором зависимых элементов. Изменения предобработки проверяю на сохранённом обезличенном образце без токенов и персональных данных. Так диагностика не смешивает доставку данных с последующей вычислительной обработкой.

Почему proxy иногда важнее ещё одного poller

Центральный Zabbix server не обязан напрямую опрашивать каждый удалённый сегмент. Если очередь привязана к площадкам с заметной сетевой задержкой, нестабильным каналом или большим самостоятельным контуром, я рассматриваю разделение через proxy. Proxy выполняет сбор ближе к целям, буферизует результаты и снижает число долгих сетевых ожиданий на центральной стороне. Это архитектурное решение, а не способ спрятать неисправность: у proxy должны быть собственные наблюдаемые ресурсы, понятная ответственность и проверенный обмен с server. Простое увеличение poller-процессов на центре оставляет прежнюю зависимость от дальнего канала и увеличивает параллелизм запросов. Решение о переносе принимаю по происхождению очереди и топологии, а не по одному проценту busy.

Безопасная проверка гипотезы

Перед изменением я сохраняю снимок Queue overview, графики внутренних items и перечень затронутых элементов без значений секретных макросов. Затем выбираю изолированную группу или небоевую цель с тем же типом проверки. Контролируемый тест меняет только один фактор: например, исправляет timeout проверки, упрощает один preprocessing step либо временно направляет тестовую группу через подготовленный proxy. Я не назначаю универсальный интервал опроса и не копирую фиксированный порог занятости: допустимый профиль зависит от длительности checks, расписания и объёма данных. Во время теста сравниваю возраст очереди, busy соответствующего класса процессов, актуальность значений и нагрузку server. Массовые изменения, перезапуск всех компонентов и одновременная перестройка шаблонов не дают доказать причинность.

Закрепление результата и границы вывода

После подтверждения гипотезы я распространяю минимальную правку только на однородный контур и продолжаю наблюдать состав очереди, а не праздную первое снижение счётчика. Устойчивый результат означает, что старые элементы уходят, новые не стареют тем же способом, а занятость связанного процесса возвращается к рабочему профилю без ухудшения серверных ресурсов. Если эффект обратный, применяется заранее подготовленный откат конфигурации или привязки группы. Этот метод не доказывает исправность базы данных, диска, сети и удалённого сервиса; их метрики рассматриваются отдельно. Он также не заменяет расчёт ёмкости для резкого роста числа items. В наших внедрениях ценность реконструкции в том, что она связывает конкретный хвост Queue overview с конкретным этапом обработки и не превращает StartPollers в универсальную ручку.

Отвергнутые альтернативы

• Сразу увеличить StartPollersЕсли задерживается конкретный медленный target или сама проверка, дополнительные процессы лишь умножают одновременные ожидания и нагрузку.
• Считать любую ненулевую очередь авариейКороткая очередь возникает при планировании и кратковременных колебаниях; важны возраст, состав, устойчивость и связь с занятостью процессов.
• Лечить недоступные узлы обычными poller-процессамиДля повторных проверок недоступных целей существует отдельный тип процессов и параметр StartPollersUnreachable.
• Добавлять poller-процессы при перегруженном preprocessing managerСбор уже может завершаться вовремя, а задержка образуется после приёма значения на этапах предобработки.
• Неограниченно наращивать процессы на центральном сервереПри удалённых площадках, сетевой задержке и большом числе автономных сегментов правильнее разделить сбор через Zabbix proxy.

Конфигурация и сбор

Только чтение Monitoring, Queue и графиков внутренних items в интерфейсе; на ОС — непривилегированное чтение разрешённых журналов и конфигурации Zabbix server. Доступ к базе, секретным макросам и содержимому vault не требуется.

• Зафиксировать Queue overview и историю zabbix[queue] за сопоставимые рабочие периоды.
• Снять графики трёх классов процессов и серверные метрики без экспорта учётных данных.
• Прочитать активные строки StartPollers, StartPollersUnreachable, Timeout и связанные Include-файлы; комментарии и секреты в рабочую запись не копировать.
• Просмотреть журнал Zabbix server в режиме read-only, выбирая сообщения о slow checks, недоступности и preprocessing по временному окну.

Контролируемая проверка и свидетельство

На изолированной группе либо небоевой цели воспроизводится один характерный item. Меняется один проверяемый фактор, после чего наблюдаются очередь, нужный process busy и системная нагрузка. Тест прекращается при росте задержки соседних проверок, появлении ошибок или неожиданном увеличении потребления ресурсов.

Фрагмент рабочего регламента

• Открыть Queue overview и записать распределение по возрасту без запуска массовых проверок.
• Сопоставить задержанные items с poller, unreachable poller или preprocessing manager.
• Проверить доступные для чтения конфигурационные строки и журнал, маскируя адреса, имена и секреты.
• Выбрать ветвь причины: медленный check, недоступная цель, preprocessing либо необходимость proxy.

Откат

До теста сохраняются прежние значения изменяемого параметра, версия шаблона и исходная привязка группы. Откат выполняется обратным единичным изменением; после него проверяются запуск соответствующих процессов, поступление значений и отсутствие нового стареющего хвоста. Если менялась схема через proxy, тестовая группа возвращается на прежний маршрут сбора.

Ограничения вывода

Нельзя вывести универсальное безопасное число StartPollers, StartPollersUnreachable, фиксированный polling interval или единый процент busy. Вывод зависит от версии Zabbix, типов items, timeout, распределения расписания, производительности базы, сети и поведения целей. Internal items показывают состояние процессов Zabbix, но не объясняют причину без Queue overview, журналов и серверных метрик.