[comment]: # aside: 1

[comment]: # ({9146432c-cbb57ea2})
# サーバー

[comment]: # ({/9146432c-cbb57ea2})

[comment]: # ({e9bf5017-0e549571})
### 概要

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

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

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

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

Zabbix のすべての設定情報はデータベースに保存され、サーバーと Webインターフェースの両方がこれにアクセスします。  
たとえば、Webインターフェース（または API）を使用して新しいアイテムを作成すると、そのアイテムはデータベースの items テーブルに追加されます。  
その後、およそ1分ごとに Zabbix サーバーは items テーブルを照会して、アクティブなアイテムの一覧を取得し、それを Zabbix サーバー内のキャッシュに保存します。  
このため、Zabbix Webインターフェースで行った変更が最新データのセクションに反映されるまで、最大で2分かかることがあります。

[comment]: # ({/e9bf5017-0e549571})

[comment]: # ({ba5b7a1d-c20247df})
### サーバーの実行

[comment]: # ({/ba5b7a1d-c20247df})

[comment]: # ({ec500727-1314fd6f})
##### パッケージとしてインストールした場合

Zabbixサーバーはデーモンプロセスとして動作します。
サーバーは以下のコマンドで起動できます。

```bash
systemctl start zabbix-server
```

これはほとんどのGNU/Linuxシステムで動作します。
他のシステムでは、以下のコマンドを実行する必要があるかもしれません。

```bash
/etc/init.d/zabbix-server start
```

同様に、停止/再起動/ステータス表示には以下のコマンドを使用します。

    systemctl stop zabbix-server
    systemctl restart zabbix-server
    systemctl status zabbix-server

[comment]: # ({/ec500727-1314fd6f})

[comment]: # ({3563f7d5-bbb4c5d8})
##### 手動で起動する

上記の方法で動作しない場合は、手動で起動する必要があります。
`zabbix_server` バイナリへのパスを見つけて、次を実行します。

```bash
zabbix_server
```

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

```bash
-c --config <file>              設定ファイルへのパス（デフォルトは /usr/local/etc/zabbix_server.conf）
-f --foreground                 Zabbix サーバーをフォアグラウンドで実行する
-R --runtime-control <option>   管理機能を実行する
-T --test-config                設定ファイルを検証して終了する
-h --help                       このヘルプを表示する
-V --version                    バージョン番号を表示する
```

コマンドラインパラメータを指定して Zabbix サーバーを実行する例:

```bash
zabbix_server -c /usr/local/etc/zabbix_server.conf
zabbix_server --help
zabbix_server -V
```

[comment]: # ({/3563f7d5-bbb4c5d8})

[comment]: # ({78c3080c-a339702b})
##### ランタイム制御

ランタイム制御オプション:

