Zabbixは、自動ネットワークディスカバリ機能を提供しており、効果的かつ非常に柔軟です。
ネットワークディスカバリを適切に設定することで、以下のことが可能になります。
Zabbixのネットワークディスカバリは、以下の情報に基づいています。
以下は提供しません。
ネットワークディスカバリは基本的に、ディスカバリとアクションの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ルックアップを上書きし、ホスト名にアイテム値を使用することも可能です。例えば:
ホスト名がアイテム値で設定されている場合、以降のディスカバリチェックでは更新されません。 アイテム値でホスト名を設定できない場合は、デフォルト値(DNS名)が使用されます。
ディスカバリされたIPアドレスで既にホストが存在し、ディスカバリ元(Zabbixサーバー、プロキシまたはプロキシグループ)が変更されていない場合、新しいホストは作成されません。 ディスカバリ元が異なる場合、ディスカバリされたエンティティは別物として扱われ、新しいホストが作成される場合があります。 ただし、ディスカバリアクションに操作(テンプレートのリンク、ホストグループへの追加など)が含まれている場合は、IPアドレス、インターフェイスタイプ、ディスカバリ元で一致する既存のホストに対して実行されます。
ネットワークディスカバリールールによって検出されたホストは、検出されたエンティティがルールのIP範囲に存在しなくなった場合、監視データ > ディスカバリから自動的に削除されます。 ホストは即座に削除されます。
ネットワークディスカバリの結果としてホストが追加される場合、以下のルールに従ってインターフェースが作成されます。
異なるプロキシによって検出されたホストは、常に異なるホストとして扱われるわけではありません。 ディスカバリと一意性のチェックは、プロキシグループの構造に依存します。プロキシがディスカバリルールを実行してホストを作成すると、そのホストはプロキシ自体ではなく、プロキシの親プロキシグループに追加されます。 Zabbixがディスカバリ中にIPの一意性を評価する際には、親プロキシグループによって監視されているホストをチェックします。 そのグループ内の個々のプロキシによって監視されているホスト(ディスカバリを実行したプロキシを含む)は、一意性チェックの対象外となるため、複数のプロキシが重複するサブネットを監視している場合、重複したホストが作成される可能性があります。
この動作により、異なるサブネットで使用される重複するIP範囲にまたがってディスカバリを実行できますが、すでに監視されているサブネットに割り当てられているプロキシを変更する場合は、重複を避けるために、ディスカバリされたホストと親プロキシグループのメンバーシップの両方に一貫してプロキシの変更を適用する必要があるため、より複雑になります。
たとえば、ディスカバリルールでプロキシを置き換える手順は次のとおりです。