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

概要

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

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

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

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

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

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

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

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

ディスカバリ

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

各ルールには、IP 範囲に対して実行するよう定義された一連のサービスチェックがあります。

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

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

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

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

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

Event Check of service result
Service Discovered サービスが 'down' の後に 'up' になった場合、または初めて検出された場合。
Service Up サービスがすでに 'up' の状態で、'up' のままである場合。
Service Lost サービスが 'up' の後に 'down' になった場合。
Service Down サービスがすでに 'down' の状態で、'down' のままである場合。
Host Discovered ホストのすべてのサービスが 'down' だった後に、そのホストの少なくとも 1 つのサービスが 'up' になった場合、または未登録のホストに属するサービスが検出された場合。
Host Up 少なくとも 1 つのサービスがすでに 'up' である状態で、ホストの少なくとも 1 つのサービスが 'up' になった場合。
Host Lost 少なくとも 1 つが 'up' だった後に、ホストのすべてのサービスが 'down' になった場合。
Host 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. ディスカバリルールを有効にする