2 Streaming an externe Systeme

Übersicht

Es ist möglich, Datenpunktwerte und Ereignisse aus Zabbix über HTTP an externe Systeme zu streamen (siehe Protokolldetails).

Der Tag-Filter kann verwendet werden, um Teilmengen von Datenpunktwerten oder Ereignissen zu streamen.

Zwei Zabbix-Server-Prozesstypen sind für das Daten-Streaming verantwortlich: connector manager und connector worker. Ein internes Zabbix-Datenpunkt zabbix[connector_queue] ermöglicht die Überwachung der Anzahl der in die Connector-Warteschlange eingereihten Werte.

Konfiguration

Die folgenden Schritte sind erforderlich, um das Streaming von Daten an ein externes System zu konfigurieren:

1. Richten Sie ein Remote-System für den Empfang von Daten von Zabbix ein. Zu diesem Zweck stehen die folgenden Tools zur Verfügung:

• Ein Beispiel für einen einfachen Empfänger, der die empfangenen Informationen in den Dateien events.ndjson und history.ndjson protokolliert.
• Kafka connector for Zabbix server – ein schlanker, in Go geschriebener Server, der dafür ausgelegt ist, Datenpunktwerte und Ereignisse von einem Zabbix-Server an einen Kafka-Broker weiterzuleiten.

2. Legen Sie die erforderliche Anzahl von Connector-Workern in Zabbix fest, indem Sie den Parameter StartConnectors in zabbix_server.conf anpassen. Die Anzahl der Connector-Worker sollte der in der Zabbix-Frontend konfigurierten Connector-Anzahl entsprechen (oder diese überschreiten, wenn mehr als eine gleichzeitige Sitzung konfiguriert ist). Starten Sie anschließend den Zabbix-Server neu.

3. Konfigurieren Sie einen neuen Connector im Zabbix-Frontend (Administration > General > Connectors) und laden Sie den Server-Cache mit dem Befehl zabbix_server -R config_cache_reload neu.

Pflichtfelder sind mit einem Sternchen gekennzeichnet.

Wenn der Kafka-Connector mit einer durch Kommas getrennten Liste von Bootstrap-Brokeradressen konfiguriert ist (zum Beispiel Kafka.URL=kafka1.example.com:9093,kafka2.example.com:9093), stellt der Kafka-Client eine Verbindung zu dem oder den Brokern her, die zuerst antworten, und verwendet deren Cluster-Metadaten. Wenn die Liste Adressen aus verschiedenen Kafka-Clustern enthält, wird nur der am schnellsten antwortende Cluster verwendet und andere Adressen werden als nicht verfügbar protokolliert. Daher können beim Start Warnungen wie die folgende erscheinen, obwohl der Connector verbunden ist:

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

In einigen Umgebungen (privaten Netzwerken, Container-Netzwerken oder bei nicht standardmäßigen DNS-/Hosts-Konfigurationen) können Hostnamen oder IP-Adressen in Loopback-Adressen (zum Beispiel 127.0.0.1/localhost) aufgelöst oder vom Client normalisiert werden, wodurch solche Warnungen irreführend sein können. Um Verwirrung zu vermeiden, stellen Sie sicher, dass alle Kafka.URL-Adressen zum selben Kafka-Cluster gehören, überprüfen Sie die DNS-Auflösung vom Connector-Host sowie die advertised.listeners der Broker und bevorzugen Sie Adressen, die in die vom Broker angekündigte Adresse aufgelöst werden.

Protokoll

Die Kommunikation zwischen dem Server und dem Empfänger erfolgt über HTTP unter Verwendung der REST-API, NDJSON, „Content-Type: application/x-ndjson“.

Weitere Einzelheiten finden Sie unter Newline-delimited JSON export protocol.

Server-Anfrage

Beispiel für das Streamen von Datenpunkt-Werten:

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}

Beispiel für das Streamen von Ereignissen:

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}

Antwort des Empfängers

Die Antwort besteht aus dem HTTP-Antwortstatuscode und der JSON-Nutzlast. Der HTTP-Antwortstatuscode muss für erfolgreich verarbeitete Anfragen "200", "201", "202", "203" oder "204" sein, andernfalls gilt die Anfrage als fehlgeschlagen.

Beispiel für einen Erfolg:

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

Beispiel mit Fehlern:

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