Zabbixから外部システムへHTTP経由でアイテム値やイベントをストリーミングすることができます(プロトコルの詳細を参照)。
タグフィルターを使用して、アイテム値やイベントのサブセットをストリーミングすることができます。
データストリーミングには、2つのZabbixサーバープロセスconnector managerとconnector workerが関与します。 Zabbixの内部アイテムzabbix[connector_queue]を使用して、コネクタキューにエンキューされた値の数を監視できます。
外部システムへのデータストリーミングを設定するには、以下の手順が必要です。
1. Zabbixからデータを受信するためのリモートシステムをセットアップします。 この目的のために、以下のツールが利用可能です。
events.ndjsonおよびhistory.ndjsonファイルに記録するシンプルな受信プログラムの例。2. zabbix_server.confのStartConnectorsパラメータを調整して、Zabbixで必要な数のコネクタワーカーを設定します。 コネクタワーカーの数は、Zabbixフロントエンドで設定されたコネクタ数と一致する必要があります(または同時セッション数が1より多い場合はそれ以上に設定します)。 その後、Zabbixサーバーを再起動します。
3. Zabbixフロントエンドで新しいコネクタを設定します(管理 > 一般 > コネクタ)、zabbix_server -R config_cache_reloadコマンドでサーバーキャッシュをリロードします。