|Option|Description|Target|
|--|------|------|
|`config_cache_reload`|設定キャッシュを再読み込みします。現在キャッシュを読み込み中の場合は無視されます。| |
|`history_cache_clear=target`|IDで指定したアイテムの履歴キャッシュをクリアします。<br>アイテムの最初と最後の値を除く、すべての値に影響します。|**target** - アイテムのID|
|`diaginfo[=<section>]`|サーバーログファイルに診断情報を収集します。|`historycache` - 履歴キャッシュの統計情報;<br>`valuecache` - 値キャッシュの統計情報;<br>`preprocessing` - 前処理マネージャーの統計情報;<br>`alerting` - アラートマネージャーの統計情報;<br>`lld` - LLDマネージャーの統計情報;<br>`locks` - ミューテックスの一覧 (*BSD* システムでは空です);<br>`connector` - キューが最も大きいコネクタの統計情報。|
|`ha_status`|高可用性（HA）クラスターの状態をログに記録します。| |
|`ha_remove_node=target`|名前またはIDで指定した高可用性（HA）ノードを削除します。<br>アクティブ/スタンバイノードは削除できないことに注意してください。|**target** - ノードの名前またはID（`ha_status` を実行して取得できます）。|
|`ha_set_failover_delay=delay`|高可用性（HA）のフェイルオーバー遅延を設定します。<br>[時間サフィックス](/manual/appendix/suffixes)がサポートされています。例: 10s、1m。| |
|`proxy_config_cache_reload[=<target>]`|プロキシの設定キャッシュを再読み込みします。|**target** - プロキシ名のカンマ区切りリスト。<br>target を指定しない場合は、すべてのプロキシの設定を再読み込みします。|
|`secrets_reload`|Vaultからシークレットを再読み込みします。| |
|`service_cache_reload`|サービスマネージャーのキャッシュを再読み込みします。| |
|`snmp_cache_reload`|SNMPキャッシュを再読み込みします — すべてのホストについて、SNMPエンジンのプロパティ（engine time、engine boots、engine id、credentials）をクリアします。SNMPの問題をトラブルシュートする際に、グローバルなキャッシュクリアを強制するために使用します。| |
|`housekeeper_execute`|[housekeeping手順](#housekeeping-procedure)を開始します。<br>housekeeping手順が現在進行中の場合は無視されます。| |
|`trigger_housekeeper_execute`|トリガーの[housekeeping手順](#housekeeping-procedure)を開始します。<br>トリガーのhousekeeping手順が現在進行中の場合は無視されます。| |
|`log_level_increase[=<target>]`|ログレベルを上げます。targetが指定されていない場合は、すべてのプロセスに影響します。<br>*BSD* システムではサポートされていません。|**process type** - 指定した種類のすべてのプロセス（例: `poller`）。<br>すべての[サーバープロセスの種類](#server-process-types-and-threads)を参照してください。<br>**process type,N** - プロセスの種類と番号（例: `poller,3`）。<br>**pid** - プロセス識別子（`1` から `65535`）。より大きい値を指定する場合は、target を 'process type,N' としてください。|
|`log_level_decrease[=<target>]`|ログレベルを下げます。targetが指定されていない場合は、すべてのプロセスに影響します。<br>*BSD* システムではサポートされていません。|^|
|`prof_enable[=<target>]`|プロファイリングを有効にします。<br>targetが指定されていない場合は、すべてのプロセスに影響します。<br>有効化されたプロファイリングでは、関数名ごとのすべてのrwlock/mutexの詳細が提供されます。|**process type** - 指定した種類のすべてのプロセス（例: `history syncer`）<br>プロファイリング対象としてサポートされるプロセスの種類: `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`.<br>**process type,N** - プロセスの種類と番号（例: `history syncer,1`）。<br>**pid** - プロセス識別子（`1` から `65535`）。より大きい値を指定する場合は、target を 'process type,N' としてください。<br>**scope** - `rwlock`, `mutex`, `processing` は、プロセスの種類と番号（例: `history syncer,1,processing`）または種類のすべてのプロセス（例: `history syncer,rwlock`）と組み合わせて使用できます。|
|`prof_disable[=<target>]`|プロファイリングを無効にします。<br>targetが指定されていない場合は、すべてのプロセスに影響します。|**process type** - 指定した種類のすべてのプロセス（例: `history syncer`）。<br>プロファイリング対象としてサポートされるプロセスの種類: `prof_enable` を参照してください。<br>**process type,N** - プロセスの種類と番号（例: `history syncer,1`）。<br>**pid** - プロセス識別子（`1` から `65535`）。より大きい値を指定する場合は、target を 'process type,N' としてください。|

[comment]: # ({/78c3080c-a339702b})

[comment]: # ({7b268db5-1cb7f51c})
サーバーの設定キャッシュをリロードするためにランタイム制御を使用する例:

```bash
zabbix_server -c /usr/local/etc/zabbix_server.conf -R config_cache_reload
```

プロキシの設定をリロードするためにランタイム制御を使用する例:

```bash
# すべてのプロキシの設定をリロード:
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

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

```bash
# サーバーログファイルに利用可能なすべての診断情報を収集:
zabbix_server -R diaginfo

# サーバーログファイルにヒストリキャッシュの統計情報を収集:
zabbix_server -R diaginfo=historycache
```

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

```bash
zabbix_server -R snmp_cache_reload
```

::: noteimportant
SNMPv3インターフェースがZabbix UI経由で更新された場合、ほとんどの場合Zabbixはそのインターフェースの新しいSNMPv3認証情報を自動的にリロードします。認証情報の変更後もポーリングが失敗する場合(例えば、engineBoots/engineIDの不整合やRFC非準拠デバイスなど)や、トラブルシューティングのためにグローバルなSNMPキャッシュのクリアを強制する必要がある場合のみ、`-R snmp_cache_reload`を使用してください。
:::

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

```bash
zabbix_server -c /usr/local/etc/zabbix_server.conf -R housekeeper_execute
```

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

```bash
# すべてのプロセスのログレベルを上げる:
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秒に設定する例:

```bash
zabbix_server -R ha_set_failover_delay=10s
```

[comment]: # ({/7b268db5-1cb7f51c})

[comment]: # ({6b190802-b4f10179})
##### プロセスユーザー

Zabbix サーバーは、root 以外のユーザーとして実行されるように設計されています。  
起動した root 以外のユーザーで実行されます。  
そのため、サーバーは任意の root 以外のユーザーで問題なく実行できます。

'root' として実行しようとすると、ハードコードされた 'zabbix' ユーザーに切り替わります。このユーザーは、システム上に [存在](/manual/installation/install/sources#2-create-user-account) している必要があります。  
サーバーを 'root' として実行できるのは、サーバー設定ファイルの 'AllowRoot' パラメーターを適切に変更した場合のみです。

Zabbix サーバーと [エージェント](agent) を同じマシンで実行する場合は、サーバーの実行ユーザーをエージェントとは別のユーザーにすることを推奨します。  
同じユーザーで両方を実行すると、エージェントがサーバー設定ファイルにアクセスできてしまい、Zabbix の Admin 権限を持つユーザーであれば、たとえばデータベースパスワードなどを簡単に取得できてしまいます。

[comment]: # ({/6b190802-b4f10179})

[comment]: # ({8415824f-0a81f475})
##### 設定ファイル

`zabbix_server` の設定方法の詳細については、[設定ファイル](/manual/concepts/server/server_params) のオプションを参照してください。

[comment]: # ({/8415824f-0a81f475})

[comment]: # ({5d50d9d1-49247ffc})
##### 起動スクリプト

これらのスクリプトは、システムの起動/シャットダウン時にZabbixプロセスを自動的に開始/停止するために使用されます。
スクリプトはmisc/init.dディレクトリにあります。

[comment]: # ({/5d50d9d1-49247ffc})

[comment]: # ({2a38a043-9f05badb})
### サーバーのプロセス種別とスレッド

-   `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サーバープロセスのさまざまな種別は、`zabbix[process,<type>,<mode>,<state>]` 内部 [アイテム](/manual/config/items/itemtypes/internal) を使用して監視できます。

[comment]: # ({/2a38a043-9f05badb})

[comment]: # ({d57cc8df-1737f6e5})
##### History syncerトランザクション統計

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

```bash
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` の各時間は、次のとおりです。

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

[comment]: # ({/d57cc8df-1737f6e5})

[comment]: # ({5f476caf-3ed4827d})
##### ハウスキーピング手順

`housekeeper` プロセスは、定期的に古いデータ（アイテムの履歴とトレンド、ユーザーセッション、イベントなど）および削除されたオブジェクトによって残されたデータを削除します。
この処理はサイクル単位で実行され、実行頻度と1サイクルあたりの削除上限は [`HousekeepingFrequency`](/manual/concepts/server/server_params#housekeepingfrequency) と [`MaxHousekeeperDelete`](/manual/concepts/server/server_params#maxhousekeeperdelete) によって決まります。
1サイクルで削除しきれなかったデータは、次のサイクルに持ち越されます。
自動ハウスキーピングは *Administration > [Housekeeping](/manual/web_interface/frontend_sections/administration/housekeeping)* で有効化および設定できます。

削除されたオブジェクトによって残されたデータを削除するために、`housekeeper` プロセスは `housekeeper` テーブルのタスクに依存します。このテーブルは、オブジェクトが削除されるたびに作成されます。
たとえば、ホストを削除すると、Zabbix はそのアイテムも削除しますが、それらの履歴、トレンド、または問題は削除しません。
代わりに、データベーストリガーが次のフィールドからなるタスクを `housekeeper` テーブルに登録します。

-   `housekeeperid` - タスク ID
-   `object` - オブジェクト種別（`0` - アイテム; `1` - トリガー; `2` - サービス; `3` - 検出されたホスト; `4` - 検出されたサービス）
-   `objectid` - オブジェクト ID（housekeeper がオブジェクト関連データを見つけるのに役立ちます）

たとえば、2つのアイテムと1つのトリガーを持つホストを削除すると、`housekeeper` テーブルは次のようになります。

```default
+---------------+--------+----------+
| 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` プロセスに通知します。

::: noteclassic
別の `trigger housekeeper` プロセスは、より限定されたタスク、つまり既知の原因トリガーを持たない問題とイベントの削除を処理します。
実行頻度は [`ProblemHousekeepingFrequency`](/manual/concepts/server/server_params#problemhousekeepingfrequency) によって制御されます。

トリガーのハウスキーピング手順が開始されるまで、すでに削除されたトリガーによって発生した問題が、引き続きサービス問題を生成し、サービスに割り当てられる場合があります。頻繁に検出/未検出が切り替わるトリガーに基づくサービス [status calculation rules](/manual/it_services/service_tree#service-configuration) を多数使用している構成では、[`ProblemHousekeepingFrequency`](/manual/concepts/server/server_params#problemhousekeepingfrequency) サーバー設定パラメーターを調整して、ハウスキーピング手順の頻度を上げることを検討してください。
:::

-   サービスの場合 - `problems` テーブルを確認し、古いサービスイベントおよび古いサービス問題を削除して、ハウスキーピング時点でそれらを解決します。

-   ネットワークディスカバリの場合 - `problems` テーブルから古いディスカバリーイベントを削除します。

housekeeper は、問題に関連付けられていないイベントのみを削除します。
たとえば、古い問題/復旧イベントは、オープンな問題に関連付けられている場合は削除されません。
housekeeper が古いエンティティを削除する際は、まず問題を削除し、その後にイベントを削除します。

::: noteclassic
`partition` モード（TimescaleDB のパーティション分割テーブル）を使用するテーブルはスキップされます。処理されるのは `regular` モードを使用するテーブルのみです。
:::

[comment]: # ({/5f476caf-3ed4827d})

[comment]: # ({eb5fd3dc-cdd68340})
### サポート対象プラットフォーム

セキュリティ要件とサーバー運用のミッションクリティカルな性質により、必要な性能、フォールトトレランス、およびレジリエンスを一貫して提供できるのは UNIX のみです。  
Zabbix は、市場をリードする各バージョンで動作します。

Zabbix サーバーは、以下のプラットフォームでテストされています。

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

::: noteclassic
Zabbix は、他の Unix 系オペレーティングシステムでも動作する場合があります。
:::

[comment]: # ({/eb5fd3dc-cdd68340})

[comment]: # ({f19f38cc-982e2546})
### ロケール

サーバーでは、一部のテキストアイテムを正しく解釈できるように、UTF-8 ロケールが必要です。
多くの最新の Unix 系システムでは UTF-8 ロケールがデフォルトになっていますが、システムによっては明示的に設定する必要があります。

[comment]: # ({/f19f38cc-982e2546})