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_server

Zabbix サーバーでは、次のコマンドラインパラメータを使用できます。

-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 - 履歴キャッシュの統計情報;
valuecache - 値キャッシュの統計情報;
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）のフェイルオーバー遅延を設定します。
時間サフィックスがサポートされています。例: 10s、1m。
proxy_config_cache_reload[=<target>] プロキシの設定キャッシュを再読み込みします。 target - プロキシ名のカンマ区切りリスト。
target を指定しない場合は、すべてのプロキシの設定を再読み込みします。
secrets_reload Vaultからシークレットを再読み込みします。
service_cache_reload サービスマネージャーのキャッシュを再読み込みします。
snmp_cache_reload SNMPキャッシュを再読み込みします — すべてのホストについて、SNMPエンジンのプロパティ（engine time、engine boots、engine id、credentials）をクリアします。SNMPの問題をトラブルシュートする際に、グローバルなキャッシュクリアを強制するために使用します。
housekeeper_execute housekeeping手順を開始します。
housekeeping手順が現在進行中の場合は無視されます。
trigger_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）
プロファイリング対象としてサポートされるプロセスの種類: 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=historycache

SNMPキャッシュをリロードするためにランタイム制御を使用する例:

zabbix_server -R snmp_cache_reload

SNMPv3インターフェースが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' ユーザーに切り替わります。このユーザーは、システム上に存在している必要があります。
サーバーを 'root' として実行できるのは、サーバー設定ファイル内の 'AllowRoot' パラメータをそれに応じて変更した場合のみです。

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 - 低レベルディスカバリータスクの管理プロセス。
  • lld worker - 低レベルディスカバリータスクのワーカープロセス。
  • 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サーバープロセスのさまざまな種類は、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 の各時間は、次のとおりです。

  • アイテム値をデータベースに書き込むのにかかった時間
  • アイテムデータ（状態、エラー、ホストインベントリなど）を更新するのにかかった時間
  • トレンドをデータベースにフラッシュするのにかかった時間
  • トリガーを計算するのにかかった時間
  • イベントとアクションを処理するのにかかった時間
ハウスキーピング手順

housekeeper プロセスは、古くなったデータ（アイテムの履歴とトレンド、ユーザーセッション、イベントなど）および削除されたオブジェクトによって残されたデータを定期的に削除します。 このプロセスはサイクル単位で実行され、実行頻度と1サイクルあたりの削除上限は HousekeepingFrequency と MaxHousekeeperDelete によって決まります。 1回のサイクルで削除されなかったデータは、次のサイクルに持ち越されます。 自動ハウスキーピングは、Administration > Housekeeping で有効化および設定できます。

削除されたオブジェクトによって残されたデータを削除するために、housekeeper プロセスは housekeeper テーブルのタスクを利用します。このテーブルは、オブジェクトが削除されるたびに投入されます。 たとえば、ホストを削除すると、Zabbix はそのアイテムも削除しますが、それらの履歴、トレンド、または問題は削除しません。 代わりに、データベーストリガーが次のフィールドからなるタスクを housekeeper テーブルに投入します。

  • housekeeperid - タスク ID
  • object - オブジェクト種別 (0 - アイテム; 1 - トリガー; 2 - サービス; 3 - 検出されたホスト; 4 - 検出されたサービス)
  • objectid - オブジェクト ID（housekeeper がオブジェクト関連データを見つけるのに役立ちます）

たとえば、2つのアイテムと1つのトリガーを持つホストを削除すると、housekeeper テーブルは次のようになります。

+---------------+--------+----------+
| housekeeperid | object | objectid |
+---------------+--------+----------+
|             1 |      1 |    28724 |
|             2 |      0 |    59396 |
|             3 |      0 |    59397 |
+---------------+--------+----------+

データベーストリガーは、オブジェクト関連データの有無を確認せずに housekeeper テーブルへ投入します。その確認は housekeeper プロセスが行います。

各タスクは、オブジェクト種別に応じて1つ以上の housekeeper 操作を発生させます。

  • アイテム（LLD ルールを含む）の場合 - それらのアイテムの値を含むすべての履歴およびトレンドテーブル（history, history_str, history_log, history_uint, history_text, history_bin, history_json, trends, trends_uint）からデータを削除します。 また、problems テーブルを確認し、それらのアイテムに関連付けられた古い内部イベントを削除します。

  • トリガーの場合 - イベント関連テーブル（problem, event_symptom, event_recovery, events）を確認し、それらのトリガーに関連付けられた古いイベントを削除します。また、削除されたイベントについて service manager プロセスに通知します。

別の trigger housekeeper プロセスが、より限定されたタスク、つまり既知のソーストリガーを持たない問題とイベントの削除を処理します。 実行頻度は ProblemHousekeepingFrequency によって制御されます。

トリガーハウスキーピング手順が開始されるまで、すでに削除されたトリガーによって発生した問題が、引き続きサービス問題を生成し、それらをサービスに割り当てる場合があります。頻繁に検出/未検出されるトリガーに基づくサービス status calculation rules が多数ある構成では、ProblemHousekeepingFrequency サーバー設定パラメーターを調整して、ハウスキーピング手順の頻度を増やすことを検討してください。

  • サービスの場合 - problems テーブルを確認し、古いサービスイベントおよび古いサービス問題を削除して、ハウスキーピング時点でそれらを解決済みにします。

  • ネットワークディスカバリの場合 - problems テーブルから古いディスカバリイベントを削除します。

housekeeper は、問題に関連付けられていないイベントのみを削除します。 たとえば、古い問題/復旧イベントは、未解決の問題に関連付けられている場合は削除されません。 housekeeper が古いエンティティを削除する際は、まず問題を削除し、その後イベントを削除します。

partition モード（TimescaleDB のパーティション分割テーブル）を使用するテーブルはスキップされます。処理されるのは regular モードを使用するテーブルのみです。

サポートされているプラットフォーム

セキュリティ要件やサーバー運用のミッションクリティカルな性質から、UNIXは必要なパフォーマンス、フォールトトレランス、レジリエンスを一貫して提供できる唯一のオペレーティングシステムです。 Zabbixは市場をリードするバージョンで動作します。

Zabbixサーバーは以下のプラットフォームでテストされています:

  • Linux
  • Solaris
  • AIX
  • HP-UX
  • Mac OS X
  • FreeBSD
  • OpenBSD
  • NetBSD
  • SCO Open Server

Zabbixは他のUnix系オペレーティングシステムでも動作する場合があります。

ロケール

サーバーが一部のテキスト項目を正しく解釈できるように、UTF-8ロケールが必要であることに注意してください。 ほとんどの最新のUnix系システムではデフォルトでUTF-8ロケールが設定されていますが、システムによっては明示的に設定する必要がある場合があります。