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

概要

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

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

  • Zabbixの導入を迅速化
  • 管理の簡素化
  • 過度な管理作業をせずに、急速に変化する環境でZabbixを利用

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

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

以下は提供しません。

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

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

ディスカバリ

Zabbixは、network discovery rulesで定義されたIP範囲を定期的にスキャンします。 チェックの頻度は、各ルールごとに個別に設定できます。

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

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

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

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

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

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

イベント サービスチェックの結果
Service Discovered サービスが「ダウン」から「アップ」になった場合、または初めて検出された場合。
Service Up サービスがすでに「アップ」である状態で、「アップ」と判定された場合。
Service Lost サービスが「アップ」から「ダウン」になった場合。
Service Down サービスがすでに「ダウン」である状態で、「ダウン」と判定された場合。
Host Discovered ホストのすべてのサービスが「ダウン」だった後に、少なくとも1つのサービスが「アップ」になった場合、または未登録のホストに属するサービスが検出された場合。
Host Up 少なくとも1つのサービスがすでに「アップ」である状態で、ホストの少なくとも1つのサービスが「アップ」になった場合。
Host Lost 少なくとも1つが「アップ」だった後に、ホストのすべてのサービスが「ダウン」になった場合。
Host Down ホストのすべてのサービスが、すでに「ダウン」である状態で「ダウン」になった場合。

アクション

ディスカバリーイベントは、以下のような関連するアクションの基礎となります。

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

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

ネットワークディスカバリーアクションはイベントベースであるため、検出されたホストがオンラインの場合もオフラインの場合もトリガーされます。 Add hostのようなアクションがService Lost/Service Downイベントでトリガーされるのを避けるために、アクション条件として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範囲に存在しなくなった場合、監視データ > ディスカバリから自動的に削除されます。 ホストは即座に削除されます。

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

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

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

プロキシ設定の変更

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

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

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

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