Почему активный агент Zabbix 7.4 не выбирает доступный прокси

Прокси зелёный. Группа Online. Резерв есть. Но активный агент в филиале упорно пытается достучаться до адреса, к которому у него нет маршрута. Я, Евгений Семёнов, встречаю эту картину после каждого второго внедрения proxy groups: от Zabbix ждут проверки сетевой доступности глазами агента, хотя сервер проверяет совсем другое. Ниже разберу механику без магии, покажу кейс антикварного магазина на 44 рабочих места и дам порядок диагностики, с которого сам начинаю такие работы.

Зелёный прокси ещё не доступен агенту

Состояние Online у прокси означает только одно: прокси связался с Zabbix server в пределах заданного Failover period. По умолчанию это одна минута, допустимый диапазон в 7.4 — от 10 секунд до 15 минут. Сервер не запускает проверку из подсети филиала и не строит матрицу маршрутов «каждый агент — каждый прокси». Если активный proxy из ЦОД успешно выходит к серверу, он будет зелёным даже тогда, когда межсетевой экран филиала отбрасывает обращения агентов к его TCP/10051.

Группа прокси тоже не доказывает сквозную доступность. При Minimum number of proxies, равном 1, группе достаточно одного или нескольких прокси, поддерживающих связь с сервером. Параметр отвечает за состояние группы и возможность перераспределения хостов, а не за достижимость её участников из каждой клиентской сети. Уменьшать Failover period в такой ситуации бесполезно: недоступный агентам прокси продолжает вовремя общаться с сервером и остаётся Online.

Отсюда моя рабочая формулировка: proxy group — это группа взаимозаменяемых сборщиков с точки зрения Zabbix server. Чтобы они стали взаимозаменяемыми для active checks, сеть обязана обеспечить агентам доступ ко всем адресам, опубликованным для этой группы. Это условие архитектуры, а не функция автоматического обнаружения маршрута.

• Online у proxy = своевременная связь с Zabbix server в пределах Failover period (по умолчанию 1m, диапазон 10s–15m).
• Minimum number of proxies (по умолчанию 1, диапазон 1–1000) определяет, останется ли группа Online; при падении ниже порога online-прокси продолжают работать, но балансировка и HA не выполняются.
• Значение Minimum number of proxies должно быть меньше числа прокси в группе: для двух прокси разумно только 1.
• Ни один из этих параметров не проверяет маршрут от агента до Address for active agents.
• Документация прямо предупреждает: в стабильной схеме без недавней перебалансировки агенты могут вообще ни разу не обратиться к резервному proxy — дефект маршрута всплывёт только при реальном отказе.

Что на самом деле делает ServerActive

Активный агент сам подключается к trapper-порту сервера или прокси, обычно TCP/10051, получает список active items, выполняет их и отправляет значения обратно. В Zabbix 7.4 участники одного кластера или proxy group перечисляются в ServerActive через точку с запятой. Запятая имеет другую семантику: она разделяет независимые серверы или кластеры, с которыми агент работает параллельно. Я регулярно вижу запятые, поставленные как знак «резервный адрес». Это неверная конфигурационная модель.

Даже если в ServerActive указан один участник группы, агент версии 7.0 и новее после успешного подключения получает и кэширует список адресов прокси группы и сведения об их нагрузке. Дальше запрос может быть перенаправлен на тот прокси, которому сервер назначил конкретный хост. Если опубликованный адрес недоступен через firewall или маршрутизацию, active checks зависнут до тайм-аута либо завершатся ошибкой. Наличие достижимого начального адреса не отменяет перенаправление.

Именно поэтому ServerActive я называю точкой входа и описанием кластера, но не гарантией маршрута. Перечислить два DNS-имени полезно: агент сможет стартовать, если первый узел действительно выключен. Однако список не обещает, что Zabbix выберет узел по результату локального Test-NetConnection. В официальной документации требование сформулировано прямо: агент должен иметь возможность подключиться через firewall ко всем прокси группы.

Для пассивных проверок логика зеркальная. В параметре Server агента нужно перечислить все прокси группы, и здесь разделитель — запятая: это список адресов, с которых агент принимает входящие подключения на TCP/10050, а не описание кластера. Если в Server оставить только первый прокси, после перераспределения второй начнёт опрашивать хост и получит отказ, хотя в интерфейсе оба узла будут зелёными. Address for active agents, заданный у прокси, используется и при подключении к активным, и к пассивным прокси.

