Zabbixプロキシは、1つまたは複数の監視対象デバイスから監視データを収集し、その情報をZabbixサーバーに送信するプロセスであり、本質的にはサーバーの代理として機能します。 収集されたすべてのデータはローカルにバッファリングされ、その後プロキシが属するZabbixサーバーに転送されます。
プロキシの導入は必須ではありませんが、単一のZabbixサーバーの負荷を分散するために非常に有益です。 プロキシのみがデータを収集する場合、サーバーでの処理はCPUやディスクI/Oの負荷が少なくなります。
Zabbixプロキシは、リモート拠点、支店、ローカル管理者のいないネットワークの集中監視に最適なソリューションです。
Zabbixプロキシには、別途データベースが必要です。
Zabbixプロキシでサポートされているデータベースは、SQLite、MySQL、PostgreSQLです。
参考: 分散環境でのプロキシの使用
Zabbixプロキシはデーモンプロセスとして実行されます。 プロキシは次のコマンドで起動できます:
これはほとんどのGNU/Linuxシステムで動作します。 他のシステムでは、次のコマンドを実行する必要があるかもしれません:
同様に、Zabbixプロキシの停止/再起動/ステータス表示には、以下のコマンドを使用します:
上記でうまくいかない場合は、手動で起動する必要があります。 zabbix_proxy バイナリのパスを探して、以下を実行します:
Zabbixプロキシでは、以下のコマンドラインパラメータが使用できます:
-c --config <file> 設定ファイルへのパス
-f --foreground フォアグラウンドでZabbixプロキシを実行
-R --runtime-control <option> 管理機能を実行
-T --test-config 設定ファイルを検証して終了
-h --help このヘルプを表示
-V --version バージョン番号を表示コマンドラインパラメータを指定してZabbixプロキシを起動する例:
ランタイム制御オプション:
| オプション | 説明 | ターゲット |
|---|---|---|
| config_cache_reload | 設定キャッシュをリロードします。キャッシュが現在ロード中の場合は無視されます。 アクティブZabbixプロキシはZabbixサーバーに接続し、設定データを要求します。 パッシブZabbixプロキシは、サーバーがプロキシに接続した次のタイミングでZabbixサーバーから設定データを要求します。 |
|
| history_cache_clear=target | IDで指定されたアイテムのヒストリーキャッシュをクリアします。 アイテムのすべての値に影響しますが、最初と最後の値は除きます。 |
target - アイテムのID |
| diaginfo[=<section>] | プロキシのログファイルに診断情報を収集します。 | historycache - ヒストリーキャッシュの統計情報 preprocessing - 前処理マネージャの統計情報 locks - ミューテックスのリスト(BSDシステムでは空) |
| snmp_cache_reload | SNMPキャッシュをリロードします — すべてのホストのSNMPエンジンプロパティ(engine time、engine boots、engine id、credentials)をクリアします。SNMPの問題をトラブルシューティングする際に、グローバルキャッシュのクリアを強制するために使用します。 | |
| housekeeper_execute | ハウスキーピング手順を開始します。ハウスキーピング手順が現在進行中の場合は無視されます。 | |
| log_level_increase[=<target>] | ログレベルを上げます。ターゲットが指定されていない場合はすべてのプロセスに影響します。 BSDシステムではサポートされていません。 |
process type - 指定したタイプのすべてのプロセス(例: poller) すべてのプロキシプロセスタイプを参照してください。 process type,N - プロセスタイプと番号(例: poller,3) pid - プロセスID(1~65535)。より大きな値の場合は、ターゲットを 'process type,N' として指定してください。 |
| log_level_decrease[=<target>] | ログレベルを下げます。ターゲットが指定されていない場合はすべてのプロセスに影響します。 BSDシステムではサポートされていません。 |
|
| prof_enable[=<target>] | プロファイリングを有効にします。 ターゲットが指定されていない場合はすべてのプロセスに影響します。 有効なプロファイリングは、関数名ごとのすべてのrwlock/mutexの詳細を提供します。 |
process type - 指定したタイプのすべてのプロセス(例: history syncer) すべてのプロキシプロセスタイプを参照してください。 process type,N - プロセスタイプと番号(例: history syncer,1) pid - プロセスID(1~65535)。より大きな値の場合は、ターゲットを 'process type,N' として指定してください。 scope - rwlock, mutex, processing はプロセスタイプと番号(例: history syncer,1,processing)またはタイプのすべてのプロセス(例: history syncer,rwlock)で使用できます |
| prof_disable[=<target>] | プロファイリングを無効にします。 ターゲットが指定されていない場合はすべてのプロセスに影響します。 |
process type - 指定したタイプのすべてのプロセス(例: history syncer) すべてのプロキシプロセスタイプを参照してください。 process type,N - プロセスタイプと番号(例: history syncer,1) pid - プロセスID(1~65535)。より大きな値の場合は、ターゲットを 'process type,N' として指定してください。 |
プロキシ設定キャッシュをリロードするためのランタイム制御の使用例:
アイテムのヒストリーキャッシュをクリアするためのランタイム制御の使用例:
診断情報を収集するためのランタイム制御の使用例:
# プロキシログファイルに利用可能なすべての診断情報を収集:
zabbix_proxy -R diaginfo
# プロキシログファイルにヒストリーキャッシュの統計情報を収集:
zabbix_proxy -R diaginfo=historycacheSNMPキャッシュをリロードするためのランタイム制御の使用例:
SNMPv3インターフェースがZabbix UI経由で更新された場合、ほとんどの場合Zabbixはそのインターフェースの新しいSNMPv3認証情報を自動的にリロードします。認証情報の変更後もポーリングが失敗する場合(たとえば、engineBoots/engineIDの不整合やRFC非準拠デバイスなど)、またはトラブルシューティングのためにグローバルなSNMPキャッシュのクリアを強制する必要がある場合のみ、-R snmp_cache_reload を使用してください。
ハウスキーパーの実行をトリガーするためのランタイム制御の使用例:
ログレベルを変更するためのランタイム制御の使用例:
# すべてのプロセスのログレベルを上げる:
zabbix_proxy -c /usr/local/etc/zabbix_proxy.conf -R log_level_increase
# 2番目のポーラープロセスのログレベルを上げる:
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'ユーザーに切り替わります。このユーザーはシステム上に存在する必要があります。 プロキシを'root'として実行するには、プロキシの設定ファイルで'AllowRoot'パラメータを適切に変更する必要があります。
zabbix_proxyの設定の詳細については、設定ファイルのオプションを参照してください。
agent poller - ワーカースレッドを持つパッシブチェック用の非同期ポーラープロセスavailability manager - ホストの可用性更新用プロセスbrowser poller - ブラウザアイテムチェック用ポーラーconfiguration syncer - 設定データのインメモリキャッシュ管理プロセスdata sender - プロキシデータ送信プロセスdiscovery manager - デバイス検出用のマネージャープロセスdiscovery worker - ディスカバリーマネージャからの検出タスクを処理するプロセスhistory syncer - ヒストリDB書き込みプロセス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トラップ用トラッパーtask manager - 他のコンポーネントから要求されたタスクのリモート実行用プロセス(例:問題のクローズ、問題の確認、アイテム値の即時チェック、リモートコマンド機能)trapper - アクティブチェック、トラップ、プロキシ通信用トラッパーunreachable poller - 到達不能デバイス用ポーラーvmware collector - VMwareサービスからのデータ収集を担当するVMwareデータコレクターこれらのプロセスタイプはプロキシのログファイルで確認できます。
プロキシのログファイルは、ファイル所有者のみが読み書きできる権限で作成されます。さらに、所有グループも読み取り可能です。他のすべての権限は拒否されます。
さまざまなタイプのZabbixプロキシプロセスは、zabbix[process,<type>,<mode>,<state>] 内部アイテムを使用して監視できます。
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プロキシは、Zabbixサーバーと同じサポートされているプラットフォームで動作します。
メモリバッファは、新しいデータ(アイテム値、ネットワークディスカバリ、ホストの自動登録)をバッファに保存し、データベースにアクセスせずにZabbixサーバーにアップロードすることを可能にします。 メモリバッファは、Zabbix 7.0からプロキシに導入されました。
Zabbix 7.0以前のインストールでは、収集されたデータはZabbixサーバーにアップロードする前にデータベースに保存されていました。 これらのインストールでは、Zabbix 7.0にアップグレードした後もデフォルトの動作として残ります。
最適なパフォーマンスのためには、プロキシでメモリバッファの使用を設定することを推奨します。 これは、ProxyBufferModeの値を「disk」(既存インストールのハードコードされたデフォルト)から「hybrid」(推奨)または「memory」に変更することで可能です。 また、メモリバッファサイズ(ProxyMemoryBufferSizeパラメータ)を設定する必要があります。
ハイブリッドモードでは、プロキシが停止した場合、バッファがいっぱいになった場合、またはデータが古くなった場合に、未送信データをデータベースにフラッシュすることで、バッファがデータ損失から保護されます。 すべての値がデータベースにフラッシュされると、プロキシはメモリバッファの使用に戻ります。
メモリモードでは、メモリバッファが使用されますが、データ損失に対する保護はありません。 プロキシが停止した場合やメモリがいっぱいになった場合、未送信データは破棄されます。
ハイブリッドモード(ProxyBufferMode=hybrid)は、Zabbix 7.0以降のすべての新規インストールに適用されます。
ProxyMemoryBufferSizeやProxyMemoryBufferAgeなどの追加パラメータは、それぞれメモリバッファのサイズとバッファ内のデータの最大保持期間を定義します。
注意:設定が矛盾している場合、プロキシはエラーを出力して起動に失敗します。例えば、以下の場合です。
プロキシが一部のテキストアイテムを正しく解釈できるように、UTF-8ロケールが必要であることに注意してください。 ほとんどの最新のUnix系システムではデフォルトでUTF-8ロケールが設定されていますが、システムによっては明示的に設定する必要がある場合があります。
Zabbixプロキシはメンテナンス期間を認識しません。詳細はメンテナンス中のキューの計算を参照してください。