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サーバーはデーモンプロセスとして実行されます。サーバーを起動するには以下を実行します。

shell> systemctl start zabbix-server

これはほとんどのGNU/Linuxシステムで動きます。他のシステムでは、以下のように実行する必要がある場合があります。

shell> /etc/init.d/zabbix-server start

同様に、停止/再起動/ステータス表示するには以下を実行します。

shell> systemctl stop zabbix-server
       shell> systemctl restart zabbix-server
       shell> systemctl status zabbix-server
手動での起動

上記の方法で起動できない場合は、手動で起動する必要があります。zabbix_serverのバイナリを見つけて、以下のように実行します:

shell> zabbix_server

Zabbixサーバーでは、以下のコマンドラインパラメーターを使用できます:

-c --config <file>              設定ファイルを絶対パスで指定します。(デフォルトは/usr/local/etc/zabbix_server.conf)
       -f --foreground                 Zabbixサーバーをフォアグラウンドで実行します。
       -R --runtime-control <option>   管理用のランタイムコマンドを実行します。
       -h --help                       ヘルプを表示します。
       -V --version                    バージョン情報を表示します。

Zabbixサーバーのコマンドラインパラメータの使用例です:

shell> zabbix_server -c /usr/local/etc/zabbix_server.conf
       shell> zabbix_server --help
       shell> zabbix_server -V
ランタイムコントロール

ランタイムコントロールオプション :

オプション 説明 ターゲット
config_cache_reload 設定キャッシュをリロードします。 キャッシュが現在ロード中の場合は無視されます。
diaginfo[=<section>] サーバーのログファイルに診断情報を収集します。 historycache - ヒストリキャッシュの統計
valuecache - 値キャッシュの統計
preprocessing - 前処理マネージャー統計
alerting - アラートマネージャーの統計
lld - LLDマネージャーの統計
locks - ミューテックスのリスト (BSD systemでは空です)
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、認証情報) をクリアします。
housekeeper_execute ハウスキーピングプロシージャを開始します。ハウスキーピングプロシージャが現在進行中の場合は無視されます。
trigger_housekeeper_execute サービスのトリガーハウスキーピング手順を開始して、削除されたトリガーによって引き起こされた障害 (ハウスキーピングの時点で解決されたとみなされる) によって生成されたサービスの障害も含めて、障害を削除します。
ハウスキーピングプロシージャが開始されるまでは、現在削除されているトリガーによって引き起こされる障害が引き続きサービスの障害を生成し、それらがサービスに割り当てられる可能性があることに注意してください。

セットアップに、頻繁に検出/未検出のトリガーに基づく多くのサービス ステータス計算ルールが含まれる場合は、ProblemHousekeepingFrequencyサーバー構成パラメーターを調整して、トリガーハウスキーピングプロシージャの頻度を増やすことを検討してください。

