2 外部システムへのストリーミング
概要
Zabbix から外部システムへ、アイテムの値とイベントを HTTP 経由でストリーミングすることができます(プロトコルの詳細を参照)。
タグフィルターを使用して、アイテムの値またはイベントのサブセットをストリーミングできます。
データストリーミングを担当する Zabbix サーバーのプロセスタイプは 2 つあります: connector manager と connector worker。
Zabbix の内部アイテム zabbix[connector_queue] を使用すると、connector キューに投入された値の数を監視できます。
設定
外部システムへのデータストリーミングを設定するには、次の手順が必要です。
1. Zabbix からデータを受信するリモートシステムを用意します。
この目的のために、次のツールを利用できます。
- 受信した情報を
events.ndjsonおよびhistory.ndjsonファイルに記録する、シンプルな receiver のサンプル。 - Kafka connector for Zabbix server - Go で書かれた軽量なサーバーで、Zabbix サーバーから Kafka ブローカーへアイテム値と障害を転送するよう設計されています。
2. zabbix_server.conf の StartConnectors パラメータを調整して、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 で実行する sender process の数を選択します。最大 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 以外の場合に再試行がトリガーされます。リダイレクトは追従されるため、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 プロキシアドレスを入力することもできます。誤ったプロトコルを指定すると、connector は Zabbix からアイテム値または障害をストリームできません。 HTTP proxy では簡易認証のみがサポートされることに注意してください。 |
| SSL verify peer | チェックボックスをオンにすると、Web サーバーの SSL 証明書を検証します。 サーバー証明書はシステム全体の証明機関(CA)ロケーションから自動的に取得されます。Zabbix サーバーまたはプロキシの設定パラメータ 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 サーバーまたはプロキシの設定パラメータ SSLCertLocation で指定されます。 |
| SSL key file | クライアント認証に使用する SSL 秘密鍵ファイル名です。秘密鍵ファイルは PEM1 形式である必要があります。ユーザーマクロがサポートされています。 このファイルを含むディレクトリは、Zabbix サーバーまたはプロキシの設定パラメータ 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 address に解決されるアドレスを優先してください。
プロトコル
サーバーと受信側間の通信は、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"}