2 外部システムへのストリーミング

概要

HTTP経由で、Zabbixから外部システムへアイテムの値およびイベントをストリーミングできます(プロトコルの詳細を参照)。

タグフィルターを使用して、アイテムの値またはイベントのサブセットをストリーミングできます。

データストリーミングを担当するZabbixサーバーのプロセスタイプは、connector managerconnector worker の2つです。 Zabbix内部アイテム zabbix[connector_queue] を使用すると、コネクターキューに追加された値の件数を監視できます。

設定

外部システムへのデータストリーミングを設定するには、次の手順が必要です。

1. Zabbix からデータを受信するリモートシステムを用意します。
この目的のために、次のツールを利用できます。

  • 受信した情報を events.ndjson および history.ndjson ファイルに記録する、シンプルな receiver のサンプル。
  • Kafka connector for Zabbix server - Zabbix サーバーから Kafka ブローカーへアイテム値とイベントを転送するよう設計された、Go で書かれた軽量なサーバー。

2. zabbix_server.confStartConnectors パラメータを調整して、Zabbix で必要な数の connector worker を設定します。
connector worker の数は、Zabbix Webインターフェースで設定した connector 数と一致している必要があります(同時セッション数が 1 より多い場合は、それ以上にしてください)。
その後、Zabbix サーバーを再起動します。

3. Zabbix Webインターフェース(Administration > General > Connectors)で新しい connector を設定し、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 - タグ値に入力文字列を含む指定タグ名を除外します(部分一致、大文字小文字を区別しない)。

条件の計算方法は 2 種類あります:
And/Or - すべての条件を満たす必要があります。同じタグ名を持つ条件は Or 条件でグループ化されます;
Or - いずれか 1 つの条件を満たせば十分です。
Type of information connector がストリームするアイテム値をフィルタリングするための情報タイプ(numeric (unsigned), numeric (float), character など)を選択します。
このフィールドは Data type が "Item values" に設定されている場合に使用できます。
HTTP authentication 認証オプションを選択します:
None - 認証を使用しません;
Basic - 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 1 メッセージ内でストリームできる値またはイベントの最大数を指定します。
Concurrent sessions この connector で実行する送信プロセス数を選択します。最大 100 セッションまで指定でき、デフォルト値は "1" です。
Attempts データストリーミングの試行回数です。最大 5 回まで指定でき、デフォルト値は "1" です。
Attempt interval データストリーミングの試行が失敗した後、connector が待機する時間を指定します。最大 10s まで指定でき、デフォルト値は "5s" です。
このフィールドは Attempts が "2" 以上に設定されている場合に使用できます。
失敗した試行とは、接続の確立に失敗した場合、または HTTP 応答コードが 200, 201, 202, 203, 204 以外の場合を指します。通信エラー、または HTTP 応答コードが 200, 201, 202, 203, 204, 400, 401, 403, 404, 405, 415, 422 以外の場合に再試行が trigger されます。リダイレクトは追跡されるため、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 は http_proxyHTTPS_PROXY などの proxy 関連環境変数を上書きします。指定されていない場合、proxy は proxy 関連環境変数を上書きしません。入力された値はそのまま渡され、妥当性チェックは行われません。
SOCKS proxy アドレスを入力することもできます。誤ったプロトコルを指定すると、connector は Zabbix からアイテム値またはイベントをストリームできません。

HTTP proxy では簡易認証のみがサポートされることに注意してください。
SSL verify peer チェックボックスをオンにすると、Web サーバーの SSL 証明書を検証します。
サーバー証明書は、システム全体の証明機関(CA)ロケーションから自動的に取得されます。Zabbix サーバーまたは proxy の設定パラメータ SSLCALocation を使用して CA ファイルの場所を上書きできます。
SSL verify host チェックボックスをオンにすると、Web サーバー証明書の Common Name フィールドまたは Subject Alternate Name フィールドが一致することを検証します。
これにより CURLOPT_SSL_VERIFYHOST cURL オプションが設定されます。
SSL certificate file クライアント認証に使用する SSL 証明書ファイル名です。証明書ファイルは PEM1 形式である必要があります。ユーザーマクロがサポートされています。
証明書ファイルに秘密鍵も含まれている場合は、SSL key file フィールドを空欄にしてください。鍵が暗号化されている場合は、SSL key password フィールドにパスワードを指定します。このファイルを含むディレクトリは、Zabbix サーバーまたは proxy の設定パラメータ SSLCertLocation で指定されます。
SSL key file クライアント認証に使用する SSL 秘密鍵ファイル名です。秘密鍵ファイルは PEM1 形式である必要があります。ユーザーマクロがサポートされています。
このファイルを含むディレクトリは、Zabbix サーバーまたは 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 がループバックアドレス(例: 127.0.0.1/localhost)に解決されたり、クライアント側で正規化されたりするため、このような警告は誤解を招くことがあります。
混乱を減らすため、すべての Kafka.URL アドレスが同じ Kafka クラスタに属していることを確認し、connector ホストからの DNS 解決と broker の advertised.listeners を検証し、broker の advertised アドレスに解決されるアドレスを優先してください。

プロトコル

サーバーとレシーバー間の通信は、REST API、NDJSON、"Content-Type: application/x-ndjson" を使用してHTTP経由で行われます。

詳細については、改行区切り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"}