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

概要

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

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

ホストとアイテム

ホストの定義

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

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

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

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

Hosts with duplicated items

If you have several similar hosts, such as Network switch 1 and Network switch 2, Zabbix provides multiple ways to quickly recreate the host. You can simply clone a host with all of its metrics by pressing the Clone button, but in this case, to update an item later, you will need to do it manually on each host.

The best practice is to create a template with all of the required metrics, for example, Network switch template. Then group the similar hosts into a host group, for the example above it could be Network switches. Now, in the Data Collection -> Hosts section you can filter all hosts by host group and use the Mass update button to link the template to all of your network switches.

Dependent items

To minimize the number of requests to the target entity, Zabbix allows the creation of master and dependent items. In this case, the master item collects a large set of information in a single request. Then dependent items can be configured to extract specific pieces of data from that collection via preprocessing and store them as individual metrics.

For example, the master item might collect a JSON or XML response containing multiple metrics or execute a database query that returns multiple columns of data (e.g., number of open connections, aborted connections, maximum allowed simultaneous connections, and total cumulative connections since startup), and dependent items will parse and store each required value separately.

The best practice for this configuration is to discard master item's history right after collection and only keep the dependent items data.

Servers and proxies

If all hosts are in the same local network as the Zabbix server and there are no scalability or performance concerns, you may not need a proxy. In larger or more complex environments, directly monitoring hosts with the Zabbix server may not be sufficient. Adding a proxy and assigning part of the hosts to that proxy allows for a more even load distribution.

The best practice is to add a Zabbix proxy when:

1. You are monitoring multiple hosts using various metric collection methods behind a firewall. The proxy will gather data from the hosts and forward it to the Zabbix server, reducing the need for opening multiple firewall ports.

2. You are monitoring remote locations, branches, and/or networks. In case of a network interruption between the Zabbix server and your remote locations, the Zabbix proxies deployed in the remote locations will continue data collection and send the collected data back to the Zabbix server whenever the network connection is restored.

3. You have a large-scale deployment and want to reduce the load on Zabbix server and improve performance. The definition of a large-scale deployment is very broad and depends not only on the number of hosts, but also on the number of values collected per second.