1 Zabbixサーバー

概要

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

Zabbixサーバーは、データのポーリングとトラッピングを処理し、それをトリガーによって判断し、ユーザーに対して通知を行います。ZabbixエージェントやZabbixプロキシからシステムの可用性と整合性に関するデータを受け取る中核となるコンポーネントです。Zabbixサーバー自体は、シンプルなサービスチェックの機能を使用して、ネットワークに接続されたサービス（Webサーバーやメールサーバーなど）をリモートからチェックすることができます。

Zabbixサーバーは、すべての設定、統計、運用データが保存される中核となるリポジトリで、監視対象のシステムで障害が発生したときに、管理者に対して能動的に警告を通知する役割を担います。

Zabbixサーバーの基本的な機能は、3つの異なるコンポーネントに分けられます。その3つとは、Zabbixサーバー、Webインターフェース、データベースストレージです。

Zabbixのすべての設定情報はデータベース上に保存され、ZabbixサーバーとWebインターフェースの両方がそのデータベースと通信します。例えば、Webインターフェース（またはAPI）を使用して新しいアイテムを作成した時には、データベース内のitemsテーブルに追加されます。次に、Zabbixサーバーはおよそ1分ごとに有効なアイテムの一覧を取得するためitemsテーブルを検索し、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 ハウスキーピング 手順を開始します。
ハウスキーピング手順が現在進行中の場合は無視されます。
trigger_housekeeper_execute トリガーのハウスキーピング手順を開始します。
トリガーのハウスキーピング手順が現在進行中の場合は無視されます。
トリガーのハウスキーピング手順が開始されるまで、すでに削除されたトリガーによって発生した障害が、引き続きサービス障害を生成し、それらをサービスに割り当てる可能性があります。頻繁に検出/未検出されるトリガーに基づくサービスのステータス計算ルールが多数ある構成では、ProblemHousekeepingFrequency サーバー設定パラメータを調整して、ハウスキーピング手順の頻度を増やすことを検討してください。
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

Zabbix UIを介してSNMPv3インターフェースが更新されると、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ポーラープロセスのログレベルを下げる:
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エージェントが同じマシン上で動作する場合、サーバーの実行とエージェントの実行に、異なるユーザーを使用することをお勧めします。どちらも同じユーザーで実行されている場合、エージェントはサーバーの設定ファイルにアクセスでき、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 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 - ヒストリ値に基づいて処理されたトリガー。
  • B - タイマーに基づいて処理されたトリガー。

"processed...in N (<timings>) sec"で示される処理時間は以下のとおりです:

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

サポートするプラットフォーム

サーバーの処理のセキュリティ要件やミッションクリティカルな性質から、必要なパフォーマンス、フォールトトレランス、および復元力を一貫して提供できるOSはUNIXだけです。Zabbixは市場に出回っているバージョンで動作します。

Zabbixサーバーは以下のプラットフォーム上で動作確認済みです:

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

Zabbixは他のUNIX系OSでも動作する可能性があります。

ロケール

いくつかのテキスト形式のアイテムを正しく処理できるようにするため、サーバーにはUTF-8のロケールが必要であることに注意してください。最近のほとんどのUNIXライクなシステムにはデフォルトでUTF-8ロケールがありますが、システムによっては具体的に設定しなければ使用することができません。