必須フィールドはアスタリスクでマークされています。
| パラメータ | 説明 |
|---|---|
| 名前 | コネクタ名を入力します。 |
| データ型 | ストリーミングするデータ型を選択します: アイテム値 - Zabbixから外部システムへアイテム値をストリーミング; イベント - Zabbixから外部システムへイベントをストリーミング。 |
| URL | 受信プログラムのURLを入力します。ユーザーマクロがサポートされています。 |
| タグフィルタ | タグフィルタに一致するアイテム値またはイベントのみをエクスポートします。設定しない場合はすべてをエクスポートします。 特定のタグやタグ値を含めたり除外したりすることができます。複数の条件を設定できます。タグ名の一致は常に大文字小文字を区別します。 各条件にはいくつかの演算子があります: 存在する - 指定したタグ名を含める; 等しい - 指定したタグ名と値を含める(大文字小文字を区別); 含む - タグ値が入力した文字列を含むタグ名を含める(部分一致、大文字小文字を区別しない); 存在しない - 指定したタグ名を除外する; 等しくない - 指定したタグ名と値を除外する(大文字小文字を区別); 含まない - タグ値が入力した文字列を含むタグ名を除外する(部分一致、大文字小文字を区別しない)。 条件の計算タイプは2つあります: And/Or - すべての条件を満たす必要があり、同じタグ名の条件はOr条件でグループ化されます; Or - いずれか1つの条件を満たせば十分です。 |
| 情報の型 | コネクタがストリーミングするアイテム値をフィルタするための情報の型(数値(符号なし)、数値(浮動小数点)、文字列など)を選択します。 このフィールドはデータ型が「アイテム値」に設定されている場合に利用できます。 |
| HTTP認証 | 認証オプションを選択します: なし - 認証を使用しない; Basic - Basic認証を使用; NTLM - NTLM(Windows NT LAN Manager)認証を使用; Kerberos - Kerberos認証を使用(参考: ZabbixでのKerberos設定); Digest - Digest認証を使用; Bearer - Bearer認証を使用。 |
| ユーザー名 | ユーザー名(最大255文字)を入力します。ユーザーマクロがサポートされています。 このフィールドはHTTP認証が「Basic」「NTLM」「Kerberos」「Digest」に設定されている場合に利用できます。 |
| パスワード | ユーザーパスワード(最大255文字)を入力します。ユーザーマクロがサポートされています。 このフィールドはHTTP認証が「Basic」「NTLM」「Kerberos」「Digest」に設定されている場合に利用できます。 |
| Bearerトークン | Bearerトークンを入力します。ユーザーマクロがサポートされています。 このフィールドはHTTP認証が「Bearer」に設定されている場合に利用でき、必須です。 |
| 詳細設定 | 詳細設定ラベルをクリックすると詳細設定オプションが表示されます(下記参照)。 |
| メッセージあたりの最大レコード数 | 1つのメッセージ内でストリーミングできる値またはイベントの最大数を指定します。 |
| 同時セッション数 | このコネクタで実行する送信プロセスの数を選択します。最大100セッションまで指定でき、デフォルト値は「1」です。 |
| 試行回数 | データストリーミングの試行回数。最大5回まで指定でき、デフォルト値は「1」です。 |
| 試行間隔 | データストリーミングが失敗した場合にコネクタが待機する時間を指定します。最大10秒まで指定でき、デフォルト値は「5秒」です。 このフィールドは試行回数が「2」以上に設定されている場合に利用できます。 失敗した試行とは、接続の確立に失敗した場合、またはHTTPレスポンスコードが200、201、202、203、204でない場合です。通信エラーやHTTPレスポンスコードが200、201、202、203、204、400、401、403、404、405、415、422でない場合に再試行が行われます。リダイレクトは追従されるため、302→200は正常応答ですが、302→503は再試行が行われます。 |
| タイムアウト | メッセージのタイムアウトを指定します(1~60秒、デフォルトは5秒)。 30s、1mなどの時間サフィックスがサポートされています。ユーザーマクロがサポートされています。 |
| HTTPプロキシ | 以下の形式で使用するHTTPプロキシを指定できます:[protocol://][username[:password]@]proxy.example.com[:port]ユーザーマクロがサポートされています。 オプションの protocol://プレフィックスを使用して、代替プロキシプロトコルを指定できます(プロトコルプレフィックスのサポートはcURL 7.21.7で追加されました)。プロトコルを指定しない場合、プロキシはHTTPプロキシとして扱われます。デフォルトでは1080ポートが使用されます。HTTPプロキシが指定されている場合、プロキシは http_proxy、HTTPS_PROXYなどのプロキシ関連の環境変数を上書きします。指定しない場合、プロキシはプロキシ関連の環境変数を上書きしません。入力された値はそのまま渡され、整合性チェックは行われません。SOCKSプロキシアドレスを入力することもできます。間違ったプロトコルを指定すると、接続に失敗し、アイテムが未サポートになります。 HTTPプロキシでサポートされるのはシンプル認証のみであることに注意してください。 |
| SSLピア検証 | チェックボックスをマークすると、WebサーバーのSSL証明書を検証します。 サーバー証明書はシステム全体の証明書認証局(CA)ロケーションから自動的に取得されます。CAファイルの場所は、Zabbixサーバーまたはプロキシの設定パラメータ SSLCALocationで上書きできます。 |
| SSLホスト検証 | チェックボックスをマークすると、Webサーバー証明書のCommon NameフィールドまたはSubject Alternate Nameフィールドが一致するかどうかを検証します。 これは CURLOPT_SSL_VERIFYHOST cURLオプションを設定します。 |
| SSL証明書ファイル | クライアント認証に使用するSSL証明書ファイル名。証明書ファイルはPEM1形式である必要があります。ユーザーマクロがサポートされています。 証明書ファイルに秘密鍵も含まれている場合は、SSL鍵ファイルフィールドを空にします。鍵が暗号化されている場合は、SSL鍵パスワードフィールドにパスワードを指定します。このファイルを含むディレクトリは、Zabbixサーバーまたはプロキシの設定パラメータ SSLCertLocationで指定します。 |
| SSL鍵ファイル | クライアント認証に使用するSSL秘密鍵ファイル名。秘密鍵ファイルはPEM1形式である必要があります。ユーザーマクロがサポートされています。 このファイルを含むディレクトリは、Zabbixサーバーまたはプロキシの設定パラメータ SSLKeyLocationで指定します。 |
| SSL鍵パスワード | SSL秘密鍵ファイルのパスワード。ユーザーマクロがサポートされています。 |
| 説明 | コネクタの説明を入力します。 |
| 有効 | チェックボックスをマークするとコネクタが有効になります。 |
Kafkaコネクタがカンマ区切りのブートストラップブローカーアドレスリスト(例:Kafka.URL=kafka1.example.com:9093,kafka2.example.com:9093)で設定されている場合、Kafkaクライアントは最初に応答したブローカーに接続し、そのクラスタのメタデータを使用します。 リストに異なるKafkaクラスタのアドレスが含まれている場合、最も応答が早いクラスタのみが使用され、他のアドレスは利用不可として記録されます。その結果、コネクタが接続されていても、以下のような起動時警告が表示される場合があります。
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クラスタに属していることを確認し、コネクタホストからのDNS解決やブローカーのadvertised.listenersを検証し、ブローカーの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" のいずれかでなければならず、失敗したリクエストの場合はそれ以外となります。
成功時の例:
エラー時の例: