2 外部システムへのストリーミング
概要
HTTP 経由で、Zabbix から外部システムへアイテムの値およびイベントをストリーミングできます(プロトコルの詳細を参照)。
タグフィルターを使用して、アイテムの値またはイベントのサブセットをストリーミングできます。
データストリーミングを担当する Zabbix サーバーのプロセスは、connector manager と connector worker の 2 つです。
Zabbix の内部アイテム zabbix[connector_queue] を使用すると、コネクターキューに追加された値の件数を監視できます。
設定
外部システムへのデータストリーミングを設定するには、以下の手順が必要です。
1. Zabbix からのデータを受信するためのリモートシステムを準備します。
この目的のために、以下のツールを利用できます。
- 受信した情報を
events.ndjsonおよびhistory.ndjsonファイルに記録する、シンプルな受信側の例。 - Zabbix server 用 Kafka connector - Go で記述された軽量サーバーで、Zabbix サーバーから Kafka ブローカーへアイテムの値およびイベントを転送するよう設計されています。
2. zabbix_server.conf の StartConnectors パラメータを調整して、Zabbix で必要な数のコネクタワーカーを設定します。
コネクタワーカー数は、Zabbix Webインターフェースで設定されたコネクタ数と一致させる必要があります(同時セッション数が 1 を超える場合は、それ以上にする必要があります)。
その後、Zabbix サーバーを再起動します。
3. Zabbix Webインターフェースで新しいコネクタを設定し(Administration > General > Connectors)、zabbix_server -R config_cache_reload コマンドでサーバーキャッシュを再読み込みします。

必須フィールドにはアスタリスクが付いています。
| Parameter | Description |
|---|---|
| Name | コネクタ名を入力します。 |
| 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 | コネクタがストリーミングするアイテムの値をフィルタリングするための情報タイプ(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 トークンを入力します。ユーザーマクロを使用できます。 このフィールドは、HTTP authentication が "Bearer" に設定されている場合に使用可能かつ必須です。 |
| Advanced configuration | Advanced configuration ラベルをクリックすると、高度な設定オプションが表示されます(以下を参照)。 |
| Max records per message | 1 つのメッセージ内でストリーミングできる値またはイベントの最大数を指定します。 |
| Concurrent sessions | このコネクタで実行する送信プロセス数を選択します。最大 100 セッションまで指定でき、デフォルト値は "1" です。 |
| Attempts | データストリーミングの試行回数です。最大 5 回まで指定でき、デフォルト値は "1" です。 |
| Attempt interval | データストリーミングの試行に失敗した後、コネクタが待機する時間を指定します。最大 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 プロキシアドレスを入力することもできます。誤ったプロトコルを指定すると、接続は失敗し、アイテムは未サポートになります。 HTTP プロキシでは単純認証のみサポートされることに注意してください。 |
| SSL verify peer | Web サーバーの SSL 証明書を検証するには、チェックボックスをオンにします。 サーバー証明書は、システム全体の認証局(CA)の場所から自動的に取得されます。CA ファイルの場所は、Zabbix サーバーまたはプロキシの設定パラメータ SSLCALocation を使用して上書きできます。 |
| 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 | コネクタの説明を入力します。 |
| Enabled | チェックボックスをオンにしてコネクタを有効にします。 |
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 を確認し、ブローカーの通知アドレスに解決されるアドレスを優先して使用してください。
プロトコル
サーバーと受信側の通信は、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}
Receiverのレスポンス
レスポンスは、HTTPレスポンスのステータスコードとJSONペイロードで構成されます。 正常に処理されたリクエストでは、HTTPレスポンスのステータスコードは "200"、"201"、"202"、"203"、または "204" である必要があります。その他のコードは、リクエストの失敗を示します。
成功時の例:
localhost:8080/v1/history": HTTP/1.1 200 OK
Date: Wed, 11 Jan 2023 16:40:30 GMT
Content-Length: 0
エラーがある場合の例:
localhost:8080/v1/history": HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json
Date: Wed, 11 Jan 2023 17:07:36 GMT
Content-Length: 55
{"error":"invalid character '{' after top-level value"}