1 ネットワークディスカバリ
概要
Zabbixは、自動ネットワークディスカバリ機能を提供しており、効果的かつ非常に柔軟です。
ネットワークディスカバリを適切に設定することで、以下のことが可能になります。
- Zabbixの導入を迅速化
- 管理の簡素化
- 過度な管理作業をせずに、急速に変化する環境でZabbixを利用
Zabbixのネットワークディスカバリは、以下の情報に基づいています。
- IPレンジ
- 外部サービスの可用性(FTP、SSH、WEB、POP3、IMAP、TCPなど)
- Zabbixエージェントから受信した情報(暗号化されていないモードのみサポート)
- SNMPエージェントから受信した情報
以下は提供しません。
- ネットワークトポロジーのディスカバリ
ネットワークディスカバリは基本的に、ディスカバリとアクションの2つのフェーズで構成されます。
ディスカバリ
Zabbixは、ネットワークディスカバリルールで定義されたIPレンジを定期的にスキャンします。 チェックの頻度は、各ルールごとに個別に設定できます。
各ルールには、IPレンジに対して実行するサービスチェックのセットが定義されています。
ディスカバリルールはディスカバリマネージャによって処理されます。 ディスカバリマネージャは、各ルールごとにタスク（ネットワークチェック）のリストを持つジョブを作成します。 ネットワークチェックは、利用可能なディスカバリワーカー（数はフロントエンドで各ルールごとに設定可能）によって並列に実行されます。 同じIPとポートのチェックのみが順次スケジューリングされます。なぜなら、一部のデバイスは同じポートへの並列接続を受け付けないためです。
ネットワークチェックのキューサイズは、約2000000または4GBのメモリに制限されています。
キューがいっぱいになると、そのディスカバリルールはスキップされ、警告メッセージがログに出力されます。
キュー内のディスカバリチェック数を監視するには、zabbix[discovery_queue]内部アイテムを使用できます。
ディスカバリチェックは他のチェックとは独立して処理されます。 いずれかのチェックでサービスが見つからない（または失敗する）場合でも、他のチェックは引き続き処理されます。
ディスカバリルールが実行中に変更された場合、現在のディスカバリ実行は中止されます。
ネットワークディスカバリモジュールによって実行されるサービスおよびホスト（IP）の各チェックは、ディスカバリエベントを生成します。
| イベント | サービスチェックの結果 |
|---|---|
| サービス検出 | サービスが「ダウン」から「アップ」になった場合、または初めて検出された場合。 |
| サービスアップ | サービスがすでに「アップ」だった後に「アップ」である場合。 |
| サービスロスト | サービスが「アップ」から「ダウン」になった場合。 |
| サービスダウン | サービスがすでに「ダウン」だった後に「ダウン」である場合。 |
| ホスト検出 | ホストのすべてのサービスが「ダウン」だった後に少なくとも1つのサービスが「アップ」になった場合、または未登録ホストに属するサービスが検出された場合。 |
| ホストアップ | ホストの少なくとも1つのサービスがすでに「アップ」だった後に少なくとも1つのサービスが「アップ」である場合。 |
| ホストロスト | ホストのすべてのサービスが少なくとも1つが「アップ」だった後に「ダウン」になった場合。 |
| ホストダウン | ホストのすべてのサービスがすでに「ダウン」だった後に「ダウン」である場合。 |
アクション
ディスカバリーイベントは、以下のような関連するアクションの基礎となります。
- 通知の送信
- ホストの追加/削除
- ホストの有効化/無効化
- ホストをグループに追加
- ホストをグループから削除
- ホストにタグを追加
- ホストからタグを削除
- テンプレートをホストにリンク/テンプレートをホストからリンク解除
- リモートスクリプトの実行
これらのアクションは、デバイスタイプ、IP、ステータス、稼働/停止時間などに応じて設定できます。 ネットワークディスカバリーベースのイベントに対するアクションの設定の詳細については、アクションのオペレーションおよび条件のページを参照してください。
ネットワークディスカバリーアクションはイベントベースであるため、検出されたホストがオンラインの場合もオフラインの場合もトリガーされます。 Add hostのようなアクションがService Lost/Service Downイベントでトリガーされるのを避けるために、アクション条件としてDiscovery status: upを追加することを強く推奨します。 そうしないと、検出されたホストが手動で削除された場合でもService Lost/Service Downイベントが生成され、次のディスカバリーサイクルで再作成されてしまいます。
検出されたホストにテンプレートをリンクする場合、リンク可能なテンプレートのいずれかに、ホストまたは他のリンク可能なテンプレートに既に存在する一意のエンティティ（例：アイテムキー）と同じ一意のエンティティ（例：アイテムキー）がある場合、テンプレートのリンクはまとめて失敗します。
ホストの作成
ホストの追加操作が選択されている場合、ホストが追加されます。 ホストの追加操作がなくても、ホストに対するアクションを伴う操作を選択した場合もホストが追加されます。 そのような操作は以下の通りです:
- ホストの有効化
- ホストの無効化
- ホストをホストグループに追加
- テンプレートをホストにリンク
作成されたホストは、検出されたホストグループに追加されます（デフォルトでは管理 > 一般 > その他で設定可能）。 ホストを別のグループに追加したい場合は、ホストグループから削除操作（"検出されたホスト"を指定）とホストグループに追加操作（別のホストグループを指定）を追加してください。ホストは必ずホストグループに所属する必要があるためです。
検出されたデバイスのIPアドレスは、検出元（Zabbixサーバー、Zabbixプロキシ、またはプロキシグループ）およびインターフェイスタイプとともに、システム内でホストを検索する基準として使用されます。 同じIPアドレス、インターフェイスタイプ、検出元を持つホストがすでに存在する場合、そのホストが操作の対象となります。 検出元が異なる場合、検出されたエンティティは別のホストとして扱われ、新しいホストが作成される場合があります。
検出されたホストのIPアドレスが変更されたり、インターフェイスが削除された場合、次回の検出時に新しいホストが作成されます。
ホスト名の付け方
ホストを追加する際、ホスト名はリバースDNSルックアップの結果、またはリバースルックアップが失敗した場合はIPアドレスとなります。 ルックアップは、ディスカバリを実行しているZabbixサーバーまたはZabbixプロキシから実行されます。 プロキシでルックアップに失敗した場合、サーバーで再試行されることはありません。 そのような名前のホストがすでに存在する場合、次のホストには名前の末尾に_2が付加され、さらに_3と続きます。
DNS/IPルックアップを上書きし、ホスト名にアイテム値を使用することも可能です。例えば:
- ディスカバリ用のZabbixエージェントアイテムを使用して、Zabbixエージェントが稼働している複数のサーバーをディスカバリし、このアイテムが返す文字列値に基づいて自動的に適切な名前を割り当てることができます
- ディスカバリ用のSNMPエージェントアイテムを使用して、複数のSNMPネットワークデバイスをディスカバリし、このアイテムが返す文字列値に基づいて自動的に適切な名前を割り当てることができます
ホスト名がアイテム値で設定されている場合、以降のディスカバリチェックでは更新されません。 アイテム値でホスト名を設定できない場合は、デフォルト値(DNS名)が使用されます。
ディスカバリされたIPアドレスで既にホストが存在し、ディスカバリ元(Zabbixサーバー、プロキシまたはプロキシグループ)が変更されていない場合、新しいホストは作成されません。 ディスカバリ元が異なる場合、ディスカバリされたエンティティは別物として扱われ、新しいホストが作成される場合があります。 ただし、ディスカバリアクションに操作(テンプレートのリンク、ホストグループへの追加など)が含まれている場合は、IPアドレス、インターフェイスタイプ、ディスカバリ元で一致する既存のホストに対して実行されます。
ホストの削除
ネットワークディスカバリールールによって検出されたホストは、検出されたエンティティがルールのIP範囲に存在しなくなった場合、監視データ > ディスカバリから自動的に削除されます。 ホストは即座に削除されます。
ホスト追加時のインターフェース作成
ネットワークディスカバリの結果としてホストが追加される場合、以下のルールに従ってインターフェースが作成されます。
- 検出されたサービス - 例えば、SNMPチェックが成功した場合、SNMPインターフェースが作成されます。
- ホストがZabbixエージェントとSNMPの両方のリクエストに応答した場合、両方のタイプのインターフェースが作成されます。
- 一意性の基準がZabbixエージェントまたはSNMPから返されたデータである場合、ホストに対して最初に見つかったインターフェースがデフォルトのものとして作成されます。 他のIPアドレスは追加のインターフェースとして追加されます。 アクションの条件（ホストIPなど）は、インターフェースの追加には影響しません。 注 これは、すべてのインターフェースが同じディスカバリルールによって検出された場合に機能します。 異なるディスカバリルールが同じホストの異なるインターフェースを検出した場合、追加のホストが追加されます。
- ホストがエージェントチェックのみに応答した場合、エージェントインターフェースのみで作成されます。 後でSNMPに応答し始めた場合は、追加のSNMPインターフェースが追加されます。
- 最初に「IP」一意性基準で検出された3つの個別のホストが作成され、その後ディスカバリルールが変更されてホストA、B、Cが同一の一意性基準の結果を持つようになった場合、BとCはA（最初のホスト）の追加インターフェースとして作成されます。 個別のホストBとCは残ります。 監視 > ディスカバリ では、追加されたインターフェースは「検出されたデバイス」列に黒字でインデントされて表示されますが、「監視対象ホスト」列には最初に作成されたホストAのみが表示されます。 「稼働/停止時間」は、追加のインターフェースと見なされるIPには測定されません。
プロキシ設定の変更
異なるプロキシによって検出されたホストは、常に異なるホストとして扱われるわけではありません。 ディスカバリと一意性のチェックは、プロキシグループの構造に依存します。プロキシがディスカバリルールを実行してホストを作成すると、そのホストはプロキシ自体ではなく、プロキシの親プロキシグループに追加されます。 Zabbixがディスカバリ中にIPの一意性を評価する際には、親プロキシグループによって監視されているホストをチェックします。 そのグループ内の個々のプロキシによって監視されているホスト（ディスカバリを実行したプロキシを含む）は、一意性チェックの対象外となるため、複数のプロキシが重複するサブネットを監視している場合、重複したホストが作成される可能性があります。
この動作により、異なるサブネットで使用される重複するIP範囲にまたがってディスカバリを実行できますが、すでに監視されているサブネットに割り当てられているプロキシを変更する場合は、重複を避けるために、ディスカバリされたホストと親プロキシグループのメンバーシップの両方に一貫してプロキシの変更を適用する必要があるため、より複雑になります。
たとえば、ディスカバリルールでプロキシを置き換える手順は次のとおりです。
- ディスカバリルールを無効にする
- プロキシの設定を同期する
- ディスカバリルールのプロキシを置き換える
- このルールで検出されたすべてのホストのプロキシを置き換える（親プロキシグループ内のホストと、そのグループ内の個々のプロキシによって監視されているホストが重複しないように更新されていることを確認する）
- ディスカバリルールを有効にする