[comment]: # ({6d5b9456-953eaff1})
# 2 設定のベストプラクティス

[comment]: # ({/6d5b9456-953eaff1})

[comment]: # ({b2dac4c8-93555269})
#### 概要

このセクションでは、Zabbixを最適なパフォーマンスと使いやすさで構成するためのベストプラクティスを説明します。
これらの推奨事項は、Zabbix開発者のアドバイスと、Zabbixトレーナーやサポートエンジニアの実践的な経験に基づいています。

すべてのZabbixインストールはユニークであり、これらのガイドラインの一部が特定の構成に適さない場合があります。
ただし、一般的な潜在的な問題を回避するために、できるだけこれらのガイドラインに従うことをお勧めします。

:::notetip
このページが改善できると思われる場合は、ぜひご意見をお聞かせください！該当するテキストをハイライトし、**ctrl+Enter**を押して間違いを報告したり、フィードバックを共有したりしてください。
:::

[comment]: # ({/b2dac4c8-93555269})

[comment]: # ({5cfb221c-254c383a})
### ホストとアイテム

[comment]: # ({/5cfb221c-254c383a})

[comment]: # ({392a841a-3a81cc27})
##### ホストの定義

Zabbixにおけるホストは、物理的なマシンやデバイスではなく、論理的なエンティティです。
監視の目的で、データベースや仮想マシンなど、個別のホストを作成することができます。
あるいは、*Johnのノートパソコン*のような汎用ホストを作成し、そのホストの下ですべてのメトリックを監視することもできます。

ベストプラクティスは、仮想マシン、データベース、コンテナ、ネットワークスイッチなど、独立したインスタンスごとに個別のホストを作成することです。このアプローチを利用することで、以下のメリットがあります。

1. 各ホストごとに個別のアイテム、トリガー、アラート通知を持つことで、監視データの混乱を避けることができます。

2. ユーザーアクセスレベルを細かく調整できます。
[ユーザーロール](/manual/web_interface/frontend_sections/users/user_roles)を設定して、特定のホストの閲覧や設定のみを許可することができます。
[最小権限の原則](/manual/best_practices/security/access_control#principle-of-least-privilege)も参照してください。

[comment]: # ({/392a841a-3a81cc27})

[comment]: # ({5ec9d412-c3c86ff6})
##### 重複したアイテムを持つホスト

*Network switch 1*や*Network switch 2*のように、いくつかの類似したホストがある場合、Zabbixはホストを迅速に再作成するための複数の方法を提供します。
Cloneボタンを押すだけで、すべてのメトリクスを持つホストを単純にクローンできますが、この場合、後でアイテムを更新するには、各ホストで手動で行う必要があります。

ベストプラクティスは、必要なすべてのメトリクスを持つテンプレート、たとえば*Network switch template*を作成することです。
次に、類似したホストをホストグループにまとめます。上記の例では*Network switches*となります。
これで、*データ収集 -> ホスト*セクションでホストグループごとにすべてのホストをフィルタリングし、*一括更新*ボタンを使用してテンプレートをすべてのネットワークスイッチにリンクできます。

[comment]: # ({/5ec9d412-c3c86ff6})

[comment]: # ({5f683345-ac526159})
##### 依存アイテム

ターゲットエンティティへのリクエスト数を最小限に抑えるために、Zabbixではマスターアイテムと依存アイテムを作成することができます。
この場合、マスターアイテムは1回のリクエストで大量の情報を収集します。
その後、依存アイテムを設定して、前処理を通じてそのコレクションから特定のデータを抽出し、個別のメトリクスとして保存することができます。

例えば、マスターアイテムが複数のメトリクスを含むJSONやXMLレスポンスを収集したり、複数のカラム（例：オープン接続数、中断された接続数、同時接続の最大許容数、起動後の累積接続数など）を返すデータベースクエリを実行したりし、依存アイテムがそれぞれ必要な値を個別に解析して保存します。

この構成のベストプラクティスは、収集直後にマスターアイテムの履歴を破棄し、依存アイテムのデータのみを保持することです。

[comment]: # ({/5f683345-ac526159})

[comment]: # ({5b256050-b327b6f1})
#### サーバーとプロキシ

すべてのホストがZabbixサーバーと同じローカルネットワーク内にあり、スケーラビリティやパフォーマンスの問題がなければ、プロキシは必要ないかもしれません。
より大規模または複雑な環境では、Zabbixサーバーでホストを直接監視するだけでは不十分な場合があります。
プロキシを追加し、一部のホストをそのプロキシに割り当てることで、より均等な負荷分散が可能になります。

ベストプラクティスとして、以下の場合にZabbixプロキシを追加します:

1. ファイアウォールの背後で複数のメトリック収集方法を使用して複数のホストを監視している場合。
プロキシはホストからデータを収集し、それをZabbixサーバーに転送するため、複数のファイアウォールポートを開く必要がなくなります。

2. リモート拠点、支店、および/またはネットワークを監視している場合。
Zabbixサーバーとリモート拠点間のネットワークが中断された場合でも、リモート拠点に配備されたZabbixプロキシはデータ収集を継続し、ネットワーク接続が復旧した際に収集したデータをZabbixサーバーに送信します。

3. 大規模な導入を行っており、Zabbixサーバーの負荷を軽減し、パフォーマンスを向上させたい場合。
大規模な導入の定義は非常に幅広く、ホスト数だけでなく、1秒あたりに収集される値の数にも依存します。

[comment]: # ({/5b256050-b327b6f1})

[comment]: # ({cc708441-34997e28})
#### シークレットマクロ

[シークレット](/manual/config/macros/secret_macros)ユーザーマクロを、シークレットテキストまたはシークレットボールトマクロとして使用することができます。

シークレットボールトマクロを使用する場合、セキュリティを強化するために、ZabbixサーバーとZabbixプロキシがそれぞれ独立してマクロ値を取得するように[設定](/manual/web_interface/frontend_sections/administration/general#other)することを推奨します。デフォルトでは、シークレットマクロの値はZabbixサーバーによって取得され、Zabbixプロキシに伝播されます。

[comment]: # ({/cc708441-34997e28})