• Для одного прокси: `ServerActive=proxy-a.mon.example.local:10051`.
• Для одной proxy group: `ServerActive=proxy-a.mon.example.local;proxy-b.mon.example.local`.
• Для пассивных проверок той же группы: `Server=proxy-a.mon.example.local,proxy-b.mon.example.local` — здесь именно запятая.
• Не используйте запятую между участниками одной группы: она предназначена для независимых серверов или кластеров, работающих параллельно.

Кейс «АнтикварГрад»: как замолчала половина агентов

Разберу обезличенный проект под условным названием антикварный магазин «АнтикварГрад». 44 рабочих места: 41 компьютер на Windows 11 (торговый зал, кассы, оценщики, бухгалтерия, реставрационная мастерская) и три Linux-узла на Ubuntu 24.04 LTS — сервер учёта, файловое хранилище фотокаталога и мини-ПК, который собирает данные датчиков температуры и влажности в хранилище. Честно скажу: для 44 машин один proxy или даже прямое подключение агентов к серверу — нормальная схема. Второй прокси появился по конкретной причине: однажды единственный proxy магазина завис в пятницу вечером, и до понедельника никто не узнал, что в хранилище с мебелью XVIII века влажность ушла за 70 %. Владелец попросил резерв именно для этого сценария.

На момент контрольного испытания server, два proxy и Agent 2 были обновлены до Zabbix 7.4.14. Серверу хватило 2 vCPU и 4 ГБ RAM, каждому прокси — 1 vCPU и 1 ГБ RAM с отдельной SQLite-базой. Это размеры конкретного стенда с большим запасом, а не официальные минимальные требования. Сначала все 44 хоста обслуживал proxy-a — виртуальная машина в серверной магазина с адресом 10.20.30.10. Затем в группу добавили proxy-b в арендованном облаке: у него был адрес управления 172.20.8.12, он исправно подключался к Zabbix server 172.20.8.5 и поэтому отображался как Online. В поле Address for active agents у второго прокси по ошибке оставили тот же 172.20.8.12. Из VLAN рабочих станций 10.20.30.0/24 маршрута к нему не было.

У группы стояли Failover period 1m и Minimum number of proxies 1. Сразу после добавления резерва всё выглядело нормально. Затем сработала балансировка. При распределении 44/0 среднее равно 22: у первого прокси избыток 22 хоста, что больше порога в 10 хостов и ровно вдвое выше среднего. Дисбаланс держался дольше grace period, равного десяти Failover period, и сервер перераспределил хосты 22/22. В Latest data у 22 станций, включая мини-ПК с датчиками хранилища, появились пробелы. Оба прокси при этом оставались зелёными.

Администратор добавил оба адреса в ServerActive и перезапустил Agent 2. Результат не изменился: агент успешно входил через первый прокси, получал актуальное назначение и затем пытался работать через недостижимый 172.20.8.12. После настройки маршрута через VPN, правила TCP/10051 и правильного DNS-имени для второго прокси мы повторили балансировку и полное выключение первого узла. Все 44 агента восстановили передачу; самое медленное переключение заняло 74 секунды. Благодаря persistent buffer потерь значений в нашем испытании не было.

• Симптом: пропуски данных ровно у половины хостов после добавления второго proxy, оба proxy Online.
• Причина: Address for active agents второго proxy указывал на management-адрес, недоступный из VLAN рабочих станций.
• Что не помогло: перечисление обоих адресов в ServerActive, перезапуск агентов, смена Failover period.
• Что помогло: маршрут через VPN, правило TCP/10051 из 10.20.30.0/24 и отдельное DNS-имя для agent-facing адреса.
• Результат: переключение при отказе первого proxy не дольше 74 секунд, без потери значений.

Диагностика: начинаю с рабочей станции

Первое, что я делаю, — не перезапускаю Zabbix server и не меняю пороги группы. Открываю проблемный хост и проверяю DNS и TCP/10051 до каждого Address for active agents. Проверка с сервера, ноутбука администратора или самого прокси не подходит: у них другие таблицы маршрутизации, DNS-зоны и правила firewall.

