プロキシ
概要
Zabbixプロキシは、1台以上の監視対象デバイスから監視データを収集し、その情報をZabbixサーバーに送信するプロセスです。基本的には、サーバーの代わりに動作します。 収集したすべてのデータはローカルにバッファリングされた後、プロキシが所属するZabbixサーバーに転送されます。
プロキシの導入は任意ですが、1台のZabbixサーバーの負荷を分散するうえで非常に有効です。 プロキシのみがデータを収集する構成にすると、サーバーで必要となるCPUおよびディスクI/Oの処理負荷を軽減できます。
Zabbixプロキシは、リモート拠点、支店、ローカル管理者がいないネットワークを一元的に監視するための理想的なソリューションです。
Zabbixプロキシには個別のデータベースが必要です。
Zabbixプロキシでサポートされているデータベースは、SQLite、MySQL、PostgreSQLです。
関連項目:
- プロキシを使用した分散監視
- プロキシの負荷分散と高可用性
- 監視設定の同期
- サーバーとプロキシ間のデータ交換プロトコル
- 設定パラメータ: Zabbixプロキシ
- Zabbix Cloudプロキシのセットアップ
プロキシの実行
パッケージとしてインストールした場合
Zabbixプロキシはデーモンプロセスとして実行されます。 プロキシは次のコマンドで起動できます:
systemctl start zabbix-proxyこれはほとんどのGNU/Linuxシステムで動作します。 他のシステムでは、次のコマンドを実行する必要があるかもしれません:
/etc/init.d/zabbix-proxy start同様に、Zabbixプロキシの停止/再起動/ステータス表示には、以下のコマンドを使用します:
systemctl stop zabbix-proxy
systemctl restart zabbix-proxy
systemctl status zabbix-proxy手動で起動する
上記でうまくいかない場合は、手動で起動する必要があります。
zabbix_proxy バイナリへのパスを見つけて、次を実行します。
zabbix_proxyZabbixプロキシでは、次のコマンドラインパラメーターを使用できます。
| Parameter | Description |
|---|---|
-c --config <config-file> |
設定ファイルへのパス。 |
-f --foreground |
Zabbixプロキシをフォアグラウンドで実行します。 |
-R --runtime-control <option> |
管理機能を実行します。 |
-T --test-config |
設定ファイルを検証して終了します。 |
-h --help |
ヘルプ情報を表示して終了します。 |
-V --version |
バージョン番号を表示します。 |
コマンドラインパラメーターを指定してZabbixプロキシを実行する例:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf
zabbix_proxy --help
zabbix_proxy -Vランタイム制御
ランタイム制御オプション:
| Option | Description | Target |
|---|---|---|
config_cache_reload |
設定キャッシュを再読み込みします。現在キャッシュが読み込み中の場合は無視されます。 アクティブな Zabbix プロキシは Zabbix サーバーに接続して設定データを要求します。 パッシブな Zabbix プロキシは、次回サーバーがプロキシに接続したときに Zabbix サーバーから設定データを要求します。 |
|
history_cache_clear=target |
ID で指定されたアイテムの history cache をクリアします。 アイテムの最初と最後の値を除く、すべての値に影響します。 |
target - アイテムの ID。 |
diaginfo[=<section>] |
プロキシのログファイルに診断情報を収集します。 | historycache - history cache の統計情報;preprocessing - preprocessing manager の統計情報;locks - mutex の一覧（BSD システムでは空です）。 |
snmp_cache_reload |
SNMP cache を再読み込みします - すべてのホストの SNMP エンジンプロパティ（engine time、engine boots、engine id、credentials）をクリアします。SNMP の問題をトラブルシュートする際に、グローバルなキャッシュクリアを強制するために使用します。 | |
housekeeper_execute |
housekeeping 手順を開始します。housekeeping 手順が現在進行中の場合は無視されます。 | |
log_level_increase[=<target>] |
ログレベルを上げます。target が指定されていない場合は、すべてのプロセスに影響します。 BSD システムではサポートされていません。 |
process type - 指定した種類のすべてのプロセス（例: poller）。すべての プロキシプロセスの種類 を参照してください。 process type,N - プロセスの種類と番号（例: poller,3）pid - プロセス識別子（ 1 から 65535）。より大きい値を指定する場合は、target を 'process type,N' として指定します。 |
log_level_decrease[=<target>] |
ログレベルを下げます。target が指定されていない場合は、すべてのプロセスに影響します。 BSD システムではサポートされていません。 |
|
prof_enable[=<target>] |
プロファイリングを有効にします。 target が指定されていない場合は、すべてのプロセスに影響します。 有効化されたプロファイリングでは、関数名ごとのすべての rwlock/mutex の詳細が提供されます。 |
process type - 指定した種類のすべてのプロセス（例: history syncer）。すべての プロキシプロセスの種類 を参照してください。 process type,N - プロセスの種類と番号（例: history syncer,1）。pid - プロセス識別子（ 1 から 65535）。より大きい値を指定する場合は、target を 'process type,N' として指定します。scope - rwlock、mutex、processing は、プロセスの種類と番号（例: history syncer,1,processing）またはその種類のすべてのプロセス（例: history syncer,rwlock）と組み合わせて使用できます。 |
prof_disable[=<target>] |
プロファイリングを無効にします。 target が指定されていない場合は、すべてのプロセスに影響します。 |
process type - 指定した種類のすべてのプロセス（例: history syncer）。すべての プロキシプロセスの種類 を参照してください。 process type,N - プロセスの種類と番号（例: history syncer,1）。pid - プロセス識別子（ 1 から 65535）。より大きい値を指定する場合は、target を 'process type,N' として指定します。 |
プロセスの種類がランタイム制御の target として指定されると、そのコマンドはその種類の実行中のプロセスにのみ適用されます。 指定した種類のプロセスが現在実行されていない場合、コマンドはエラーを返します:
zabbix_proxy -R log_level_increase='data sender'
Cannot redirect signal: "data sender" process does not existランタイム制御を使用してプロキシの設定キャッシュを再読み込みする例:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R config_cache_reloadランタイム制御を使用してアイテムの history cache をクリアする例:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R history_cache_clear=42243ランタイム制御を使用して診断情報を収集する例:
# プロキシのログファイルに利用可能なすべての診断情報を収集します:
zabbix_proxy -R diaginfo
# プロキシのログファイルに history cache の統計情報を収集します:
zabbix_proxy -R diaginfo=historycacheランタイム制御を使用して SNMP cache を再読み込みする例:
zabbix_proxy -R snmp_cache_reloadSNMPv3 インターフェースが Zabbix UI から更新された場合、ほとんどの場合、Zabbix はそのインターフェースの新しい SNMPv3 credentials を自動的に再読み込みします。-R snmp_cache_reload は、credentials の変更後もポーリングが失敗し続ける場合（たとえば engineBoots/engineID の不整合や RFC 非準拠デバイスが原因の場合）、またはトラブルシューティングのためにグローバルな SNMP cache クリアを強制する必要がある場合にのみ使用してください。
ランタイム制御を使用して housekeeper の実行を開始する例:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R housekeeper_executeランタイム制御を使用してログレベルを変更する例:
# すべてのプロセスのログレベルを上げます:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase
# 2 番目の poller プロセスのログレベルを上げます:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase=poller,2
# PID 1234 のプロセスのログレベルを上げます:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase=1234
# すべての http poller プロセスのログレベルを下げます:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_decrease="http poller"ユーザーとしてのプロセス実行
Zabbixプロキシは、root以外のユーザーとして実行するように設計されています。 起動したroot以外のユーザーとして実行されます。 そのため、問題なく任意のroot以外のユーザーとしてプロキシを実行できます。
「root」として実行しようとすると、ハードコードされた「zabbix」ユーザーに切り替わります。このユーザーはシステム上に存在している必要があります。
プロキシ設定ファイルの AllowRoot パラメータを適切に変更した場合にのみ、「root」としてプロキシを実行できます。
設定ファイル
設定ファイルのデフォルトパスは、オペレーティングシステムと Zabbix のインストール方法によって異なります。
- ソースからインストールした場合:
/usr/local/etc/zabbix_proxy.conf、または コンパイル時 に設定された変数--sysconfdirまたは--prefix。 - パッケージからインストールした場合:
/etc/zabbix/zabbix_proxy.conf。
zabbix_proxy の設定方法の詳細については、設定ファイル のオプションを参照してください。
プロキシのプロセスタイプとスレッド
agent poller- パッシブチェック用の非同期ポーラープロセス（ワーカースレッド付き）;apm manager- アプリケーションパフォーマンスモニタリング（APM）用のマネージャープロセス;apm worker-apm managerからのアプリケーションパフォーマンスモニタリング（APM）タスクを処理するプロセス;availability manager- ホストの可用性を更新するプロセス;browser poller- ブラウザーアイテムのチェック用ポーラー;configuration syncer- 設定データのメモリ内キャッシュを管理するプロセス;data sender- プロキシデータ送信プロセス;discovery manager- デバイス検出用のマネージャープロセス;discovery worker- discovery managerからの検出タスクを処理するプロセス;history syncer- 履歴データベースライター;housekeeper- 古いアイテム履歴を削除するプロセス;http agent poller- HTTPチェック用の非同期ポーラープロセス（ワーカースレッド付き）;http poller- Web監視ポーラー;icmp pinger- icmppingチェック用ポーラー;internal poller- 内部チェック用ポーラー;ipmi manager- IPMIポーラーマネージャー;ipmi poller- IPMIチェック用ポーラー;java poller- Javaチェック用ポーラー;odbc poller- ODBCチェック用ポーラー;poller- パッシブチェック用の通常のポーラー;preprocessing manager- 前処理ワーカースレッドを使用して前処理タスクを管理するマネージャー;preprocessing worker- データ前処理用のスレッド;self-monitoring- 内部サーバー統計を収集するプロセス;snmp poller- SNMPチェック用の非同期ポーラープロセス（ワーカースレッド付き。walk[OID]およびget[OID]アイテムのみ）;snmp trapper- SNMPトラップ用のトラッパー;supervisor- サーバープロセスおよびスレッドの起動とシャットダウンを調整し、それらの準備状態を監視するプロセス;task manager- 他のコンポーネントから要求されたタスク（障害のクローズ、障害の認識、アイテム値の即時チェック、リモートコマンド機能など）をリモート実行するプロセス;telemetry query poller- テレメトリクエリアイテムのチェック用ポーラー;trapper- アクティブチェック、トラップ、プロキシ通信に使用するトラッパー;unreachable poller- 到達不能なデバイス用のポーラー;vmware collector- VMwareサービスからデータを収集するVMwareデータコレクター。
これらのプロセスタイプは、プロキシのログファイルで確認できます。
プロキシのログファイルは、ファイル所有者だけが読み書きできる権限で作成されます。 また、所有者グループはファイルを読み取ることができます。 その他の権限はすべて拒否されます。
さまざまなタイプのZabbixプロキシプロセスは、zabbix[process,<type>,<mode>,<state>]内部itemを使用して監視できます。
History syncerトランザクション統計
history syncerプロセスのタイトルには、history syncerトランザクションに関する詳細な統計が表示されます。
205276 ? S 0:00 zabbix_proxy: history syncer #1 [processed 1 values in 0.001179 (0.001167,0.000000) sec, idle 1 sec]
205277 ? S 0:00 zabbix_proxy: history syncer #2 [processed 0 values in 0.000022 (0.000000,0.000000) sec, idle 1 sec]processed...in N (<timings>) sec に含まれる時間は、次のとおりです。
- アイテムの値をデータベースに書き込むのにかかった時間。
- アイテムデータ（状態、エラー）を更新するのにかかった時間。
ハウスキーピング手順
Zabbix プロキシには、古くなったアイテムの履歴データとトレンドを削除する housekeeper プロセスがあります。
このプロセスは、HousekeepingFrequency によって決まる頻度でサイクル実行され、各サイクルでの削除上限は ProxyLocalBuffer と ProxyOfflineBuffer によって決まります。
Zabbix サーバーのハウスキーピング手順とは異なり、プロキシの housekeeper プロセスは housekeeper テーブルを使用しません。代わりに、各ハウスキーピングサイクルで古くなったデータをすべて削除します。
サポートされるプラットフォーム
Zabbixプロキシは、Zabbixサーバーと同じ サポートされるプラットフォーム の一覧で動作します。
メモリバッファ
メモリバッファを使用すると、新しいデータ（アイテムの値、ネットワーク検出、ホストの自動登録）をバッファに保存し、データベースにアクセスせずにZabbixサーバーへアップロードできます。 メモリバッファは、Zabbix 7.0でプロキシに導入されました。
Zabbix 7.0より前のインストールでは、収集したデータはZabbixサーバーへアップロードする前にデータベースへ保存されていました。 これらのインストールでは、Zabbix 7.0へのアップグレード後も、これがデフォルトの動作です。
パフォーマンスを最適化するため、プロキシでメモリバッファを使用するように設定することを推奨します。
これを行うには、ProxyBufferModeの値をdisk（既存のインストールでハードコードされているデフォルト値）からhybrid（推奨）またはmemoryに変更します。
また、メモリバッファのサイズ（ProxyMemoryBufferSizeパラメータ）を設定する必要があります。
hybridモードでは、プロキシが停止した場合、バッファがいっぱいになった場合、またはデータが古くなりすぎた場合に、未送信のデータをデータベースへフラッシュすることで、データ損失からバッファを保護します。 すべての値がデータベースへフラッシュされると、プロキシはメモリバッファの使用に戻ります。
memoryモードではメモリバッファが使用されますが、データ損失に対する保護はありません。 プロキシが停止した場合、またはメモリがいっぱいになった場合、未送信のデータは破棄されます。
hybridモード（ProxyBufferMode=hybrid）は、Zabbix 7.0以降のすべての新規インストールに適用されます。
ProxyMemoryBufferSizeやProxyMemoryBufferAgeなどの追加パラメータでは、それぞれメモリバッファのサイズと、バッファ内のデータの最大経過時間を定義します。
設定に矛盾がある場合、プロキシはエラーを出力して起動に失敗します。たとえば、次の場合です。
ProxyBufferModeがhybridまたはmemoryに設定され、ProxyMemoryBufferSizeが0の場合。ProxyBufferModeがhybridまたはmemoryに設定され、ProxyLocalBufferが0でない場合。
ロケール
プロキシでは、一部のテキストアイテムを正しく解釈できるように、UTF-8 ロケールが必要です。 多くの最新の Unix 系システムでは UTF-8 ロケールがデフォルトになっていますが、システムによっては明示的に設定する必要があります。
メンテナンス中のキューの計算
Zabbixプロキシはメンテナンス期間を認識しません。詳細はメンテナンス中のキューの計算を参照してください。
プロキシの背後で Zabbix Webインターフェースを使用する
Zabbix Webインターフェースがプロキシサーバーの背後で実行されている場合、リバースプロキシされたパスに一致するよう、プロキシ設定ファイル内の Cookie パスを書き換える必要があります。 以下の例を参照してください。 Cookie パスを書き換えない場合、Zabbix Webインターフェースへのログイン時に、ユーザーが認証の問題に遭遇する可能性があります。
NGINXの設定例
# ..
location / {
# ..
proxy_cookie_path /zabbix /;
proxy_pass http://192.168.0.94/zabbix/;
# ..Apacheの設定例
# ..
ProxyPass "/" http://host/zabbix/
ProxyPassReverse "/" http://host/zabbix/
ProxyPassReverseCookiePath /zabbix /
ProxyPassReverseCookieDomain host zabbix.example.com
# ..