2 Потоковая передача во внешние системы
Обзор
Можно передавать значения элементов данных и события из Zabbix во внешние системы по HTTP (см. подробности протокола).
Фильтр тегов можно использовать для передачи подмножеств значений элементов данных или событий.
За потоковую передачу данных отвечают два типа процессов сервера Zabbix: connector manager и connector worker.
Внутренний элемент данных Zabbix zabbix[connector_queue] позволяет отслеживать количество значений, поставленных в очередь коннектора.
Конфигурация
Для настройки потоковой передачи данных во внешнюю систему необходимо выполнить следующие шаги:
1. Подготовьте удаленную систему для приема данных из Zabbix. Для этого доступны следующие инструменты:
- Пример простого приемника, который записывает полученную информацию в файлы
events.ndjsonиhistory.ndjson. - Kafka connector for Zabbix server — легковесный сервер, написанный на Go, предназначенный для пересылки значений элементов данных и событий с сервера Zabbix в брокер Kafka.
2. Установите требуемое количество рабочих процессов connector в Zabbix, изменив параметр StartConnectors в файле zabbix_server.conf.
Количество рабочих процессов connector должно соответствовать (или превышать, если число одновременных сеансов больше 1) настроенному количеству connector в веб-интерфейсе Zabbix.
Затем перезапустите сервер Zabbix.
3. Настройте новый connector в веб-интерфейсе Zabbix (Administration > General > Connectors) и обновите кэш сервера с помощью команды zabbix_server -R config_cache_reload.

