サーバー

概要

Zabbixサーバーは、Zabbixソフトウェアの中心となるプロセスです。

サーバーはデータのポーリングとトラッピングを行い、トリガーを計算し、ユーザーに通知を送信します。
また、Zabbix エージェントとプロキシがシステムの可用性と整合性に関するデータを報告する中心的なコンポーネントでもあります。
サーバー自身も、簡単なサービスチェックを使用して、ネットワーク上のサービス（Webサーバーやメールサーバーなど）をリモートで確認できます。

サーバーは、すべての設定、統計、および運用データが保存される中央リポジトリであり、監視対象のいずれかのシステムで問題が発生した際に、管理者へ積極的に警告を発する Zabbix の主体です。

基本的な Zabbix サーバーの動作は、次の3つの明確なコンポーネントに分かれています。Zabbix サーバー、Webインターフェース、およびデータベースストレージです。

Zabbix のすべての設定情報はデータベースに保存され、サーバーと Webインターフェースの両方がこれにアクセスします。
たとえば、Webインターフェース（または API）を使用して新しいアイテムを作成すると、そのアイテムはデータベースの items テーブルに追加されます。
その後、およそ1分ごとに Zabbix サーバーは items テーブルを照会して、アクティブなアイテムの一覧を取得し、それを Zabbix サーバー内のキャッシュに保存します。
このため、Zabbix frontend で行った変更が最新データのセクションに反映されるまで、最大で2分かかることがあります。

関連情報:

サーバーの実行

パッケージとしてインストールされている場合

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 サーバーでは、次のコマンドラインパラメータを使用できます。

Parameter Description
-c --config <config-file> 設定ファイルへのパス。
-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
ランタイム制御

ランタイム制御オプション:

