Zabbix active и passive checks — разница в модели

РАЗБОР #07

Разницу между active и passive checks часто объясняют одной схемой:

Passive:
Zabbix server → agent

Active:
agent → Zabbix server

Формально это верно. Но если на этом остановиться, теряется самое интересное. Active и passive checks отличаются не только тем, кто открывает TCP-соединение. Меняется сама модель взаимодействия:

кто знает расписание проверки
+
кто инициирует получение значения
+
как находится monitored host
+
какие сетевые доступы нужны
+
что происходит при недоступности одной стороны

Разберём по слоям.

1. Начнём с passive check

Допустим, в Zabbix создан item:

Type:
Zabbix agent

Key:
system.cpu.util

Для passive check инициатором выступает Zabbix server или proxy. Упрощённо:

Zabbix server / proxy
        ↓
TCP connection
        ↓
agent :10050
        ↓
запрос конкретной метрики
        ↓
agent получает значение
        ↓
ответ
        ↓
Zabbix

То есть Zabbix фактически говорит агенту: дай мне сейчас значение этого item.

2. Что для этого должен знать server

Для passive check серверу или proxy нужно понимать:

куда подключаться?

Для этого используется Agent interface узла:

IP / DNS
+
port

Например:

10.20.30.15:10050

Получается:

Zabbix
   ↓
Agent interface
   ↓
10.20.30.15:10050

Если адрес неправильный или недоступен, passive checks работать не будут.

3. Что должен разрешить сам agent

В конфигурации агента есть параметр:

Server=

Он определяет, от каких Zabbix servers или proxies агент разрешает входящие соединения для passive checks. Например:

Server=10.10.0.5

То есть наличие открытого порта 10050 ещё недостаточно. Нужно одновременно:

server может добраться до agent
        +
agent принимает connection
        +
source разрешён параметром Server

4. Получаем сетевую модель passive checks

Например:

Zabbix Server
10.10.0.5
      │
      │ TCP/10050
      ↓
Linux Server
10.20.30.15
Zabbix Agent

Firewall должен разрешить:

10.10.0.5
    ↓
10.20.30.15:10050

Если между ними находятся:

NAT
firewall
VPN
ACL

нужно обеспечить именно этот входящий путь к agent.

5. Теперь active check

В frontend item уже имеет другой тип:

Zabbix agent (active)

Здесь логика меняется. Agent сам обращается к server или proxy:

agent
  ↓
ServerActive
  ↓
Zabbix server / proxy :10051

Но важная деталь: агент не просто отправляет значения куда-то на сервер. Сначала он получает информацию о том, какие active checks должен выполнять.

6. Как active agent узнаёт свои проверки

В конфигурации задаётся:

ServerActive=zabbix.example.ru:10051

Agent подключается к указанному server или proxy и сообщает в запросе в том числе свой:

Hostname

Упрощённо:

agent
  ↓
«Я host01»
  ↓
Zabbix
  ↓
«Вот список твоих active checks»

После этого агент выполняет эти проверки самостоятельно.

7. И вот здесь появляется одно из самых важных отличий

Для passive check логика приблизительно такая:

Zabbix
  ↓
пришло время item
  ↓
обратиться к agent
  ↓
получить значение

Для active:

agent
  ↓
получить конфигурацию active checks
  ↓
самостоятельно выполнять проверки
  ↓
накопить значения
  ↓
отправить их в Zabbix

То есть:

passive
→ Zabbix запрашивает значение

active
→ agent получает задания и выполняет их сам

Это уже гораздо больше, чем просто изменение направления connection.

8. Для active checks особенно важен Hostname

Например, на agent:

Hostname=web01

А в Zabbix frontend host называется:

web-01

Для человека разница минимальна. Для active checks:

web01
≠
web-01

Agent приходит на server:

Я web01

а такой конфигурации для active checks сервер не находит. Получаем типичную ситуацию:

agent запущен
        +
сеть работает
        +
порт 10051 доступен
        +
данные не приходят

Причина — не сеть. А идентификация host.