Протоколы пассивных и активных проверок

Этот раздел содержит сведения о протоколе для пассивных и активных проверок, выполняемых Zabbix agent и Zabbix agent 2.

Zabbix использует протокол обмена данными на основе JSON для взаимодействия с агентами.

Протоколы Zabbix agent и Zabbix agent 2 были унифицированы начиная с Zabbix 7.0. Различие между запросами/ответами Zabbix agent и Zabbix agent 2 выражается значением тега "variant".

Пассивные проверки

Пассивная проверка — это простой запрос данных. Сервер или прокси Zabbix запрашивает некоторые данные (например, загрузку CPU), а агент Zabbix отправляет результат обратно на сервер.

Пассивные проверки выполняются асинхронно — не требуется получать ответ на один запрос до начала других проверок. Разрешение DNS также выполняется асинхронно.

Опросчик агента будет пытаться подключиться ко всем адресам, возвращенным DNS-запросом. Это гарантирует, что если один IP-адрес недоступен, опросчик попробует следующий доступный адрес, повышая вероятность успешного подключения. Это улучшение применяется как к серверу Zabbix, так и к прокси.

Максимальная параллельность асинхронных проверок составляет 1000 (определяется параметром MaxConcurrentChecksPerPoller).

Количество асинхронных опросчиков агента определяется параметром StartAgentPollers.

Запрос сервера

Для определения длины заголовка и данных см. детали протокола.

{
  "request": "passive checks",
  "data": [
    {
      "key": "agent.version",
      "timeout": 3
    }
  ]
}

Ответ агента

{
  "version": "8.0.0",
  "variant": 2,
  "data": [
    {
      "value": "8.0.0"
    }
  ]
}

Например, для поддерживаемых элементов данных:

1. Сервер открывает TCP-соединение
2. Сервер отправляет <HEADER><DATALEN>{"request":"passive checks","data":[{"key":"agent.ping","timeout":3}]}
3. Агент читает запрос и отвечает <HEADER><DATALEN>{"version":"8.0.0","variant":2,"data":[{"value":1}]}
4. Сервер обрабатывает данные, чтобы получить значение, в нашем случае — 1
5. TCP-соединение закрывается

Для неподдерживаемых элементов данных:

1. Сервер открывает TCP-соединение
2. Сервер отправляет <HEADER><DATALEN>{"request":"passive checks","data":[{"key":"vfs.fs.size[/nono]","timeout":3}]}
3. Агент читает запрос и отвечает <HEADER><DATALEN>{"version":"8.0.0","variant":2,"data":[{"error":"Unsupported item key."}]}
4. Сервер обрабатывает данные, изменяет состояние элемента данных на неподдерживаемое с указанным сообщением об ошибке
5. TCP-соединение закрывается

Переключение на старый протокол

Чтобы обеспечить работу сервера или прокси Zabbix с агентами версий до 7.2, которые используют протокол в открытом виде, реализован переход на старый протокол.

Пассивные проверки выполняются с использованием JSON-протокола (7.0 и новее) после перезапуска или при изменении конфигурации интерфейса.
Если в ответ не получен допустимый JSON (агент отправил "ZBX_NOTSUPPORTED"), Zabbix кэширует интерфейс как использующий старый протокол и повторяет проверку, отправляя только ключ элемента данных.

Обратите внимание, что каждый час сервер/прокси Zabbix снова будет пытаться работать с новым протоколом со всеми интерфейсами, при необходимости возвращаясь к старому протоколу.

Активные проверки

Активные проверки требуют более сложной обработки. Сначала агент должен получить от сервера/прокси список элементов данных и/или удаленных команд для независимой обработки.

Серверы/прокси, с которых нужно получать активные проверки, перечислены в параметре 'ServerActive' файла конфигурации агента. Частота запроса этих проверок задается параметром 'RefreshActiveChecks' в том же файле конфигурации. Однако если обновление активных проверок завершается неудачей, повторная попытка выполняется через жестко заданные 60 секунд.

