1 Zabbixサーバー
概要
Zabbixサーバーは、Zabbixソフトウェアの中核となるプロセスです。
サーバーはデータのポーリングとトラッピングを行い、トリガーを計算し、ユーザーに通知を送信します。
また、Zabbix エージェントとプロキシがシステムの可用性や整合性に関するデータを報告する中心的なコンポーネントでもあります。
サーバー自身も、簡単なサービスチェックを使用して、ネットワーク上のサービス（Webサーバーやメールサーバーなど）をリモートで確認できます。
サーバーは、すべての設定データ、統計データ、および運用データが保存される中央リポジトリであり、監視対象のいずれかのシステムで問題が発生した際に、管理者へ積極的に警告を発する Zabbix の主体でもあります。
基本的な Zabbix サーバーの動作は、Zabbix サーバー、Webインターフェース、データベースストレージという3つの異なるコンポーネントに分かれています。
Zabbix のすべての設定情報はデータベースに保存され、サーバーと Webインターフェースの両方がこれにアクセスします。
たとえば、Webインターフェース（または API）を使用して新しいアイテムを作成すると、そのアイテムはデータベースの items テーブルに追加されます。
その後、Zabbix サーバーはおよそ1分に1回、items テーブルを照会して有効なアイテムの一覧を取得し、それを Zabbix サーバー内のキャッシュに保存します。
このため、Zabbix Webインターフェースで行った変更が最新データのセクションに反映されるまで、最大で2分かかることがあります。
Zabbixサーバーの起動
パッケージとしてインストールした場合
Zabbixサーバーはデーモンプロセスとして動作します。 サーバーは以下のコマンドで起動できます。
systemctl start zabbix-serverこれはほとんどのGNU/Linuxシステムで動作します。 他のシステムでは、以下のコマンドを実行する必要があるかもしれません。
/etc/init.d/zabbix-server start同様に、停止/再起動/ステータス表示には以下のコマンドを使用します。
systemctl stop zabbix-server
systemctl restart zabbix-server
systemctl status zabbix-server手動で起動する
上記の方法で動作しない場合は、手動で起動する必要があります。
zabbix_server バイナリへのパスを見つけて、次を実行します。
zabbix_serverZabbix サーバーでは、次のコマンドラインパラメータを使用できます。
-c --config <file> 設定ファイルへのパス（デフォルトは /usr/local/etc/zabbix_server.conf）
-f --foreground Zabbix サーバーをフォアグラウンドで実行する
-R --runtime-control <option> 管理機能を実行する
-T --test-config 設定ファイルを検証して終了する
-h --help このヘルプを表示する
-V --version バージョン番号を表示するコマンドラインパラメータを指定して Zabbix サーバーを実行する例:
zabbix_server -c /usr/local/etc/zabbix_server.conf
zabbix_server --help
zabbix_server -Vランタイム制御
ランタイム制御オプション:
| Option | Description | Target |
|---|---|---|
config_cache_reload |
設定キャッシュを再読み込みします。現在キャッシュを読み込み中の場合は無視されます。 | |
history_cache_clear=target |
IDで指定したアイテムの履歴キャッシュをクリアします。 アイテムの最初と最後の値を除く、すべての値に影響します。 |
target - アイテムのID |
diaginfo[=<section>] |
診断情報をサーバーログファイルに収集します。 | historycache - history cacheの統計情報;valuecache - value cacheの統計情報;preprocessing - 前処理マネージャーの統計情報;alerting - アラートマネージャーの統計情報;lld - LLDマネージャーの統計情報;locks - ミューテックスの一覧 (BSD システムでは空);connector - キューが最も大きいコネクタの統計情報。 |
ha_status |
高可用性(HA)クラスタの状態をログに記録します。 | |
ha_remove_node=target |
名前またはIDで指定した高可用性(HA)ノードを削除します。 アクティブ/スタンバイノードは削除できないことに注意してください。 |
target - ノードの名前またはID (ha_status の実行で取得可能)。 |
ha_set_failover_delay=delay |
高可用性(HA)のフェイルオーバー遅延を設定します。 Time suffixes がサポートされています。例: 10s, 1m。 |
|
proxy_config_cache_reload[=<target>] |
プロキシの設定キャッシュを再読み込みします。 | target - プロキシ名のカンマ区切りリスト。 target を指定しない場合は、すべてのプロキシの設定を再読み込みします。 |
secrets_reload |
Vaultからシークレットを再読み込みします。 | |
service_cache_reload |
サービスマネージャーのキャッシュを再読み込みします。 | |
snmp_cache_reload |
SNMPキャッシュを再読み込みします。SNMPエンジンのプロパティー(エンジン時間、エンジン起動回数、エンジンID、認証情報)をすべてのホストについてクリアします。SNMPの問題をトラブルシューティングする際に、グローバルなキャッシュクリアを強制するために使用します。 | |
housekeeper_execute |
housekeeping 手順を開始します。 housekeeping 手順が現在進行中の場合は無視されます。 |
|
trigger_housekeeper_execute |
トリガーの housekeeping 手順を開始します。 トリガーの housekeeping 手順が現在進行中の場合は無視されます。 トリガーの housekeeping 手順が開始されるまで、すでに削除されたトリガーによって発生した障害がサービス障害を生成し、それらをサービスに割り当てる場合があります。頻繁に検出/未検出が切り替わるトリガーに基づくサービス状態計算ルールを多数使用している構成では、 ProblemHousekeepingFrequency サーバー設定パラメーターを調整して、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)プロファイリング対象としてサポートされるプロセス種別: alerter, alert manager, availability manager, configuration syncer, discovery manager, escalator, history poller, history syncer, housekeeper, http poller, icmp pinger, ipmi manager, ipmi poller, java poller, lld manager, lld worker, odbc poller, poller, preprocessing manager, preprocessing worker, proxy poller, self-monitoring, service manager, snmp trapper, task manager, timer, trapper, unreachable poller, vmware collector.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)。プロファイリング対象としてサポートされるプロセス種別: prof_enable を参照してください。process type,N - プロセス種別と番号(例: history syncer,1)。pid - プロセス識別子( 1 から 65535)。より大きい値を指定する場合は、target を 'process type,N' としてください。 |
サーバーの設定キャッシュをリロードするためにランタイム制御を使用する例:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R config_cache_reloadプロキシの設定をリロードするためにランタイム制御を使用する例:
# すべてのプロキシの設定をリロード:
zabbix_server -R proxy_config_cache_reload
# Proxy1とProxy2の設定をリロード:
zabbix_server -R proxy_config_cache_reload=Proxy1,Proxy2アイテムのヒストリキャッシュをクリアするためにランタイム制御を使用する例:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R history_cache_clear=42243診断情報を収集するためにランタイム制御を使用する例:
# サーバーログファイルに利用可能なすべての診断情報を収集:
zabbix_server -R diaginfo
# サーバーログファイルにヒストリキャッシュの統計情報を収集:
zabbix_server -R diaginfo=historycacheSNMPキャッシュをリロードするためにランタイム制御を使用する例:
zabbix_server -R snmp_cache_reloadSNMPv3インターフェースがZabbix UI経由で更新された場合、ほとんどの場合Zabbixはそのインターフェースの新しいSNMPv3認証情報を自動的にリロードします。認証情報の変更後もポーリングが失敗する場合(例えば、engineBoots/engineIDの不整合やRFC非準拠デバイスなど)や、トラブルシューティングのためにグローバルなSNMPキャッシュのクリアを強制する必要がある場合のみ、-R snmp_cache_reloadを使用してください。
ハウスキーパーの実行をトリガーするためにランタイム制御を使用する例:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R housekeeper_executeログレベルを変更するためにランタイム制御を使用する例:
# すべてのプロセスのログレベルを上げる:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase
# 2番目のポーラープロセスのログレベルを上げる:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=poller,2
# PID 1234のプロセスのログレベルを上げる:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=1234
# すべてのhttp pollerプロセスのログレベルを下げる:
zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_decrease="http poller"HAフェイルオーバー遅延を最小の10秒に設定する例:
zabbix_server -R ha_set_failover_delay=10sプロセスユーザー
Zabbix サーバーは、root 以外のユーザーとして実行するように設計されています。 起動時に指定された root 以外のユーザーで実行されます。 そのため、サーバーは任意の root 以外のユーザーとして問題なく実行できます。
'root' として実行しようとすると、ハードコードされた 'zabbix' ユーザーに切り替わります。このユーザーはシステム上に 存在 している必要があります。 サーバー設定ファイルの 'AllowRoot' パラメーターを適切に変更した場合にのみ、'root' としてサーバーを実行できます。
Zabbix サーバーと エージェント を同じマシンで実行する場合は、サーバーの実行ユーザーをエージェントの実行ユーザーとは別にすることを推奨します。 そうしないと、両方を同じユーザーで実行した場合に、エージェントがサーバー設定ファイルへアクセスできてしまい、Zabbix の Admin 権限を持つユーザーであれば、たとえばデータベースパスワードなどを比較的簡単に取得できてしまいます。
設定ファイル
zabbix_server の設定方法の詳細については、設定ファイル のオプションを参照してください。
起動スクリプト
これらのスクリプトは、システムの起動/シャットダウン時にZabbixプロセスを自動的に開始/停止するために使用されます。 スクリプトはmisc/init.dディレクトリにあります。
サーバーのプロセス種別とスレッド
agent poller- ワーカースレッドを持つ、パッシブチェック用の非同期ポーラープロセス;alert manager- アラートキューのマネージャー;alert syncer- アラートDB書き込みプロセス;alerter- 通知送信プロセス;availability manager- ホストの可用性更新プロセス;browser poller- ブラウザアイテムチェック用のポーラー;configuration syncer- 設定データのメモリ内キャッシュを管理するプロセス;configuration syncer worker- アイテム名内のユーザーマクロ値を解決し、同期するプロセス;connector manager- コネクター用のマネージャープロセス;connector worker- connector manager からの要求を処理するプロセス;discovery manager- デバイス発見のマネージャープロセス;discovery worker- discovery manager からの発見タスクを処理するプロセス;escalator- アクションのエスカレーション処理プロセス;ha manager- 高可用性を管理するプロセス;history poller- データベース接続を必要とする計算チェックを処理するプロセス;history syncer- history DB書き込みプロセス;housekeeper- 古いデータ（アイテム履歴とトレンド、ユーザーセッション、イベントなど）および削除済みオブジェクトに残されたデータを削除するプロセス;http agent poller- ワーカースレッドを持つ、HTTPチェック用の非同期ポーラープロセス;http poller- Web監視ポーラー;icmp pinger- icmppingチェック用のポーラー;internal poller- 内部チェック用のポーラー;ipmi manager- IPMIポーラーマネージャー;ipmi poller- IPMIチェック用のポーラー;java poller- Javaチェック用のポーラー;lld manager- low-level discovery タスクのマネージャープロセス;lld worker- low-level discovery タスクのワーカープロセス;odbc poller- ODBCチェック用のポーラー;poller- パッシブチェック用の通常のポーラー;preprocessing manager- 前処理ワーカースレッドを持つ前処理タスクのマネージャー;preprocessing worker- データ前処理用のスレッド;proxy poller- パッシブプロキシ用のポーラー;proxy group manager- プロキシの負荷分散と高可用性を管理するマネージャー;report manager- スケジュールレポート生成タスクのマネージャー;report writer- スケジュールレポートを生成するプロセス;self-monitoring- サーバー内部統計を収集するプロセス;service manager- history syncer、task manager、alert manager から障害、障害タグ、障害復旧に関する情報を受け取り、サービスを管理するプロセス;snmp poller- ワーカースレッドを持つ、SNMPチェック用の非同期ポーラープロセス（walk[OID]およびget[OID]アイテムのみ）;snmp trapper- SNMPトラップ用のトラッパー;task manager- 他のコンポーネントから要求されたタスク（例: 障害を閉じる、障害を承認する、アイテム値を今すぐ確認する、リモートコマンド機能）をリモート実行するプロセス;timer- メンテナンスを処理するタイマー;trapper- アクティブチェック、トラップ、プロキシ通信用のトラッパー;trigger housekeeper- その後削除されたトリガーによって生成された障害とイベントを削除するプロセス;unreachable poller- 到達不能なデバイス用のポーラー;vmware collector- VMwareサービスからのデータ収集を担当する VMware データコレクター。
サーバーログファイルを使用すると、これらのプロセス種別を確認できます。
Zabbix 7.4.6 以降では、サーバーログファイルはファイル所有者のみが読み書き可能な権限で作成されます。さらに、ファイルは所有者グループによって読み取り可能です。それ以外の権限はすべて拒否されます。
さまざまな種類の Zabbix サーバープロセスは、zabbix[process,<type>,<mode>,<state>] 内部 アイテム を使用して監視できます。
History syncerトランザクション統計
history syncerプロセスのタイトルには、history syncerトランザクションに関する詳細な統計が表示されます。
205182 ? S 0:00 zabbix_server: history syncer #2 [processed 0 values, 0+0 triggers in 0.000021 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]
205183 ? S 0:00 zabbix_server: history syncer #3 [processed 18 values, 7+0 triggers in 0.002612 (0.001108,0.000000,0.000000,0.001208,0.000014) sec, idle 1 sec]
205184 ? S 0:00 zabbix_server: history syncer #4 [processed 0 values, 0+0 triggers in 0.000027 (0.000000,0.000000,0.000000,0.000000,0.000000) sec, idle 1 sec]「A+B triggers」では、次の意味になります。
- A - history valuesに基づいて処理されたトリガー
- B - タイマーに基づいて処理されたトリガー
processed...in N (<timings>) sec の各時間は、次のとおりです。
- アイテム値をデータベースに書き込むのにかかった時間
- アイテムデータ（状態、エラー、ホストインベントリなど）を更新するのにかかった時間
- トレンドをデータベースにフラッシュするのにかかった時間
- トリガーを計算するのにかかった時間
- イベントとアクションを処理するのにかかった時間
サポートされているプラットフォーム
セキュリティ要件やサーバー運用のミッションクリティカルな性質から、UNIXは必要なパフォーマンス、フォールトトレランス、レジリエンスを一貫して提供できる唯一のオペレーティングシステムです。 Zabbixは市場をリードするバージョンで動作します。
Zabbixサーバーは以下のプラットフォームでテストされています:
- Linux
- Solaris
- AIX
- HP-UX
- Mac OS X
- FreeBSD
- OpenBSD
- NetBSD
- SCO Open Server
Zabbixは他のUnix系オペレーティングシステムでも動作する場合があります。
ロケール
サーバーが一部のテキスト項目を正しく解釈できるように、UTF-8ロケールが必要であることに注意してください。 ほとんどの最新のUnix系システムではデフォルトでUTF-8ロケールが設定されていますが、システムによっては明示的に設定する必要がある場合があります。