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

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 トリガーのハウスキーピング手順を開始します。
トリガーのハウスキーピング手順が現在実行中の場合は無視されます。
トリガーのハウスキーピング手順が開始されるまで、削除済みのトリガーによって引き起こされた障害がサービス障害を生成し、サービスに割り当てられる場合があります。頻繁に検出または未検出となるトリガーに基づくサービスのステータス計算ルールが多数設定されている場合は、ProblemHousekeepingFrequencyサーバー設定パラメータを調整して、ハウスキーピング手順の実行頻度を増やすことを検討してください。
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' ユーザーに切り替わります。このユーザーはシステム上に 存在 している必要があります。 サーバー設定ファイルの 'AllowRoot' パラメーターを適切に変更した場合にのみ、'root' としてサーバーを実行できます。

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 - ブラウザアイテムチェック用のポーラー;
  • 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 - 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ロケールが設定されていますが、システムによっては明示的に設定する必要がある場合があります。