ハウスキーピングプロシージャが現在進行中の場合は無視されます。
log_level_increase[=<target>] ログレベルを上げます。ターゲットが指定されていない場合、すべてのプロセスに影響します。
BSD システムではサポートされていません。
process type - 指定されたタイプのすべてのプロセス (ポーラーなど)
全てのサーバープロセスの種類を確認する。
process type,N - プロセスの種類と数 (例: poller,3)
pid - プロセスID(1 ~ 65535)。より大きな値の場合は、ターゲットを'process type,N'として指定します。
log_level_decrease[=<target>] ログレベルを下げます。ターゲットが指定されていない場合、すべてのプロセスに影響します。
BSD システムではサポートされていません。
prof_enable[=<target>] プロファイリングを有効にします。
ターゲットが指定されていない場合、すべてのプロセスに影響します。
有効なプロファイリングでは、関数名ごとにすべての rwlocks/mutex の詳細が提供されます。
process type - 指定されたタイプのすべてのプロセス(history syncerなど)
プロファイリングターゲットとしてサポートされるプロセスタイプ : alerter, alert manager, availability manager, configuration syncer, discoverer, 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 - プロセスID (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 - プロセスID(1 ~ 65535)。より大きな値の場合は、ターゲットを'process type,N'として指定します。

ランタイム制御を使用してサーバー構成キャッシュをリロードする例 :

shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R config_cache_reload

ランタイム制御を使用してプロキシ構成をリロードする例 :

すべてのプロキシの設定をリロードします :
       shell> zabbix_server -R proxy_config_cache_reload
       
       Proxy1とProxy2の設定をリロードします :
       shell> zabbix_server -R proxy_config_cache_reload=Proxy1,Proxy2

ランタイム制御を使用して診断情報を収集する例 :

# サーバー ログ ファイルで利用可能なすべての診断情報を収集 :
       shell> zabbix_server -R diaginfo
       
       # サーバー ログ ファイルで履歴キャッシュ統計を収集 :
       shell> zabbix_server -R diaginfo=historycache

ランタイム制御を使用してSNMPキャッシュをリロードする例 :

shell> zabbix_server -R snmp_cache_reload  

ランタイム制御を使用してハウスキーパーの実行をトリガーする例 :

shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R housekeeper_execute

ランタイム制御を使用してログレベルを変更する例 :

# すべてのプロセスのログレベルを上げる :
       shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase
       
       # 2番目のポーラープロセスのログレベルを上げる :
       shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=poller,2
       
       # PID1234のプロセスのログレベルを上げる :
       shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_increase=1234
       
       # すべてのhttpポーラープロセスのログレベルを下げる :
       shell> zabbix_server -c /usr/local/etc/zabbix_server.conf -R log_level_decrease="http poller"

HAフェイルオーバー遅延を最小10秒に設定する例 :

shell> 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ディレクトリの下にあります。

サーバープロセスの種類

  • alert manager - アラート・キュー・マネージャー
  • alert syncer - アラート DB ライター
  • alerter - 通知の送信プロセス
  • availability manager - ホスト可用性の更新プロセス
  • configuration syncer - 設定データのメモリ内キャッシュを管理するプロセス
  • connector manager - コネクタのマネージャープロセス
  • connector worker - コネクタマネージャーからのリクエストを処理するプロセス
  • discoverer - デバイス検出プロセス
  • escalator - アクションエスカレーションのプロセス
  • ha manager - 高可用性を管理するプロセス
  • history poller - データベース接続を必要とする計算された内部チェックを処理するためのプロセス
  • history syncer - ヒストリDBライター
  • housekeeper - 古いヒストリデータの削除プロセス
  • http poller - ウェブ監視ポーラー
  • icmp pinger - icmppingチェックのポーラー
  • ipmi manager - IPMIポーラーマネージャー
  • ipmi poller - IPMIチェックのポーラー
  • java poller - Javaチェックのポーラー
  • lld manager - ローレベルディスカバリタスクのマネージャプロセス
  • lld worker - ローレベルディスカバリタスクのワーカープロセス
  • odbc poller - ODBCチェックのポーラー
  • poller - パッシブチェック用の通常のポーラー
  • preprocessing manager - 前処理タスクのマネージャー
  • preprocessing worker - データ前処理のプロセス
  • proxy poller - パッシブプロキシのポーラー
  • report manager- スケジュールされたレポート生成タスクのマネージャー
  • report writer - スケジュールされたレポートを生成するプロセス
  • self-monitoring - 内部サーバー統計を収集するためのプロセス
  • service manager - ヒストリ同期機能、タスクマネージャー、アラートマネージャーから障害、障害タグ、障害回復に関する情報を受信して​​サービスを管理するプロセス
  • snmp trapper - SNMPトラップのトラッパー
  • task manager - 他のコンポーネントによって要求されたタスクをリモートで実行するためのプロセス (例: 障害のクローズ、障害の確認、項目値の即時チェック、リモートコマンド機能)
  • timer - メンテナンス処理用タイマー
  • trapper - アクティブチェック、トラップ、プロキシ通信用のトラッパー
  • trigger housekeeper - 削除されたトリガーによって発生した障害を除去するプロセス
  • unreachable poller - 到達不能デバイスのポーラー
  • vmware collector - VMwareサービスからのデータ収集を担当するVMwareデータコレクター

サーバー ログ ファイルを使用して、これらのプロセス タイプを監視できます。

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

サポートされているプラットフォーム

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

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

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

Zabbixは、他のUNIX系OSでも同様に動作します。

ロケール

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