2 Strumieniowanie do systemów zewnętrznych

Przegląd

Możliwe jest strumieniowanie wartości pozycji i zdarzeń z Zabbix do zewnętrznych systemów przez HTTP (zobacz szczegóły protokołu).

Filtr tagów może być używany do strumieniowania podzbiorów wartości pozycji lub zdarzeń.

Za strumieniowanie danych odpowiadają dwa typy procesów serwera Zabbix: connector manager i connector worker. Wewnętrzna pozycja Zabbix zabbix[connector_queue] umożliwia monitorowanie liczby wartości umieszczonych w kolejce connector.

Konfiguracja

Aby skonfigurować przesyłanie danych do systemu zewnętrznego, należy wykonać następujące czynności:

1. Skonfiguruj system zdalny do odbierania danych z Zabbix. W tym celu dostępne są następujące narzędzia:

  • Przykład prostego odbiornika, który zapisuje odebrane informacje w plikach events.ndjson i history.ndjson.
  • Kafka connector for Zabbix server - lekki serwer napisany w języku Go, przeznaczony do przekazywania wartości pozycji i zdarzeń z serwera Zabbix do brokera Kafka.

2. Ustaw wymaganą liczbę procesów roboczych connectora w Zabbix, dostosowując parametr StartConnectors w pliku zabbix_server.conf. Liczba procesów roboczych connectora powinna odpowiadać skonfigurowanej liczbie connectorów w frontendzie Zabbix (lub ją przekraczać, jeśli liczba jednoczesnych sesji jest większa niż 1). Następnie uruchom ponownie serwer Zabbix.

3. Skonfiguruj nowy connector w frontendzie Zabbix (Administracja > Ogólne > Connectors) i przeładuj pamięć podręczną serwera za pomocą polecenia zabbix_server -R config_cache_reload.

Pola wymagane są oznaczone gwiazdką.

Parametr Opis
Nazwa Wprowadź nazwę connectora.
Typ danych Wybierz typ danych do przesyłania:
Wartości pozycji - przesyłaj wartości pozycji z Zabbix do systemów zewnętrznych;
Zdarzenia - przesyłaj zdarzenia z Zabbix do systemów zewnętrznych.
URL Wprowadź URL odbiornika. Obsługiwane są makra użytkownika.
Filtr tagów Eksportuj tylko wartości pozycji lub zdarzenia pasujące do filtra tagów. Jeśli filtr nie zostanie ustawiony, eksportowane będzie wszystko.
Można uwzględniać lub wykluczać określone tagi i wartości tagów. Można ustawić kilka warunków. Dopasowywanie nazw tagów zawsze uwzględnia wielkość liter.

Dla każdego warunku dostępne są następujące operatory:
Istnieje - uwzględnij określone nazwy tagów;
Równa się - uwzględnij określone nazwy i wartości tagów (z uwzględnieniem wielkości liter);
Zawiera - uwzględnij określone nazwy tagów, których wartości zawierają wprowadzony ciąg (dopasowanie podciągu, bez uwzględniania wielkości liter);
Nie istnieje - wyklucz określone nazwy tagów;
Nie równa się - wyklucz określone nazwy i wartości tagów (z uwzględnieniem wielkości liter);
Nie zawiera - wyklucz określone nazwy tagów, których wartości zawierają wprowadzony ciąg (dopasowanie podciągu, bez uwzględniania wielkości liter).

