ディスカバリルールは、ディスカバリマネージャーによって処理されます。ディスカバリマネージャーは、各ルールごとにタスク（ネットワークチェック）のリストを含むジョブを作成します。ネットワークチェックは、利用可能なディスカバリワーカーによって並列に実行されます（数はWebインターフェースで各ルールごとに設定可能です）。同じIPとポートに対するチェックのみが順次スケジュールされます。これは、一部のデバイスが同じポートへの並列接続を受け付けないためです。

ネットワークチェックのキューサイズは、約2000000件または約4 GBのメモリに制限されています。キューがいっぱいになると、ディスカバリルールはスキップされ、警告メッセージがログに出力されます。キュー内のディスカバリチェック数の監視には、内部アイテム zabbix[discovery_queue] を使用できます。

ディスカバリチェックは、他のチェックとは独立して処理されます。いずれかのチェックでサービスが見つからない場合（または失敗した場合）でも、他のチェックは引き続き処理されます。

ディスカバリルールが実行中に変更された場合、現在のディスカバリ実行は中止されます。

ネットワークディスカバリモジュールによって実行される、サービスおよびホスト（IP）の各チェックは、ディスカバリイベントを生成します。

イベント	サービスチェック結果
サービス検出	サービスが「down」だった後に「up」になった場合、または初めて検出された場合。
サービス稼働	サービスがすでに「up」だった後も「up」である場合。
サービス消失	サービスが「up」だった後に「down」になった場合。
サービス停止	サービスがすでに「down」だった後も「down」である場合。
ホスト検出	ホストのすべてのサービスが「down」だった後に、そのホストの少なくとも1つのサービスが「up」になった場合、または未登録のホストに属するサービスが検出された場合。
ホスト稼働	ホストの少なくとも1つのサービスが、少なくとも1つのサービスがすでに「up」だった後も「up」である場合。
ホスト消失	ホストの少なくとも1つのサービスが「up」だった後に、そのホストのすべてのサービスが「down」になった場合。
ホスト停止	ホストのすべてのサービスが、すでに「down」だった後も「down」である場合。

アクション

ディスカバリイベントは、次のような関連するactionの基礎となります。

通知の送信
ホストの追加/削除
ホストの有効化/無効化
ホストをグループに追加
ホストをグループから削除
ホストにタグを追加
ホストからタグを削除
ホストへのテンプレートのリンク/ホストからのテンプレートのリンク解除
リモートスクリプトの実行

これらのアクションは、デバイスタイプ、IP、ステータス、稼働時間/停止時間などに応じて設定できます。ネットワークディスカバリベースのイベントに対するアクション設定の詳細については、actionのoperationおよびconditionsのページを参照してください。

ネットワークディスカバリアクションはイベントベースであるため、検出されたホストがオンラインの場合とオフラインの場合の両方でトリガーされます。 Service Lost/Service DownイベントでAdd hostのようなアクションがトリガーされるのを避けるため、アクションcondition Discovery status: up を追加することを強く推奨します。そうしないと、検出されたホストを手動で削除しても、引き続きService Lost/Service Downイベントが生成され、次回のディスカバリサイクル中に再作成されます。

検出されたホストへのテンプレートのリンクは、リンク可能なテンプレートのいずれかにある一意のエンティティ（例：アイテムキー）が、ホスト上または他のリンク可能なテンプレート上にすでに存在する一意のエンティティ（例：アイテムキー）と同一である場合、まとめて失敗します。

ホストの作成

ホストを追加 操作が選択されている場合、ホストが追加されます。また、ホストを追加 操作がなくても、ホストに対するアクションとなる操作を選択すると、ホストが追加されます。そのような操作は次のとおりです。

ホストを有効化
ホストを無効化
ホストをホストグループに追加
テンプレートをホストにリンク

作成されたホストは Discovered hosts グループに追加されます（デフォルト。Administration > General > Other で設定可能）。ホストを別のグループに追加したい場合は、ホストは必ずホストグループに属している必要があるため、ホストグループから削除 操作（"Discovered hosts" を指定）を追加し、さらに ホストグループに追加 操作（別のホストグループを指定）も追加してください。

検出されたデバイスのIPアドレスに加え、ディスカバリ元（Zabbixサーバー、Zabbixプロキシ、またはプロキシグループ）およびインターフェースタイプが、システム内でホストを特定するための基準として使用されます。同じIPアドレス、インターフェースタイプ、およびディスカバリ元を持つホストがすでに存在する場合、そのホストが操作実行の対象になります。ディスカバリ元が異なる場合、検出されたエンティティは別のホストとして扱われ、新しいホストが作成されることがあります。

検出されたホストのIPアドレスが変更された場合、またはインターフェースが削除された場合、次回のディスカバリ時に新しいホストが作成されます。

ホスト名の付け方

ホストを追加する際、ホスト名は逆引きDNSルックアップの結果、または逆引きに失敗した場合はIPアドレスになります。ルックアップは、ディスカバリを実行している側に応じて、ZabbixサーバーまたはZabbixプロキシから実行されます。プロキシでルックアップに失敗した場合、サーバーで再試行は行われません。その名前のホストがすでに存在する場合、次のホスト名には _2 が追加され、その次は _3 というように続きます。