На Windows достаточно штатного PowerShell. Важно проверить оба имени по отдельности и записать полученные IP. Если DNS возвращает management-адрес, NAT с неправильной стороны или IPv6 без рабочего маршрута, проблема уже найдена.

Resolve-DnsName proxy-a.mon.example.local
Resolve-DnsName proxy-b.mon.example.local
Test-NetConnection proxy-a.mon.example.local -Port 10051 -InformationLevel Detailed
Test-NetConnection proxy-b.mon.example.local -Port 10051 -InformationLevel Detailed

На Linux я выполняю эквивалентную проверку через getent и nc:

getent ahosts proxy-a.mon.example.local
getent ahosts proxy-b.mon.example.local
nc -vz -w 3 proxy-a.mon.example.local 10051
nc -vz -w 3 proxy-b.mon.example.local 10051

Затем сверяю три вещи в интерфейсе: хост должен быть Monitored by proxy group, оба proxy должны входить именно в эту группу, а их Address for active agents обязаны быть адресами, доступными агентам. Полезно посмотреть текущее количество назначенных хостов у каждого прокси. Если перестали обновляться примерно 20–22 станции из 44, а распределение стало 22/22, это гораздо сильнее указывает на маршрут до одного участника, чем на случайный сбой Agent 2.

• Проверьте точное совпадение `Hostname` агента с Host name в Zabbix: значение регистрозависимое.
• Убедитесь, что TCP/10051 слушается на каждом прокси и разрешён от всех подсетей агентов.
• Посмотрите журнал Agent 2 сразу после перезапуска и после очередного обновления active checks.
• При необходимости снимите трафик на прокси командой `tcpdump -ni any tcp port 10051`: SYN от проблемного хоста либо приходит, либо нет.
• Не используйте `zabbix_get` как доказательство исправности active checks: утилита проверяет пассивный опрос агента, обычно через TCP/10050.

Конфигурация, которую я оставил в проекте

Я выбираю простой вариант: одна proxy group соответствует одной зоне сетевой достижимости. В «АнтикварГрад» первый proxy остался в серверной магазина, второй — в ЦОД, но для него сделали отдельное имя proxy-b.mon.example.local, которое из сети магазина разрешалось в 10.20.254.22 — адрес на стороне VPN. Firewall разрешал 10.20.30.0/24 обращаться по TCP/10051 к обоим узлам. Серверный адрес и management-интерфейс второго прокси агентам больше не публиковались.

В Administration → Proxies мы указали Address for active agents: proxy-a.mon.example.local:10051 и proxy-b.mon.example.local:10051. Это отдельное понятие от адреса, по которому активный proxy сам соединяется с сервером. Смешивать agent-facing и management-сети удобно только на маленьком плоском стенде. В филиальной инфраструктуре я их разделяю и называю явно.

Фрагмент конфигурации Windows Agent 2 выглядел так. PSK у каждого хоста был свой; файл ключа создавался системой управления конфигурациями и не распространялся вместе с шаблоном.

Hostname=AG-RM-023
ServerActive=proxy-a.mon.example.local;proxy-b.mon.example.local
RefreshActiveChecks=5
Timeout=5
TLSConnect=psk
TLSPSKIdentity=AG-RM-023
TLSPSKFile=C:\ProgramData\Zabbix\agent.psk
EnablePersistentBuffer=1
PersistentBufferFile=C:\ProgramData\Zabbix\zabbix_agent2.db
PersistentBufferPeriod=24h
LogType=file
LogFile=C:\ProgramData\Zabbix\zabbix_agent2.log

RefreshActiveChecks=5 — штатное значение по умолчанию в Agent 2 версии 7.4. После неудачного обновления агент делает следующую попытку через 60 секунд, поэтому переключение не обязано укладываться в пять секунд. Timeout=5 немного удобнее на VPN, но увеличивать его до 30 секунд ради недоступного маршрута я не советую.

Перед распространением конфиг проверяли штатным тестом, затем перезапускали службу:

& 'C:\Program Files\Zabbix Agent 2\zabbix_agent2.exe' -T -c 'C:\Program Files\Zabbix Agent 2\zabbix_agent2.conf'
Restart-Service 'Zabbix Agent 2'
Get-Content 'C:\ProgramData\Zabbix\zabbix_agent2.log' -Tail 100