Агент затем периодически отправляет новые значения на сервер(ы). Если агент получил какие-либо удаленные команды для выполнения, результат выполнения также будет отправлен. Обратите внимание, что выполнение удаленных команд на активном агенте поддерживается начиная с Zabbix agent 7.0.

Получение списка элементов данных

Запрос агента

Запрос active checks используется для получения активных проверок, которые должны обрабатываться агентом.
Этот запрос отправляется агентом при запуске, а затем с интервалами RefreshActiveChecks.

{
  "request": "active checks",
  "host": "Zabbix server",
  "host_metadata": "mysql,nginx",
  "interface": "zabbix.server.lan",
  "ip": "159.168.1.1",
  "port": 12050,
  "version": "8.0.0",
  "variant": 2,
  "config_revision": 1,
  "session": "e3dcbd9ace2c9694e1d7bbd030eeef6e"
}

Ответ сервера

Ответ active checks отправляется сервером агенту после обработки запроса active checks.

{
  "response": "success",
  "config_revision": 2,
  "data": [
    {
      "key": "system.uptime",
      "itemid": 1234,
      "delay": "10s",
      "lastlogsize": 0,
      "mtime": 0
    },
    {
      "key": "agent.version",
      "itemid": 5678,
      "delay": "10m",
      "lastlogsize": 0,
      "mtime": 0,
      "timeout": "30s"
    }
  ],
  "commands": [
    {
      "command": "df -h --output=source,size / | awk 'NR>1 {print $2}'",
      "id": 1324,
      "wait": 1
    }
  ]
}

Сервер должен ответить success.

Например:

1. Агент открывает TCP-соединение
2. Агент запрашивает список проверок
3. Сервер отвечает списком элементов данных и удаленных команд для выполнения
4. Агент разбирает ответ
5. TCP-соединение закрывается
6. Агент начинает периодический сбор данных и выполняет удаленные команды (поддерживается начиная с Zabbix agent 7.0)

Отправка собранных данных

Агент отправляет

Запрос данных агента содержит собранные значения элементов данных и значения выполненных удаленных команд (если таковые имеются).

{
  "request": "agent data",
  "data": [
    {
      "id": 1,
      "itemid": 5678,
      "value": "7.0.0",
      "clock": 1712830783,
      "ns": 76808644
    },
    {
      "id": 2,
      "itemid": 1234,
      "value": "69672",
      "clock": 1712830783,
      "ns": 77053975
    }
  ],
  "commands": [
    {
      "id": 1324,
      "value": "16G"
    }
  ],
  "session": "8495cd52070e6ca52b371f29c8574165",
  "host": "Zabbix server",
  "version": "8.0.0",
  "variant": 2
}

Каждому значению назначается виртуальный ID. ID значения — это простой возрастающий счетчик, уникальный в рамках одного сеанса передачи данных (идентифицируемого по токену сеанса). Этот ID используется для отбрасывания дублирующихся значений, которые могут передаваться в условиях плохого соединения.

Ответ сервера

Ответ на данные агента отправляется сервером обратно агенту после обработки запроса данных агента.

{
  "response": "success",
  "info": "processed: 2; failed: 0; total: 2; seconds spent: 0.003534"
}

Например:

1. Агент открывает TCP-соединение
2. Агент отправляет список значений
3. Сервер обрабатывает данные и отправляет статус обратно
4. TCP-соединение закрывается

Сообщение heartbeat

Отправка агентом

Сообщение heartbeat отправляется активным агентом на сервер/прокси Zabbix каждые HeartbeatFrequency секунд (настраивается в файле конфигурации Zabbix agent/agent 2).

Оно используется для мониторинга доступности активных проверок.

{
  "request": "active check heartbeat",
  "host": "Zabbix server",
  "heartbeat_freq": 60,
  "version": "8.0.0",
  "variant": 2
}

Ответ перенаправления

Когда узел сети был переназначен, сервер может указать агенту перенаправить его heartbeat (и последующие активные проверки) на другой экземпляр прокси или сервера.

  {
    "response": "failed",
    "redirect": {
      "revision": 2,
      "address": "192.0.2.1:10055"
    }
  }

Старый XML-протокол