1 Zabbixサーバー

概要

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

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

サーバーは、すべての設定、統計、運用データが保存される中央リポジトリであり、監視対象システムのいずれかで問題が発生した場合に、管理者に積極的にアラートを送信するZabbixのエンティティです。

基本的なZabbixサーバーの機能は、3つの異なるコンポーネントに分かれています。それらは、Zabbixサーバー、Webフロントエンド、データベースストレージです。

Zabbixのすべての設定情報はデータベースに保存されており、サーバーとWebフロントエンドの両方がデータベースとやり取りします。 たとえば、Webフロントエンド（またはAPI）を使用して新しいアイテムを作成すると、それはデータベースのitemsテーブルに追加されます。 その後、約1分ごとにZabbixサーバーはitemsテーブルをクエリし、アクティブなアイテムのリストを取得し、それをZabbixサーバー内のキャッシュに保存します。 このため、Zabbixフロントエンドで行った変更が最新データセクションに反映されるまでに最大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) のフェイルオーバー遅延を設定します。
Time suffixes がサポートされています。例: 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 ハウスキーピング手順 を開始します。
ハウスキーピング手順が現在進行中の場合は無視されます。
trigger_housekeeper_execute トリガーのハウスキーピング手順 を開始します。
トリガーのハウスキーピング手順が現在進行中の場合は無視されます。
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が指定されていない場合は、すべてのプロセスに影響します。
プロファイリングを有効にすると、すべての rwlocks/mutexes の詳細が関数名ごとに提供されます。		 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の管理者レベルのユーザーであれば、たとえばデータベースのパスワードなどを簡単に取得できてしまいます。

設定ファイル

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 - 履歴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>] を使用して監視できます。

ヒストリーシンカーのトランザクション統計

ヒストリーシンカーのプロセスタイトルには、ヒストリーシンカーのトランザクションに関する詳細な統計情報が表示されます。

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 - ヒストリ値によって処理されたトリガー数
  • 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 によって制御されます。

トリガーハウスキーピング手順が開始されるまで、すでに削除されたトリガーによって発生した障害が、引き続きサービス障害を生成し、それらをサービスに割り当てる可能性があります。セットアップに、頻繁にディスカバリ/未ディスカバリされるトリガーに基づく多数のサービスステータス計算ルールが含まれる場合は、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ロケールが設定されていますが、システムによっては明示的に設定する必要がある場合があります。