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

概要

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

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

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

設定

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

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

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

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 で実行する 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_proxyHTTPS_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"}