Persistent buffer полезен при коротком обрыве, но это страховка данных, а не средство выбора маршрута. Если TCP/10051 недоступен сутками, буфер лишь отсрочит потерю значений.

• Обновляйте server и proxy до одной актуальной версии ветки; на стенде использовалась 7.4.14.
• Для active mode с proxy groups нужен агент не старее 7.0; я всё равно выравниваю версии компонентов, чтобы сократить число переменных.
• Храните базу каждого proxy отдельно. Подключать proxy к базе Zabbix server нельзя.
• Шифруйте соединения агентов с proxy через PSK или сертификаты и ограничивайте TCP/10051 нужными подсетями.

Как испытывать резерв, а не индикатор

После исправления я всегда провожу два разных теста. Сначала останавливаю proxy, на котором находятся выбранные контрольные хосты. Сервер должен признать его Offline после Failover period и перераспределить хосты. Затем запускаю или перезагружаю один агент, пока исходный proxy выключен. Второй сценарий ловит опасную конфигурацию, где в ServerActive указан единственный недоступный bootstrap-адрес.

Второй тест сетевой: proxy оставляем Online для сервера, но временно закрываем путь от тестовой рабочей станции к его agent-facing адресу. Это и есть сценарий из статьи. Ожидаемый результат честный: Zabbix не обязан объявить proxy Offline, потому что его связь с сервером цела. Мы проверяем, что такого одностороннего ограничения в боевой матрице firewall вообще не может возникнуть и что мониторинг отдельно контролирует доступность TCP/10051 из каждой филиальной зоны.

На что можно забить? На попытку добиться переключения за две-три секунды для обычных рабочих мест. Failover period в 30–60 секунд плюс повторное обновление active checks обычно разумнее, чем агрессивные десять секунд и нервная реакция на краткий сетевой джиттер. А вот на запуск агента при выключенном первом адресе забивать нельзя: именно этот тест выявляет резерв, существующий только на схеме.

• Зафиксируйте исходное назначение контрольных хостов по proxy.
• Остановите назначенный proxy дольше Failover period.
• Проверьте новое назначение, поступление Latest data и журнал агента.
• Перезагрузите один Agent 2 при выключенном первом адресе ServerActive.
• Верните proxy, дождитесь Online и повторите тест в обратную сторону.
• Проверьте накопление и отправку buffered values после восстановления связи.

Мой приоритет: сначала связность, потом Zabbix

Причина такого сбоя обычно не в алгоритме балансировки Zabbix 7.4. Наоборот, он делает ровно то, что обещано: видит два online proxy и распределяет между ними хосты. Ошибка появляется уровнем ниже — один из опубликованных адресов недостижим из сети агента. Сервер об этом не знает и узнавать по текущей модели не обязан.

Порядок действий у меня жёсткий. Сначала проверяю с проблемного хоста DNS и TCP/10051 ко всем участникам. Затем сверяю Address for active agents и назначение хоста группе. После этого исправляю маршруты, ACL и имена. И только потом трогаю Failover period, Minimum number of proxies, буферы и интервалы. Такой порядок экономит часы бессмысленных перезапусков.

На сентябрь 2026 года актуальный выпуск ветки — Zabbix 7.4.14 от 25 августа 2026 года; сама 7.4 является Standard release с ограниченной поддержкой до IV квартала 2026 года, а 7.0 LTS поддерживается полностью до 30 июня 2027 года. Для нового долгоживущего внедрения я уже планировал бы переход на следующую LTS-ветку после её стабильного выпуска и проверки миграции. Но обновление версии само по себе не исправит отсутствующий маршрут: правило «каждый агент достигает каждого proxy своей группы» останется главным.

• Одна proxy group — одна зона сетевой достижимости для её агентов.
• ServerActive: участники группы через точку с запятой; Server для пассивных проверок: через запятую.
• Address for active agents — адрес, реально доступный из сети агентов, а не management-интерфейс.
• Minimum number of proxies меньше общего числа прокси в группе, Failover period 30–60 секунд.
• Отдельный элемент данных `net.tcp.service[tcp,<proxy>,10051]` с контрольной станции каждой зоны на каждый proxy группы.

Частые вопросы