また、DNS/IPルックアップを上書きし、代わりにホスト名としてアイテムの値を使用することも可能です。例えば、次のようなケースです。

Zabbixエージェントが稼働している複数のサーバーを、ディスカバリ用のZabbixエージェントアイテムを使用して検出し、このアイテムが返す文字列値に基づいて適切な名前を自動的に割り当てることができます
複数のSNMPネットワークデバイスを、ディスカバリ用のSNMPエージェントアイテムを使用して検出し、このアイテムが返す文字列値に基づいて適切な名前を自動的に割り当てることができます

ホスト名がアイテムの値を使用して設定されている場合、その後のディスカバリチェックでは更新されません。アイテムの値を使用してホスト名を設定できない場合は、デフォルト値（DNS名）が使用されます。

検出されたIPアドレスを持つホストがすでに存在し、かつディスカバリ元（Zabbixサーバー、プロキシ、またはプロキシグループ）が変更されていない場合、新しいホストは作成されません。ディスカバリ元が異なる場合、検出された対象は別個のものとして扱われ、新しいホストが作成されることがあります。ただし、ディスカバリアクションに操作（テンプレートのリンク、ホストグループへの追加など）が含まれている場合、それらはIPアドレス、インターフェースタイプ、およびディスカバリ元が一致する既存のホストに対して実行されます。

ホストの削除

ネットワークディスカバリルールによって検出されたホストは、検出されたエンティティがそのルールのIP範囲内になくなった場合、Monitoring > Discovery から自動的に削除されます。
ホストは即座に削除されます。

ホスト追加時のインターフェース作成

ネットワークディスカバリの結果としてホストが追加される場合、インターフェースは次のルールに従って作成されます。

検出されたサービスに応じて作成されます。例えば、SNMPチェックが成功した場合は、SNMPインターフェースが作成されます。
ホストがZabbixエージェントとSNMPリクエストの両方に応答した場合は、両方の種類のインターフェースが作成されます。
一意性の条件がZabbixエージェントまたはSNMPから返されたデータである場合、ホストに対して最初に見つかったインターフェースがデフォルトのインターフェースとして作成されます。
その他のIPアドレスは追加インターフェースとして追加されます。アクションの条件（ホストIPなど）は、インターフェースの追加には影響しません。この動作は、すべてのインターフェースが同じディスカバリルールによって検出される場合に機能することに注意してください。同じホストの別のインターフェースが別のディスカバリルールによって検出された場合は、追加のホストが作成されます。
ホストがエージェントチェックのみに応答した場合は、エージェントインターフェースのみを持つホストとして作成されます。
その後SNMPにも応答し始めた場合は、追加のSNMPインターフェースが追加されます。
最初に3つの別個のホストが "IP" の一意性条件によって作成され、その後ディスカバリルールが変更されてホストA、B、Cが同一の一意性条件の結果を持つようになった場合、BとCは最初のホストであるAの追加インターフェースとして作成されます。
個別のホストBとCはそのまま残ります。
Monitoring > Discovery では、追加されたインターフェースは "Discovered device" 列に黒いフォントでインデントされて表示されますが、"Monitored host" 列には最初に作成されたホストであるAのみが表示されます。追加インターフェースと見なされるIPについては、"Uptime/Downtime" は測定されません。

プロキシ設定の変更

異なるプロキシによってディスカバリされたホストは、常に別々のホストとして扱われるわけではありません。
ディスカバリと一意性チェックはプロキシグループの構造に依存します。プロキシがディスカバリルールを実行してホストを作成すると、そのホストはプロキシ自体に割り当てられるのではなく、そのプロキシの親プロキシグループに追加されます。
Zabbixがディスカバリ中にIPの一意性を評価する際は、親プロキシグループによって監視されているホストを確認します。
そのグループ内の個々のプロキシによって監視されているホスト（ディスカバリを実行したプロキシ自身を含む）は、一意性チェックでは無視されます。そのため、複数のプロキシが重複するサブネットを監視している場合、重複したホストが作成される可能性があります。

この動作により、異なるサブネットで使用される重複したIP範囲にまたがってディスカバリを実行できますが、すでに監視されているサブネットに割り当てられたプロキシを変更する場合は、重複を避けるために、ディスカバリされたホストと親プロキシグループのメンバーシップの両方に対して、プロキシの変更を一貫して適用する必要があるため、より複雑になります。

たとえば、ディスカバリルール内のプロキシを置き換える手順は次のとおりです。

ディスカバリルールを無効にする
プロキシ設定を同期する
ディスカバリルール内のプロキシを置き換える
このルールによってディスカバリされたすべてのホストのプロキシを置き換える（重複を避けるため、親プロキシグループ内のホストと、そのグループ内の個々のプロキシによって監視されているすべてのホストが更新されるようにしてください）
ディスカバリルールを有効にする

What’s next?

1 ネットワークディスカバリルールの設定

Docs

1 ネットワークディスカバリ

概要

ディスカバリ