プロキシを使用した分散監視
概要
Zabbixプロキシは、効果的で信頼性の高い分散監視環境を構築するために使用できます。
プロキシは、パフォーマンスデータと可用性データを収集するためにローカルに配置します。 その後、データは一元管理されたサーバーに報告されます。
Zabbixプロキシは、次の用途に使用できます。
- リモートロケーションの監視
- 通信が不安定なロケーションの監視
- 数千台のデバイスを監視する際のZabbixサーバーの負荷軽減
- アプリケーションパフォーマンス監視（APM）のためのテレメトリデータの収集
プロキシには、ZabbixサーバーへのTCP接続が1つだけ必要です。 このため、ファイアウォールルールを1つ設定するだけで済み、ファイアウォールを容易に通過できます。
Zabbixプロキシは、専用のデータベースを使用する必要があります。 Zabbixサーバーのデータベースを指定すると、設定が破損します。
プロキシが収集したすべてのデータは、サーバーに送信される前にローカルに保存されます。
これにより、サーバーとの一時的な通信障害によるデータ損失を防止できます。
プロキシ設定ファイルのProxyLocalBufferおよびProxyOfflineBufferパラメータで、データをローカルに保持する期間を制御します。
Zabbixサーバーのデータベースから最新の設定変更を直接受信するプロキシは、Zabbixサーバーよりも新しい設定を持つ場合があります。これは、CacheUpdateFrequencyの値によって、Zabbixサーバーの設定更新が遅れる可能性があるためです。 その結果、プロキシがデータの収集を開始してZabbixサーバーに送信しても、Zabbixサーバーがそのデータを無視する場合があります。
Zabbixプロキシはデータコレクターです。 トリガーの計算、イベントの処理、アラートの送信は行いません。 プロキシの機能の概要については、次の表を参照してください。
| 機能 | プロキシでのサポート | |
|---|---|---|
| アイテム | ||
| Zabbixエージェントチェック | はい | |
| Zabbixエージェントチェック（アクティブ） | はい 1 | |
| シンプルチェック | はい | |
| トラッパーアイテム | はい | |
| SNMPチェック | はい | |
| SNMPトラップ | はい | |
| IPMIチェック | はい | |
| JMXチェック | はい | |
| ログファイル監視 | はい | |
| 内部チェック | はい | |
| SSHチェック | はい | |
| Telnetチェック | はい | |
| 外部チェック | はい | |
| 依存アイテム | はい | |
| スクリプトアイテム | はい | |
| ブラウザーアイテム | はい | |
| テレメトリクエリアイテム | はい | |
| 組み込みWeb監視 | はい | |
| アイテム値の前処理 | はい | |
| ネットワークディスカバリ | はい | |
| アクティブエージェントの自動登録 | はい | |
| ローレベルディスカバリ | はい 2 | |
| リモートコマンド | はい | |
| テレメトリデータの収集（APM） | はい 3 | |
| トリガーの計算 | いいえ | |
| イベントの処理 | いいえ | |
| イベント相関 | いいえ | |
| アラートの送信 | いいえ | |
[1] エージェントがアクティブチェックについてサーバーではなくプロキシに問い合わせるようにするには、エージェント設定ファイルのServerActiveパラメータにプロキシを指定する必要があります。
[2] LLDでは、Zabbixプロキシはデータの収集と前処理のみを行い、その後、さらなる処理のためにZabbixサーバーへ送信します。
[3] テレメトリデータは、プロキシでAPMが有効になっている場合にのみ収集されます（プロキシの設定のAPMタブを参照）。Zabbixサーバーはテレメトリデータを受信できません。
プロキシの機能
プロキシを使用するかどうかを選択する際には、いくつかの考慮事項を 踏まえる必要があります。
| プロキシ | |
|---|---|
| 軽量 | はい |
| GUI | いいえ |
| 独立して動作する | はい |
| 保守が容易 | はい |
| DBの自動作成 | はい1 |
| ローカル管理 | いいえ |
| 組み込みハードウェアに対応 | はい |
| 一方向のTCP接続 | はい |
| 集中設定 | はい |
| 通知を生成する | いいえ |
1 DBの自動作成機能はSQLiteでのみ動作します。 その他の対応データベースでは手動セットアップが必要です。
Zabbixプロキシはメンテナンス期間を認識しません。詳細はメンテナンス中のキューの計算を参照してください。
過負荷からの保護
Zabbix サーバーがしばらく停止しており、プロキシが大量のデータを収集していた場合、その後サーバーが起動すると、過負荷になることがあります（history cache の使用率がしばらく 95-100% のままになります）。 この過負荷により、処理性能が低下し、本来よりもチェックの処理が遅くなる可能性があります。 このような状況を防ぎ、history cache の過負荷によって発生する問題を回避するための保護機能が実装されています。
Zabbix サーバーの history cache がいっぱいになると、history cache への書き込みアクセスが制限され、サーバーのデータ収集処理が停止します。 history cache 過負荷の最も一般的なケースは、サーバー停止後にプロキシが収集済みデータをアップロードする際に発生します。 これを避けるためにプロキシのスロットリングが追加されました（現在は無効化できません）。
history cache の使用率が 80% に達すると、Zabbix サーバーはスロットリングモードに入ります。 スロットリングモードでは、history cache の使用率が 60% 未満のときにのみプロキシデータを受け入れ、受け入れるプロキシを順番に切り替えます。 history cache の使用率が 20% 未満になると、サーバーは通常モードに戻ります。
さらに、通常モードでは、history cache の使用率が 60% を超えると、Zabbix サーバーは非常に大きなパケット（10,000 レコード以上）を送信する個々のプロキシをスロットリングします。
この判定は、サーバーがプロキシのアップロードを評価した瞬間に適用されるため、history cache 使用率のグラフ（内部アイテム zabbix[wcache,history,pused] とその更新間隔）には、短時間のスパイクがすぐには反映されない場合があります。
このスロットリングモードは、キャッシュ使用率が再び 80% に達するか、20% まで低下するか、またはスロットリングリストが空になるまで継続します。 最初のケースでは、サーバーは再びプロキシデータの受け入れを停止します。 他の 2 つのケースでは、サーバーは通常どおり動作し、すべてのプロキシからのデータを受け入れます。
上記の情報は、次の表で示すことができます。
| History write cache usage |
Zabbix server mode | Zabbix server action |
|---|---|---|
| 80% に達する | 待機 | プロキシデータの受け入れを停止するが、後で連絡するための優先順位付きプロキシ一覧（throttling list）は保持する。 |
| 60% に達する | 通常、ただしスロットリングされる準備あり | データを受け入れるかどうかを判断する際に、非常に大きなプロキシアップロード（10k レコード超）を拒否する場合がある。それ以外のプロキシデータは受け入れ続ける。 |
| 20% まで低下する | 通常 | スロットリングリストを破棄し、プロキシデータの受け入れを通常どおり開始する。 |
この動作をメトリックと関連付けるには、zabbix[wcache,history,pused] 内部アイテムを使用できます。
設定
インストールし、設定したプロキシを、Zabbix Webインターフェースで設定します。
プロキシの追加
独自のインフラストラクチャにプロキシをインストールする代わりに、Zabbix Cloud にプロキシをデプロイできます。 デプロイするには、管理 > プロキシ で クラウドにプロキシを作成 をクリックします。Zabbix Cloud が新しいブラウザータブで開きます。 そこでプロキシノードを作成した後、以下の説明に従って Zabbix の Webインターフェースでプロキシを設定します。 詳細については、Zabbix Cloud プロキシのセットアップを参照してください。
Zabbix の Webインターフェースでプロキシを設定するには、次の手順に従います。
- 管理 > プロキシ に移動します。
- プロキシの作成 をクリックします。
- フォームにプロキシのパラメータを入力します。
| パラメータ | 説明 | |
|---|---|---|
| プロキシ名 | プロキシ名を入力します。プロキシ設定ファイルの Hostname パラメータと同じ名前である必要があります。 | |
| プロキシグループ | プロキシの負荷分散/高可用性に使用するプロキシグループを1つ選択します。 | |
| アクティブエージェント用アドレス | 監視対象のアクティブエージェントまたは送信元が接続するアドレスを入力します。Zabbix 7.0 以降のエージェントでのみサポートされます。 このアドレスは、アクティブプロキシとパッシブプロキシの両方への接続に使用されます。このフィールドは、プロキシグループ フィールドでプロキシグループが選択されている場合にのみ使用できます。 |
|
| アドレス | 接続先の IP アドレス/DNS 名。 | |
| ポート | 接続先の TCP ポート番号（デフォルトは10051）。ユーザーマクロを使用できます。 | |
| プロキシモード | プロキシモードを選択します。 アクティブ - プロキシが Zabbix サーバーに接続し、設定データを要求します パッシブ - Zabbix サーバーがプロキシに接続します 注：暗号化通信を使用しない場合（機密性）、アクティブプロキシの使用時に、Zabbix サーバーのトラッパーポートにアクセスできる第三者がプロキシ設定データを取得できる可能性があります。認証が行われない場合、または プロキシアドレス フィールドでプロキシアドレスが制限されていない場合、誰でもアクティブプロキシになりすまして設定データを要求できるためです。 |
|
| プロキシアドレス | 指定した場合、アクティブプロキシからの要求は、カンマ区切りの IP アドレス（必要に応じて CIDR 表記）、またはアクティブな Zabbix プロキシの DNS 名で構成されたこのリストからのみ受け付けられます。 このフィールドは、プロキシモード フィールドでアクティブプロキシが選択されている場合にのみ使用できます。マクロはサポートされません。 |
|
| インターフェース | パッシブプロキシのインターフェース情報を入力します。 このフィールドは、プロキシモード フィールドでパッシブプロキシが選択されている場合にのみ使用できます。 |
|
| アドレス | パッシブプロキシの IP アドレス/DNS 名。 | |
| ポート | パッシブプロキシの TCP ポート番号（デフォルトは10051）。ユーザーマクロを使用できます。 | |
| 説明 | プロキシの説明を入力します。 | |
暗号化タブでは、プロキシとの暗号化接続を必須にできます。
| パラメータ | 説明 |
|---|---|
| プロキシへの接続 | サーバーがパッシブプロキシに接続する方法：暗号化なし（デフォルト）、PSK（事前共有鍵）、または証明書を使用。 |
| プロキシからの接続 | アクティブプロキシから許可する接続の種類を選択します。複数の接続タイプを同時に選択できます（テストや別の接続タイプへの切り替えに便利です）。デフォルトは「暗号化なし」です。 |
| 発行者 | 証明書で許可する発行者。証明書はまず CA（認証局）で検証されます。有効で CA によって署名されている場合、発行者 フィールドを使用して許可する CA をさらに制限できます。このフィールドは任意であり、Zabbix のインストール環境で複数の CA の証明書を使用する場合に使用します。 |
| サブジェクト | 証明書で許可するサブジェクト。証明書はまず CA で検証されます。有効で CA によって署名されている場合、サブジェクト フィールドを使用して、サブジェクト 文字列の値を1つだけ許可できます。このフィールドが空の場合、設定された CA によって署名された有効な証明書はすべて受け入れられます。 |
| PSK identity | 事前共有鍵の識別文字列。 PSK identity には機密情報を含めないでください。使用する PSK を受信側に知らせるため、ネットワーク上で暗号化されずに送信されます。 |
| PSK | 事前共有鍵（16進数文字列）。最大長：Zabbix が GnuTLS または OpenSSL ライブラリを使用する場合は512桁（256バイトの PSK）、Zabbix が mbed TLS（PolarSSL）ライブラリを使用する場合は64桁（32バイトの PSK）。例：1f87b595725ac58dd977beef14b97461a7c1045b9a1c963065002c5473194952 |
APMタブでは、プロキシ上でアプリケーションパフォーマンス監視（APM）を設定できます。 プロキシは、OpenTelemetry プロトコル（OTLP/gRPC）を介してアプリケーションまたは OpenTelemetry コレクターから送信されたテレメトリデータ（トレース、メトリクス、ログ）を収集し、データをテレメトリデータソースに書き込むことができます。
| パラメータ | 説明 | |
|---|---|---|
| データ収集を有効にする | プロキシでテレメトリデータの収集を有効にするには、チェックボックスをオンにします。 テレメトリデータの収集を有効にする前に、プロキシ設定ファイルで StartAPMCollectors パラメータを 1 に設定します。 |
|
| 1秒あたりの最大メッセージ数 | プロキシが受け入れる1秒あたりのメッセージ数の最大値を設定します。 無制限 - 受信するすべてのメッセージを受け入れます。 カスタム - 指定した1秒あたりのメッセージ数まで受け入れます。 メッセージとは、アプリケーション、OpenTelemetry コレクター、または別のテレメトリソースから送信される OTLP リクエストです。サイズは送信元によって異なります。たとえば、OpenTelemetry コレクターは数千のスパンを1つのメッセージにまとめることがありますが、単純なアプリケーションはより小さなメッセージ（例：トレースごとに1つ）を送信する場合があります。 制限を超えると、プロキシは gRPC ステータスコード UNAVAILABLE（一時的なエラー）で応答します。そのため、送信元は設定に応じて、後でメッセージの送信を再試行する場合があります。 |
|
| リソース属性を追加 | 選択したタイプの受信テレメトリデータに追加するリソース属性を指定します（例：このプロキシが受信したすべてのデータに環境またはリージョンを示す属性を付加する）。これらの属性を使用してテレメトリデータをフィルターできます。たとえば、テレメトリクエリアイテムの条件で使用できます。 | |
| 名前 | 属性名を入力します（例：deployment.environment、cloud.region）。選択した タイプ で一意である必要があります。 |
|
| 値 | 属性値を入力します（例：production、eu-central-1）。空にすることもできます。 |
|
| タイプ | 属性を適用する受信データのタイプを選択します：トレース、メトリクス、またはログ。 | |
タイムアウトタブでは、対応するアイテムタイプのグローバルタイムアウトを上書きできます。
| パラメータ | 説明 |
|---|---|
| アイテムタイプのタイムアウト | アイテムのタイムアウトをタイプに基づいて設定します。 グローバル - グローバルタイムアウトを使用します（各アイテムタイプのグレー表示された タイムアウト フィールドに表示されます）。 上書き - カスタムタイムアウトを設定します（各アイテムタイプの タイムアウト フィールド）。許可される範囲：1～600秒（デフォルト：グローバルタイムアウトから継承）。時間のサフィックス（例：30s、1m）およびユーザーマクロがサポートされます。 グローバルタイムアウト リンクをクリックすると、グローバルタイムアウトを設定できます。グローバルタイムアウト リンクは、管理 > 一般設定 Webインターフェースセクションへの権限を持つ スーパー管理者 タイプのユーザーにのみ表示されます。 プロキシレベルのタイムアウトはグローバルタイムアウトを上書きしますが、個々のアイテムのタイムアウトが設定されている場合は、個々のアイテムのタイムアウトによって上書きされます。 |
プロキシのメジャーバージョンがサーバーのメジャーバージョンと一致しない場合、
アイコンが アイテムタイプのタイムアウト の横に表示され、ホバー時に「プロキシとサーバーのバージョンが一致しないため、タイムアウトが無効です」というメッセージが表示されます。
この場合、プロキシはプロキシ設定ファイルの Timeout パラメータを使用します。
既存のプロキシの編集フォームには、次の追加ボタンがあります。
- 設定を更新 - プロキシの設定を更新します。
- 複製 - 既存のプロキシのプロパティに基づいて新しいプロキシを作成します。
- 削除 - プロキシを削除します。
ホスト設定
ホスト設定フォームの Monitored by フィールドを使用して、個別のホストをプロキシまたはプロキシグループで監視するように指定できます。
ホストの一括更新も、ホストをプロキシまたはプロキシグループで監視するように指定する別の方法です。