2 設定のベストプラクティス

概要

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

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

ホストとアイテム

ホストの定義

Zabbixのホストは、物理的なマシンやデバイスではなく、論理的なエンティティです。 監視のために、データベースや、たとえば仮想マシン用の個別のホストを作成できます。 または、一般的なホストJohn's laptopを作成し、そのホストの下のすべてのメトリクスを監視することができます。

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

1. 各ホストの個別のアイテム、トリガー、アラート通知を持っていることによる監視データの乱雑さを避けます。

2. ユーザーアクセスレベルを微調整します。 特定のホストのみを表示や設定するためのアクセスを許可のあるユーザーの役割を設定できます。 最小特権の原則を参照してください。

重複したアイテムを持つホスト

ネットワークスイッチ1とネットワークスイッチ2のように、類似したホストが複数ある場合、Zabbixではホストを素早く再作成する複数の方法を提供しています。 クローン ボタンを押すだけで、すべてのメトリックを含むホストのクローンを作成できますが、この場合、後でアイテムを更新するには、各ホストで手動で更新する必要があります。

ベストプラクティスは、必要なメトリックをすべて含むテンプレート（例：ネットワークスイッチテンプレート）を作成することです。 次に、類似したホストをホストグループにグループ化します。上記の例では、ネットワークスイッチが該当します。 これで、データ収集 -> ホストセクションで、すべてのホストをホストグループでフィルタリングし、一括更新ボタンを使用してテンプレートをすべてのネットワークスイッチにリンクできます。

依存アイテム

対象エンティティへのリクエスト数を最小限に抑えるため、Zabbix ではマスターアイテムと依存アイテムを作成できます。 この場合、マスターアイテムは単一のリクエストで大量の情報を収集します。 その後、依存アイテムは、前処理によってその収集から特定のデータ部分を抽出し、個別のメトリックとして保存するように設定できます。

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

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

サーバーとプロキシ

すべてのホストがZabbixサーバーと同じローカルネットワーク上にあり、スケーラビリティやパフォーマンスに問題がない場合は、プロキシは不要です。

大規模または複雑な環境では、Zabbixサーバーでホストを直接監視するだけでは不十分な場合があります。 プロキシを追加し、一部のホストをそのプロキシに割り当てることで、より均等な負荷分散が可能になります。

以下の場合は、Zabbixプロキシを追加することを推奨します。

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

2. リモート拠点、ブランチ、またはネットワークを監視している場合 Zabbixサーバーとリモート拠点間のネットワークが中断した場合、リモート拠点に配置されたZabbixプロキシはデータ収集を継続し、ネットワーク接続が回復するたびに収集したデータをZabbixサーバーに送信します。

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