1 Zabbixサーバー

概要

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

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

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

基本的な Zabbix サーバーの動作は、Zabbix サーバー、Webインターフェース、データベースストレージという3つの異なるコンポーネントに分かれています。

Zabbix のすべての設定情報はデータベースに保存され、サーバーと Webインターフェースの両方がこれにアクセスします。
たとえば、Webインターフェース(または API)を使用して新しいアイテムを作成すると、そのアイテムはデータベースの items テーブルに追加されます。
その後、およそ1分ごとに Zabbix サーバーは 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 設定キャッシュを再読み込みします。現在キャッシュを読み込み中の場合は無視されます。
diaginfo[=<section>] サーバーのログファイルに診断情報を収集します。 historycache - history cache の統計;
valuecache - value cache の統計;
preprocessing - 前処理マネージャーの統計;
alerting - アラートマネージャーの統計;
lld - LLDマネージャーの統計;
locks - mutex の一覧 (BSD システムでは空です);
connector - 最もキューが大きい 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エンジンのプロパティー(エンジン時間、エンジン起動回数、エンジンID、認証情報)をすべてのホストでクリアします。SNMPの問題をトラブルシューティングする際に、グローバルなキャッシュクリアを強制するために使用します。
housekeeper_execute housekeeping 手順を開始します。
housekeeping 手順が現在進行中の場合は無視されます。
trigger_housekeeper_execute トリガーの housekeeping 手順を開始します。
トリガーの housekeeping 手順が現在進行中の場合は無視されます。
トリガーの housekeeping 手順が開始されるまで、すでに削除されたトリガーによって発生した障害が、サービス障害として生成され、サービスに割り当てられる場合があります。構成に、頻繁に検出/未検出となるトリガーに基づく多数のサービスステータス計算ルールが含まれる場合は、ProblemHousekeepingFrequency サーバー設定パラメーターを調整して、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 -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 - 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 7.0.22以降では、サーバーログファイルはファイル所有者に対してのみ読み書き権限付きで作成されます。さらに、ファイルは所有者グループによって読み取り可能です。それ以外の権限はすべて拒否されます。

さまざまな種類の Zabbix サーバープロセスは、zabbix[process,<type>,<mode>,<state>] 内部 アイテム を使用して監視できます。

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

サーバーの処理のセキュリティ要件やミッションクリティカルな性質から、必要なパフォーマンス、フォールトトレランス、および復元力を一貫して提供できる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ロケールがありますが、システムによっては具体的に設定しなければ使用することができません。