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

概要

Zabbix は、自動ネットワークディスカバリ機能を提供しており、これは効果的で非常に柔軟です。

ネットワークディスカバリを適切に設定すると、次のことが可能になります。

  • Zabbix の導入を迅速化
  • 管理の簡素化
  • 過度な管理作業を行うことなく、変化の激しい環境で Zabbix を利用

Zabbix のネットワークディスカバリは、次の情報に基づいています。

  • IP 範囲
  • 外部サービスの可用性(FTP、SSH、WEB、POP3、IMAP、TCP など)
  • Zabbix エージェント から受信した情報(サポートされるのは暗号化されていないモードのみ)
  • SNMP エージェント から受信した情報

次の機能は提供されません。

  • ネットワークトポロジーのディスカバリ

ネットワークディスカバリは、基本的にディスカバリとアクションの 2 つのフェーズで構成されます。

ディスカバリ

Zabbixは、ネットワークディスカバリルールで定義されたIP範囲を定期的にスキャンします。 チェックの頻度は、各ルールごとに個別に設定できます。

各ルールには、そのIP範囲に対して実行するサービスチェックのセットが定義されています。

ディスカバリルールはディスカバリマネージャーによって処理されます。 ディスカバリマネージャーは、各ルールごとにタスク(ネットワークチェック)のリストを持つジョブを作成します。 ネットワークチェックは、利用可能なディスカバリワーカーによって並列に実行されます (数は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範囲にまたがってディスカバリを実行できますが、すでに監視されているサブネットに割り当てられたプロキシを変更する場合は、重複を避けるために、ディスカバリされたホストと親プロキシグループのメンバーシップの両方に対して、プロキシの変更を一貫して適用する必要があるため、より複雑になります。

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

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