オプション 説明 対象
config_cache_reload 設定キャッシュを再読み込みします。キャッシュの読み込み中の場合は無視されます。
history_cache_clear=target IDで指定したアイテムの履歴キャッシュをクリアします。
アイテムの最初と最後の値を除く、すべての値に影響します。		 target - アイテムのID
diaginfo[=<section>] 診断情報をサーバーのログファイルに収集します。 historycache - 履歴キャッシュの統計情報;
valuecache - value cacheの統計情報;
preprocessing - 前処理マネージャーの統計情報;
alerting - アラートマネージャーの統計情報;
lld - LLDマネージャーの統計情報;
locks - mutexの一覧（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 - プロキシ名をカンマ区切りで指定したリスト。
対象を指定しない場合、すべてのプロキシの設定を再読み込みします。
secrets_reload Vaultからシークレットを再読み込みします。
service_cache_reload サービスマネージャーのキャッシュを再読み込みします。
snmp_cache_reload SNMPキャッシュを再読み込みします。すべてのホストについて、SNMPエンジンのプロパティ（エンジン時間、エンジンブート、エンジンID、認証情報）をクリアします。SNMPの問題をトラブルシューティングする際に、グローバルキャッシュを強制的にクリアするために使用します。
housekeeper_execute ハウスキーピング手順を開始します。
ハウスキーピング手順の実行中の場合は無視されます。
trigger_housekeeper_execute トリガーのハウスキーピング手順を開始します。
トリガーのハウスキーピング手順の実行中の場合は無視されます。
log_level_increase[=<target>] ログレベルを上げます。対象を指定しない場合、すべてのプロセスに影響します。
BSDシステムではサポートされません。		 process type - 指定したタイプのすべてのプロセス（例: poller）。
すべてのサーバープロセスタイプを参照してください。
process type,N - プロセスタイプと番号（例: poller,3）。
pid - プロセス識別子（1から65535）。これより大きい値を指定する場合は、対象を「process type,N」として指定してください。
log_level_decrease[=<target>] ログレベルを下げます。対象を指定しない場合、すべてのプロセスに影響します。
BSDシステムではサポートされません。
prof_enable[=<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、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）。これより大きい値を指定する場合は、対象を「process type,N」として指定してください。
scope - rwlock、mutex、processingを、プロセスタイプと番号（例: history syncer,1,processing）またはそのタイプのすべてのプロセス（例: history syncer,rwlock）とともに使用できます。
prof_disable[=<target>] プロファイリングを無効にします。
対象を指定しない場合、すべてのプロセスに影響します。		 process type - 指定したタイプのすべてのプロセス（例: history syncer）。
プロファイリング対象としてサポートされるプロセスタイプ: prof_enableを参照してください。
process type,N - プロセスタイプと番号（例: history syncer,1）。
pid - プロセス識別子（1から65535）。これより大きい値を指定する場合は、対象を「process type,N」として指定してください。

実行時制御の対象としてプロセス種別を指定した場合、そのコマンドはその種別の実行中プロセスにのみ適用されます。 指定した種別のプロセスが現在実行されていない場合、コマンドはエラーを返します。

zabbix_server -R log_level_increase='discovery manager'
Cannot redirect signal: "discovery manager" process does not exist

サーバーの設定キャッシュを再読み込みするために実行時制御を使用する例:

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 認証情報を自動的に再読み込みします。-R snmp_cache_reload は、認証情報の変更後もポーリングが失敗し続ける場合（たとえば、engineBoots/engineID の不整合や RFC 非準拠デバイスが原因の場合）や、トラブルシューティングのためにグローバルな SNMP キャッシュのクリアを強制したい場合にのみ使用してください。

housekeeper の実行をトリガーするために実行時制御を使用する例:

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番目の poller プロセスのログレベルを上げる:
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のインストール方法によって異なります。

  • ソースからインストールした場合: /usr/local/etc/zabbix_server.conf、またはコンパイル時の変数 --sysconfdir または --prefix で設定したパス。
  • パッケージおよびアプライアンスからインストールした場合: /etc/zabbix/zabbix_server.conf。

zabbix_serverの設定方法については、設定ファイルのオプションを参照してください。

起動スクリプト

これらのスクリプトは、システムの起動/シャットダウン時にZabbixプロセスを自動的に開始/停止するために使用されます。 スクリプトはmisc/init.dディレクトリにあります。

サーバープロセスの種類とスレッド

  • agent poller - パッシブチェック用の非同期ポーラープロセスで、ワーカースレッドを持ちます;
  • alert manager - アラートキューのマネージャー;
  • alert syncer - アラートDB書き込みプロセス;
  • alerter - 通知送信プロセス;
  • availability manager - ホストの可用性更新プロセス;
  • browser poller - browser アイテムチェック用のポーラー;
  • configuration syncer - 設定データのメモリ内キャッシュを管理するプロセス;
  • configuration syncer worker - アイテム名におけるユーザーマクロ値を解決および同期するプロセス;
  • connector manager - connector 用のマネージャープロセス;
  • 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トラップ用のトラッパー;
  • supervisor - サーバープロセスとスレッドの起動および停止を調整し、それらの準備完了状態を監視します;
  • 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 の各時間は、次のとおりです。

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

housekeeper プロセスは、定期的に古いデータ（アイテム履歴やトレンド、ユーザーセッション、イベントなど）および削除されたオブジェクトに残されたデータを削除します。 この処理はサイクル単位で実行され、実行頻度と 1 サイクルあたりの削除上限は HousekeepingFrequency と MaxHousekeeperDelete によって決まります。 1 サイクルで削除しきれなかったデータは、次のサイクルに持ち越されます。 自動 housekeeping は 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 プロセスがデータを削除する際に行います。

  • 削除されたアイテム（LLD ルールを含む）については、すべての履歴およびトレンドテーブル（history, history_str, history_log, history_uint, history_text, history_bin, history_json, trends, trends_uint）からそのデータを削除します。 また、problem テーブルから内部イベントも削除します。

  • 削除されたトリガーについては、イベント関連テーブル（problem, event_symptom, events; データベース自体も event_recovery テーブルからイベントを削除します）からそのイベントを削除します。 また、削除されたイベントについて service manager プロセスに通知します。

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

トリガー housekeeping procedure が開始されるまで、すでに削除されたトリガーによって作成された障害が、引き続きサービス障害を生成し、サービスに割り当てられる場合があります。 構成に、頻繁に発見/未発見となるトリガーに基づく多数のサービス status calculation rules が含まれる場合は、ProblemHousekeepingFrequency サーバー設定パラメータを調整して、housekeeping procedure の頻度を上げることを検討してください。

  • 削除されたサービスについては、problem テーブルからその障害を削除します。events テーブルからのイベント削除は、設定された data storage period の後にのみ行われます。

  • 削除された発見済みホスト/サービス（network discovery）については、events テーブルからそのイベントを削除します。

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 ロケールがデフォルトになっていますが、システムによっては明示的に設定する必要があります。