Обязательные поля отмечены звездочкой.
| Parameter | Description |
|---|---|
| Name | Введите имя connector. |
| Data type | Выберите тип данных для потоковой передачи: Item values — передавать значения элементов данных из Zabbix во внешние системы; Events — передавать события из Zabbix во внешние системы. |
| URL | Введите URL приемника. Поддерживаются пользовательские макросы. |
| Tag filter | Экспортировать только значения элементов данных или события, соответствующие фильтру тегов. Если не задано, экспортируется все. Можно включать, а также исключать определенные теги и значения тегов. Можно задать несколько условий. Сопоставление имени тега всегда чувствительно к регистру. Для каждого условия доступны следующие операторы: Exists — включать указанные имена тегов; Equals — включать указанные имена тегов и значения (с учетом регистра); Contains — включать указанные имена тегов, у которых значения тегов содержат введенную строку (поиск подстроки, без учета регистра); Does not exist — исключать указанные имена тегов; Does not equal — исключать указанные имена тегов и значения (с учетом регистра); Does not contain — исключать указанные имена тегов, у которых значения тегов содержат введенную строку (поиск подстроки, без учета регистра). Для условий доступны два типа вычисления: And/Or — должны быть выполнены все условия, условия с одинаковым именем тега будут сгруппированы по условию Or; Or — достаточно выполнения одного условия. |
| Type of information | Выберите тип информации (numeric (unsigned), numeric (float), character и т. д.), по которому следует фильтровать значения элементов данных, которые должен передавать connector. Это поле доступно, если для Data type выбрано "Item values". |
| HTTP authentication | Выберите вариант аутентификации: None — аутентификация не используется; Basic — используется базовая аутентификация; NTLM — используется аутентификация NTLM (Windows NT LAN Manager); Kerberos — используется аутентификация Kerberos (см. также: Настройка Kerberos в Zabbix); Digest — используется аутентификация Digest; Bearer — используется аутентификация Bearer. |
| Username | Введите имя пользователя (до 255 символов). Поддерживаются пользовательские макросы. Это поле доступно, если для HTTP authentication выбрано "Basic", "NTLM", "Kerberos" или "Digest". |
| Password | Введите пароль пользователя (до 255 символов). Поддерживаются пользовательские макросы. Это поле доступно, если для HTTP authentication выбрано "Basic", "NTLM", "Kerberos" или "Digest". |
| Bearer token | Введите Bearer token. Поддерживаются пользовательские макросы. Это поле доступно и обязательно, если для HTTP authentication выбрано "Bearer". |
| Advanced configuration | Нажмите заголовок Advanced configuration, чтобы отобразить дополнительные параметры конфигурации (см. ниже). |
| Max records per message | Укажите максимальное количество значений или событий, которые можно передать в одном сообщении. |
| Concurrent sessions | Выберите количество процессов отправки, которые будут запущены для этого connector. Можно указать до 100 сеансов; значение по умолчанию — "1". |
| Attempts | Количество попыток передачи данных. Можно указать до 5 попыток; значение по умолчанию — "1". |
| Attempt interval | Укажите, сколько времени connector должен ждать после неудачной попытки передачи данных. Можно указать до 10s; значение по умолчанию — "5s". Это поле доступно, если для Attempts задано значение "2" или больше. Неудачными считаются попытки, при которых не удалось установить соединение или код HTTP-ответа не равен 200, 201, 202, 203, 204. Повторные попытки triggered в случае ошибок связи или если код HTTP-ответа не равен 200, 201, 202, 203, 204, 400, 401, 403, 404, 405, 415, 422. Перенаправления обрабатываются, поэтому 302 -> 200 считается успешным ответом; тогда как 302 -> 503 вызовет повторную попытку. |
| Timeout | Укажите тайм-аут сообщения (1-60 секунд, по умолчанию - 5 секунд). Поддерживаются суффиксы времени, например 30s, 1m. Поддерживаются пользовательские макросы. |
| HTTP proxy | Можно указать HTTP proxy в следующем формате:[protocol://][username[:password]@]proxy.example.com[:port]Поддерживаются пользовательские макросы. Необязательный префикс protocol:// можно использовать для указания альтернативных протоколов proxy (поддержка префикса протокола была добавлена в cURL 7.21.7). Если протокол не указан, proxy будет считаться HTTP proxy. По умолчанию будет использоваться порт 1080.Если HTTP proxy указан, proxy переопределит переменные окружения, связанные с proxy, такие как http_proxy, HTTPS_PROXY. Если не указан, proxy не будет переопределять переменные окружения, связанные с proxy. Введенное значение передается как есть, без проверки корректности.Также можно указать адрес SOCKS proxy. Если указать неверный протокол, connector не сможет передавать значения элементов данных или события из Zabbix. Обратите внимание, что с HTTP proxy поддерживается только простая аутентификация. |
| SSL verify peer | Установите флажок, чтобы проверить SSL-сертификат веб-сервера. Сертификат сервера будет автоматически взят из системного хранилища центров сертификации (CA). Расположение файлов CA можно переопределить с помощью параметра конфигурации Zabbix server или proxy SSLCALocation. |
| SSL verify host | Установите флажок, чтобы проверить, совпадает ли поле Common Name или поле Subject Alternate Name в сертификате веб-сервера. Это задает опцию cURL CURLOPT_SSL_VERIFYHOST. |
| SSL certificate file | Имя файла SSL-сертификата, используемого для аутентификации клиента. Файл сертификата должен быть в формате PEM1. Поддерживаются пользовательские макросы. Если файл сертификата также содержит закрытый ключ, оставьте поле SSL key file пустым. Если ключ зашифрован, укажите пароль в поле SSL key password. Каталог, содержащий этот файл, задается параметром конфигурации Zabbix server или proxy SSLCertLocation. |
| SSL key file | Имя файла закрытого SSL-ключа, используемого для аутентификации клиента. Файл закрытого ключа должен быть в формате PEM1. Поддерживаются пользовательские макросы. Каталог, содержащий этот файл, задается параметром конфигурации Zabbix server или proxy SSLKeyLocation. |
| SSL key password | Пароль файла закрытого SSL-ключа. Поддерживаются пользовательские макросы. |
| Description | Введите описание connector. |
| Enabled | Установите флажок, чтобы включить connector. |
Когда Kafka connector настроен с разделенным запятыми списком адресов bootstrap broker (например Kafka.URL=kafka1.example.com:9093,kafka2.example.com:9093), клиент Kafka подключается к тому broker(ам), который отвечает первым, и использует его метаданные кластера.
Если список содержит адреса из разных кластеров Kafka, будет использоваться только самый быстро отвечающий кластер, а остальные адреса будут зарегистрированы как недоступные; в результате могут появляться предупреждения при запуске, подобные следующему, даже если connector подключен:
kafka cluster connected, but broker(s) "kafka1.example.com:9093, kafka2.example.com:9093" unavailable; will retry on message send if active brokers fail
В некоторых средах (частные сети, контейнерные сети или нестандартные настройки DNS/hosts) имена узлов или IP-адреса могут разрешаться в loopback-адреса (например 127.0.0.1/localhost) или нормализоваться клиентом, из-за чего такие предупреждения могут вводить в заблуждение.
Чтобы уменьшить путаницу, убедитесь, что все адреса Kafka.URL относятся к одному и тому же кластеру Kafka, проверьте разрешение DNS с узла, на котором запущен connector, и advertised.listeners broker'ов, а также отдавайте предпочтение адресам, которые разрешаются в объявленный адрес broker'а.
Протокол
Обмен данными между сервером и получателем выполняется по HTTP с использованием REST API, NDJSON, "Content-Type: application/x-ndjson".
Подробнее см. в разделе Протокол экспорта JSON с разделением по символу новой строки.
Запрос сервера
Пример потоковой передачи значений элементов данных:
POST /v1/history HTTP/1.1
Host: localhost:8080
Accept: */*
Accept-Encoding: deflate, gzip, br, zstd
Content-Length: 628
Content-Type: application/x-ndjson
{"host":{"host":"Zabbix server","name":"Zabbix server"},"groups":["Zabbix servers"],"item_tags":[{"tag":"foo","value":"test"}],"itemid":44457,"name":"foo","clock":1673454303,"ns":800155804,"value":0,"type":3}
{"host":{"host":"Zabbix server","name":"Zabbix server"},"groups":["Zabbix servers"],"item_tags":[{"tag":"foo","value":"test"}],"itemid":44457,"name":"foo","clock":1673454303,"ns":832290669,"value":1,"type":3}
{"host":{"host":"Zabbix server","name":"Zabbix server"},"groups":["Zabbix servers"],"item_tags":[{"tag":"bar","value":"test"}],"itemid":44458,"name":"bar","clock":1673454303,"ns":867770366,"value":123,"type":3}
Пример потоковой передачи событий:
POST /v1/events HTTP/1.1
Host: localhost:8080
Accept: */*
Accept-Encoding: deflate, gzip, br, zstd
Content-Length: 333
Content-Type: application/x-ndjson
{"clock":1673454303,"ns":800155804,"value":1,"eventid":5,"name":"trigger for foo being 0","severity":0,"hosts":[{"host":"Zabbix server","name":"Zabbix server"}],"groups":["Zabbix servers"],"tags":[{"tag":"foo_trig","value":"test"},{"tag":"foo","value":"test"}]}
{"clock":1673454303,"ns":832290669,"value":0,"eventid":6,"p_eventid":5}
Ответ получателя
Ответ состоит из кода состояния HTTP-ответа и полезной нагрузки JSON. Код состояния HTTP-ответа должен быть "200", "201", "202", "203" или "204" для запросов, которые были успешно обработаны, в противном случае — для неуспешных запросов.
Пример успешного ответа:
HTTP/1.1 200 OK
Content-Type: application/json
X-Content-Type-Options: nosniff
Date: Tue, 21 Apr 2026 10:13:04 GMT
Content-Length: 23
{"response":"success"}
Пример с ошибками:
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json
X-Content-Type-Options: nosniff
Date: Tue, 21 Apr 2026 12:15:01 GMT
Content-Length: 55
{"error":"invalid character '{' after top-level value"}