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 worker в Zabbix, изменив параметр StartConnectors в zabbix_server.conf. Количество процессов connector worker должно соответствовать (или превышать, если число одновременных сессий больше 1) настроенному количеству коннекторов в веб-интерфейсе Zabbix. Затем перезапустите сервер Zabbix.

3. Настроить новый коннектор в веб-интерфейсе Zabbix (Administration > General > Connectors) и перезагрузить кэш сервера командой zabbix_server -R config_cache_reload.

Обязательные поля отмечены звёздочкой.

Параметр Описание
Name Введите имя коннектора.
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 и т. д.), по которому будут фильтроваться значения элементов данных, передаваемые коннектором.
Это поле доступно, если Data type установлено в "Item values".
HTTP authentication Выберите вариант аутентификации:
None — аутентификация не используется;
Basic — используется базовая аутентификация;
NTLM — используется аутентификация NTLM (Windows NT LAN Manager);
Kerberos — используется аутентификация Kerberos (см. также: Configuring Kerberos with 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 Выберите количество процессов отправки, которые будут запущены для этого коннектора. Можно указать до 100 сессий; значение по умолчанию — "1".
Attempts Количество попыток потоковой передачи данных. Можно указать до 5 попыток; значение по умолчанию — "1".
Attempt interval Укажите, сколько времени коннектор должен ждать после неудачной попытки передачи данных. Можно указать до 10s; значение по умолчанию — "5s".
Это поле доступно, если Attempts установлено в "2" или больше.
Неудачными считаются попытки, при которых не удалось установить соединение, либо код HTTP-ответа не равен 200, 201, 202, 203, 204. Повторные попытки запускаются в случае ошибок связи или если код 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-прокси в следующем формате:
[protocol://][username[:password]@]proxy.example.com[:port]
Поддерживаются пользовательские макросы.

Необязательный префикс protocol:// может использоваться для указания альтернативных протоколов прокси (поддержка префикса протокола добавлена в cURL 7.21.7). Если протокол не указан, прокси будет рассматриваться как HTTP-прокси. По умолчанию будет использоваться порт 1080.

Если указан HTTP proxy, прокси переопределит связанные с прокси переменные окружения, такие как http_proxy, HTTPS_PROXY. Если не указан, прокси не будет переопределять связанные с прокси переменные окружения. Введённое значение передаётся как есть, без какой-либо проверки корректности.
Также можно указать адрес SOCKS-прокси. Если указан неверный протокол, соединение завершится ошибкой, и элемент данных станет неподдерживаемым.

Обратите внимание, что для HTTP-прокси поддерживается только простая аутентификация.
SSL verify peer Установите флажок, чтобы проверять SSL-сертификат веб-сервера.
Сертификат сервера будет автоматически взят из системного расположения центра сертификации (CA). Вы можете переопределить расположение файлов CA с помощью параметра конфигурации сервера Zabbix или прокси 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 или прокси SSLCertLocation.
SSL key file Имя файла закрытого SSL-ключа, используемого для аутентификации клиента. Файл закрытого ключа должен быть в формате PEM1. Поддерживаются пользовательские макросы.
Каталог, содержащий этот файл, задаётся параметром конфигурации сервера Zabbix или прокси SSLKeyLocation.
SSL key password Пароль файла закрытого SSL-ключа. Поддерживаются пользовательские макросы.
Description Введите описание коннектора.
Enabled Установите флажок, чтобы включить коннектор.

Когда Kafka connector настроен со списком адресов bootstrap-брокеров, разделённых запятыми (например, Kafka.URL=kafka1.example.com:9093,kafka2.example.com:9093), клиент Kafka подключается к брокеру(ам), ответившему(им) первым, и использует их метаданные кластера. Если список содержит адреса из разных кластеров Kafka, будет использоваться только кластер, ответивший быстрее всего, а остальные адреса будут записаны в журнал как недоступные; в результате при запуске могут появляться предупреждения, подобные следующему, даже если коннектор подключён:

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 с узла, на котором работает коннектор, а также параметр advertised.listeners брокеров, и по возможности используйте адреса, которые разрешаются в advertised-адрес брокера.

Протокол

Обмен данными между сервером и получателем выполняется по 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" для запросов, которые были успешно обработаны, в противном случае — для неуспешных запросов.

Пример успешного ответа:

localhost:8080/v1/history": HTTP/1.1 200 OK
Date: Wed, 11 Jan 2023 16:40:30 GMT
Content-Length: 0

Пример с ошибками:

localhost:8080/v1/history": HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json
Date: Wed, 11 Jan 2023 17:07:36 GMT
Content-Length: 55

{"error":"invalid character '{' after top-level value"}