Dostępne są dwa typy obliczania warunków:
And/Or - wszystkie warunki muszą być spełnione, a warunki mające tę samą nazwę tagu zostaną połączone warunkiem Or;
Or - wystarczy spełnienie jednego warunku.
Typ informacji Wybierz typ informacji (liczbowy (bez znaku), liczbowy (zmiennoprzecinkowy), znakowy itd.), według którego mają być filtrowane wartości pozycji przesyłane przez connector.
To pole jest dostępne, jeśli dla opcji Typ danych ustawiono wartość „Wartości pozycji”.
Uwierzytelnianie HTTP Wybierz opcję uwierzytelniania:
Brak - uwierzytelnianie nie jest używane;
Basic - używane jest uwierzytelnianie podstawowe;
NTLM - używane jest uwierzytelnianie NTLM (Windows NT LAN Manager);
Kerberos - używane jest uwierzytelnianie Kerberos (zobacz także: Konfigurowanie Kerberos z Zabbix);
Digest - używane jest uwierzytelnianie Digest;
Bearer - używane jest uwierzytelnianie Bearer.
Nazwa użytkownika Wprowadź nazwę użytkownika (do 255 znaków). Obsługiwane są makra użytkownika.
To pole jest dostępne, jeśli dla opcji Uwierzytelnianie HTTP ustawiono wartość „Basic”, „NTLM”, „Kerberos” lub „Digest”.
Hasło Wprowadź hasło użytkownika (do 255 znaków). Obsługiwane są makra użytkownika.
To pole jest dostępne, jeśli dla opcji Uwierzytelnianie HTTP ustawiono wartość „Basic”, „NTLM”, „Kerberos” lub „Digest”.
Token Bearer Wprowadź token Bearer. Obsługiwane są makra użytkownika.
To pole jest dostępne i wymagane, jeśli dla opcji Uwierzytelnianie HTTP ustawiono wartość „Bearer”.
Konfiguracja zaawansowana Kliknij nagłówek Konfiguracja zaawansowana, aby wyświetlić zaawansowane opcje konfiguracji (zobacz poniżej).
Maksymalna liczba rekordów na wiadomość Określ maksymalną liczbę wartości lub zdarzeń, które mogą być przesyłane w jednej wiadomości.
Jednoczesne sesje Wybierz liczbę procesów nadawczych uruchamianych dla tego connectora. Można określić do 100 sesji; wartość domyślna to „1”.
Liczba prób Liczba prób przesłania danych. Można określić do 5 prób; wartość domyślna to „1”.
Odstęp między próbami Określ, jak długo connector powinien czekać po nieudanej próbie przesłania danych. Można określić maksymalnie 10 s; wartość domyślna to „5 s”.
To pole jest dostępne, jeśli dla opcji Liczba prób ustawiono wartość „2” lub większą.
Nieudane próby to takie, podczas których nie udało się nawiązać połączenia lub kod odpowiedzi HTTP nie wynosi 200, 201, 202, 203 ani 204. Ponowne próby są uruchamiane w przypadku błędów komunikacji lub gdy kod odpowiedzi HTTP nie wynosi 200, 201, 202, 203, 204, 400, 401, 403, 404, 405, 415 ani 422. Przekierowania są obsługiwane, dlatego 302 -> 200 jest odpowiedzią pozytywną, natomiast 302 -> 503 spowoduje ponowną próbę.
Limit czasu Określ limit czasu wiadomości (1-60 sekund, domyślnie - 5 sekund).
Obsługiwane są przyrostki czasu (np. 30s, 1m). Obsługiwane są makra użytkownika.
Proxy HTTP Można określić proxy HTTP w następującym formacie:
[protocol://][username[:password]@]proxy.example.com[:port]
Obsługiwane są makra użytkownika.

Opcjonalny prefiks protocol:// może służyć do określenia alternatywnych protokołów proxy (obsługa prefiksu protokołu została dodana w cURL 7.21.7). Jeśli protokół nie zostanie określony, proxy będzie traktowane jako proxy HTTP. Domyślnie używany będzie port 1080.

Jeśli określono Proxy HTTP, proxy zastąpi zmienne środowiskowe związane z proxy, takie jak http_proxy i HTTPS_PROXY. Jeśli nie zostanie określone, proxy nie zastąpi zmiennych środowiskowych związanych z proxy. Wprowadzona wartość jest przekazywana bez zmian, bez sprawdzania poprawności.
Można również wprowadzić adres proxy SOCKS. Jeśli określisz nieprawidłowy protokół, connector nie będzie mógł przesyłać wartości pozycji ani zdarzeń z Zabbix.

Należy pamiętać, że w przypadku proxy HTTP obsługiwane jest tylko proste uwierzytelnianie.
Weryfikuj peer SSL Zaznacz pole wyboru, aby zweryfikować certyfikat SSL serwera WWW.
Certyfikat serwera jest weryfikowany względem certyfikatów zaufanych urzędów certyfikacji (CA) znajdujących się w systemowej lokalizacji CA. Lokalizację plików CA można zmienić za pomocą parametru konfiguracji serwera Zabbix lub proxy SSLCALocation.
Weryfikuj host SSL Zaznacz pole wyboru, aby zweryfikować, czy pole Common Name lub Subject Alternate Name certyfikatu serwera WWW pasuje.
Ustawia to opcję cURL CURLOPT_SSL_VERIFYHOST.
Plik certyfikatu SSL Nazwa pliku certyfikatu SSL używanego do uwierzytelniania klienta. Plik certyfikatu musi być w formacie PEM1. Obsługiwane są makra użytkownika.
Jeśli plik certyfikatu zawiera również klucz prywatny, pozostaw pole Plik klucza SSL puste. Jeśli klucz jest zaszyfrowany, określ hasło w polu Hasło klucza SSL. Katalog zawierający ten plik jest określany przez parametr konfiguracji serwera Zabbix lub proxy SSLCertLocation.
Plik klucza SSL Nazwa pliku prywatnego klucza SSL używanego do uwierzytelniania klienta. Plik klucza prywatnego musi być w formacie PEM1. Obsługiwane są makra użytkownika.
Katalog zawierający ten plik jest określany przez parametr konfiguracji serwera Zabbix lub proxy SSLKeyLocation.
Hasło klucza SSL Hasło pliku prywatnego klucza SSL. Obsługiwane są makra użytkownika.
Opis Wprowadź opis connectora.
Włączony Zaznacz pole wyboru, aby włączyć connector.

Jeśli Kafka connector zostanie skonfigurowany z rozdzielaną przecinkami listą adresów brokerów rozruchowych (na przykład Kafka.URL=kafka1.example.com:9093,kafka2.example.com:9093), klient Kafka połączy się z brokerem lub brokerami, które odpowiedzą jako pierwsze, i użyje ich metadanych klastra. Jeśli lista zawiera adresy z różnych klastrów Kafka, używany będzie tylko klaster odpowiadający najszybciej, a pozostałe adresy zostaną zapisane w dzienniku jako niedostępne; w rezultacie mogą pojawić się ostrzeżenia podczas uruchamiania, takie jak poniższe, nawet jeśli connector jest połączony:

kafka cluster connected, but broker(s) "kafka1.example.com:9093, kafka2.example.com:9093" unavailable; will retry on message send if active brokers fail 

W niektórych środowiskach (sieci prywatne, sieci kontenerów lub niestandardowe konfiguracje DNS/hosts) nazwy hostów lub adresy IP mogą być rozwiązywane do adresów pętli zwrotnej (na przykład 127.0.0.1/localhost) albo normalizowane przez klienta, co może powodować, że takie ostrzeżenia będą mylące. Aby ograniczyć niejasności, upewnij się, że wszystkie adresy Kafka.URL należą do tego samego klastra Kafka, sprawdź rozwiązywanie DNS z hosta connectora oraz wartości advertised.listeners brokerów i preferuj adresy rozwiązywane do adresu rozgłaszanego przez brokera.

Protokół

Komunikacja między serwerem a odbiorcą odbywa się przez HTTP z użyciem REST API, NDJSON, „Content-Type: application/x-ndjson”.

Więcej informacji można znaleźć w protokole eksportu JSON rozdzielanego znakami nowej linii.

Żądanie serwera

Przykład strumieniowania wartości pozycji:

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}

Przykład strumieniowania zdarzeń:

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}
Odpowiedź odbiorcy

Odpowiedź składa się z kodu statusu odpowiedzi HTTP oraz ładunku JSON. Kod statusu odpowiedzi HTTP musi mieć wartość "200", "201", "202", "203" lub "204" dla żądań, które zostały obsłużone pomyślnie, inny dla żądań zakończonych niepowodzeniem.

Przykład powodzenia:

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"}

Przykład z błędami:

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"}