Такое мнение встречается довольно часто.
Исторически одна из причин действительно была связана с количеством polling operations на стороне Zabbix server.
Но современные версии Zabbix умеют выполнять passive agent checks асинхронно.
То есть модель:
1 poller = 1 check = ждём ответ
уже плохо описывает современную реализацию passive agent checks.
Поэтому выбор:
active vs passive
сейчас правильнее делать по архитектуре, сетевой модели и характеру monitoring, а не по универсальному правилу:
«если hosts много — обязательно active».
18. Где passive может быть удобнее
Passive checks имеют очень понятную модель:
нужно значение
↓
Zabbix спрашивает agent
↓
получает ответЭто удобно, когда:
- — server/proxy легко достигает monitored hosts;
- — monitoring network централизована;
- — firewall позволяет TCP/10050;
- — адреса hosts стабильны;
- — хочется простой диагностики request/response.
Например, внутри одного серверного сегмента:
proxy ↓ 100 серверов
passive checks могут быть совершенно нормальным архитектурным выбором.
19. Где active может быть удобнее
Например:
- — удалённые офисы;
- — NAT;
- — DMZ;
- — облачные VM;
- — динамические адреса;
- — жёсткие inbound firewall rules;
- — log monitoring;
- — сеть, где monitored host может инициировать outbound, а Zabbix не может подключаться внутрь.
Схема:
много внутренних hosts
↓
одно разрешённое направление
↓
Zabbix / Proxy :10051часто существенно проще сопровождать.
20. Динамический IP — хороший пример
Для passive checks Zabbix должен знать:
куда подключиться к agent?
Если IP постоянно меняется, появляется дополнительная задача.
Для active agent сам знает:
куда подключаться к Zabbix?
А Zabbix идентифицирует его в первую очередь через host identity.
То есть monitored host становится менее зависим от доступного извне собственного адреса.
21. Диагностика passive checks
Допустим, данные перестали приходить.
Полезно разделить проверку на этапы.
С Zabbix server/proxy:
zabbix_get -s 10.20.30.15 -k agent.ping
Если получаем:
1
значит, базовое passive-взаимодействие работает.
Если нет — проверяем:
agent запущен?
↓
слушает 10050?
↓
Agent interface правильный?
↓
маршрут существует?
↓
firewall пропускает?
↓
Server= разрешает источник?То есть passive удобно диагностировать как обычный входящий сервис.
22. Диагностика active checks начинается с другой стороны
Здесь вопрос уже:
способен ли agent обратиться к Zabbix?
Проверяем:
ServerActive
↓
DNS
↓
route
↓
TCP/10051А затем:
Hostname
↓
host в frontend
↓
тип items
↓
proxy assignmentОчень полезен журнал агента.
Типичная логика ошибки может показать, что:
соединение есть
но:
active checks для этого host не получены
Это сразу переводит диагностику с сети на конфигурацию.
23. Особенно полезно разделять две проверки
Для active agent:
Может ли agent подключиться к server?
и:
Получает ли agent правильную конфигурацию?
Это не одно и то же.
Например:
TCP 10051 → OK Hostname → неправильный
Сеть исправна. Active monitoring — нет.
24. А доступность agent при active checks как определяется?
Старое упрощение иногда звучит так:
active agent невозможно нормально контролировать, потому что server сам к нему не подключается.
В современных версиях Zabbix active agent может отправлять heartbeat на server/proxy.
Это используется для контроля доступности active checks.
То есть модель стала сильнее, чем просто:
значения иногда приходят → значит agent жив
Но важно понимать сам принцип:
для active monitoring состояние оценивается через активное взаимодействие агента с Zabbix, а не через входящую проверку agent.ping со стороны server.
25. Один и тот же host может выглядеть исправным только наполовину
Например:
passive items → работают active items → не работают
Это вполне возможно.
Почему?
Потому что passive подтверждает:
server → agent:10050
А active требует:
agent → server:10051 + корректный Hostname + правильную active-конфигурацию
Получаем две независимые цепочки.