Zabbix Documentation 2.0

2.23.04.04.2 (current)In development:4.4 (devel)Unsupported:1.82.02.43.23.4

User Tools

Site Tools

This translation is older than the original page and might be outdated. See what has changed.

Sidebar

jp:manual:discovery:low_level_discovery

3 ローレベルディスカバリ

概要

ローレベルディスカバリは、コンピュータ上に存在する異なるものの、アイテムやトリガー、グラフを自動的に作成する方法を提供します。例えば、Zabbix は、ファイルシステムやネットワークインターフェースのそれぞれにアイテムを手動で作成しなくても、自動的に使用するマシンのファイルシステムやネットワークインターフェースの監視を開始します。加えて、定期的に実行されるディスカバリの実際の結果に基づいて、Zabbix が不要なものを自動的に削除するように設定することも可能です。

Zabbix 2.0では、すぐに使える3タイプのディスカバリがサポートされています:

  • システムのディスカバリ
  • ネットワークインターフェースのディスカバリ
  • SNMP OIDのディスカバリ

ユーザーは、特定の JSON プロトコルに従うことによって提供される、独自のディスカバリのタイプを定義できます。

ディスカバリのプロセスの一般的なアーキテクチャは以下のとおりです:

最初に、ユーザーは[設定]→[テンプレート]の[ディスカバリ]列でディスカバリルールを作成します。1つのディスカバリルールは、(1)必要なエンティティ(例えば、ファイルシステムまたはネットワークインターフェース)を検出するアイテムと、(2)そのアイテムの値に基づいて作成されるアイテム、トリガー、グラフのプロトタイプから構成されます。

必要なエンティティを検出するアイテムは、ほかの場所で見られるレギュラーアイテムのようにみえます:サーバは、Zabbix エージェント(または設定されている他のアイテムタイプ)にそのアイテムの値を問合せ、エージェントはテキストの値で応答します。違いは、エージェントが応答する値には、特定のJSON形式で検出されたエンティティのリストを含まれるという点です。この形式の詳細はカスタムのディスカバリチェックの実装者にとって重要なだけですが、戻り値にはマクロ→値のペアのリストが含まれているということは知っておく必要があります。例えば、アイテム「net.if.discovery」は2つのペア」:{#IFNAME} → 「lo」と {#IFNAME} → 「eth0」を返す可能性があります。

ローレベルディスカバリのアイテム vfs.fs.discovery と net.if.discovery は、Zabbxi エージェントのバージョン2.0からサポートされています。
Zabbix プロキシでは、ローレベルディスカバリのルールの戻り値は、Oracle DBでは4000文字、IBM DB2では2048文字までに制限されています。

これらのマクロは、各検出されたエンティティの実際のアイテム、トリガー、グラフの作成の基盤となる名前、キー、その他のプロトタイプフィールドに使用されます。これらのマクロは以下の場所で使用可能です:

  • 以下の場所のアイテムのプロトタイプ
    • 名前
    • キー
    • SNMP OID
    • 計算アイテム の式
    • SSH と Telnet のスクリプト
    • データベース監視アイテムのパラメータ
  • 以下の場所のトリガーのプロトタイプ
    • 名前
    • 条件式(アイテムキーのプロトタイプを参照するときに)
  • 以下の場所のグラフのプロトタイプ
    • 名前

サーバがディスカバリアイテムのために値を受信するとき、マクロ→値のペアを見て、それぞれのペアがプロトタイプに基づいて実際のアイテム、トリガー、グラフを生成します。上記の「net.if.discovery」を使用する例では、サーバは、ループバックインターフェース「lo」のアイテムとトリガーとグラフのセットを1つ生成し、インターフェース「eth0」に別の1セットを生成します。

次のセクションでは、上記で説明された処理を詳細に描き、ファイルシステム、ネットワークインターフェース、SNMP OIDのディスカバリを実行する方法を示します。最後のセクションで、ディスカバリアイテム用のJSON 形式について説明し、Perl スクリプトで独自のファイルシステムのディスカバリをどのように実装するかの例を示します。

3.1 ファイルシステムのディスカバリ

ファイルシステムのディスカバリを設定するには、次のことをおこないます:

  • [設定]→[テンプレート]を選択
  • 適切なテンプレートの行内の[ディスカバリ]をクリック

  • 画面右上の角の[ディスカバリを作成]をクリック
  • 次の詳細をフォームに記入

パラメータ 説明
名前 ディスカバリルールの名前
タイプ ディスカバリを実行するチェックのタイプ;ファイルシステムのディスカバリ用のZabbix エージェントとします。
キー 「vfs.fs.discovery」キーをもつアイテムが、多くのプラットフォームのZabbix エージェント内に構築され(詳細はサポートされているアイテムキーのリストを参照)、コンピュータ上に存在するファイルシステムのリストとそのタイプを含むJSONを返します。
更新間隔(秒) このフィールドでディスカバリの実行頻度を指定します。最初の、ファイルシステムのディスカバリを設定するだけのときは、短い間隔で設定したいと思うでしょうが、ファイルシステムは通常はそう頻繁に変わらないので、うまく動くことを確認したら30分以上で設定します。
注意:「0」に設定した場合、アイテムはポーリングされません。しかし、0でない値をもつ「例外の更新間隔」が存在する場合は、例外の更新間隔でそのアイテムがポーリングされます。
例外の更新間隔 更新間隔に例外をつくることができます。例えば:
更新間隔: 0, 期間: 6-7,00:00-24:00 と設定すると、ウィークエンドはポーリングを無効にします。例外の更新間隔を設定しない場合は、デフォルトの更新間隔が使用されます。
例外の更新間隔が複数オーバーラップした場合は、オーバーラップしている期間は最も短い間隔の値が使用されます。
期間の形式の説明は、 期間の指定のページを参照してください。
注意:「0」に設定すると、例外の更新期間中はアイテムはポーリングされず、例外の更新期間が終了後、更新間隔に従ってポーリングが再開されます。
存在しなくなったリソースの保持期間(日) このフィールドで、ディスカバリのステータスが「もう検出されません」となってから、検出されたエンティティを何日間削除しないで保持するかを指定することができます。(最大3650日)
注意:「0」に設定した場合、エンティティはすぐに削除されます。単なるフィルターの設定間違いで、すべてのヒストリデータでエンティティが削除される結果となる場合があるので、「0」を使用することはお奨めしません。
フィルター
フィルターは、特定のファイルシステムの、実際のアイテム、トリガー、グラフの生成だけに使用可能です。POSIX正規表現で記述します。例えば、ファイルシステムのC、D、Eドライブだけを対象としたい場合は、[マクロ]に{#FSNAME}、[正規表現]のテキストフィールドに「^C|^D|^E」と入れます。{#FSTYPE} マクロを使用することによって、ファイルシステムのタイプでもフィルタリングが可能です。(例:^ext|^reiserfs)
[正規表現]フィールドでは、正規表現の入力、またはグローバル正規表現の参照が可能です。
正規表現をテストするために、「grep -E」を使用することができます。例えば:
for f in ext2 nfs reiserfs smbfs; do echo $f | grep -E '^ext|^reiserfs' || echo "SKIP: $f"; done
説明 説明を入力します。
ステータス 有効 - そのルールが実行されます。
無効 - そのルールは実行されません。
取得不可 - アイテムが取得不可です。このアイテムは実行されませんが、Zabbix は、取得不可なアイテムの更新間隔の設定に従って、定期的にそのアイテムのステータスを「有効」に設定しようと試みます。
大文字・小文字だけが異なるファイルシステム名が正しく検出されるように、MySQLのZabbix データベースは、大文字・小文字を区別するように作成する必要があります。
ディスカバリルールのヒストリは保存されません。

ルールが作成されたら、アイテムのプロトタイプを作成するために、そのルールの対象となるアイテムで[プロトタイプを作成]をクリックします。ファイルシステム名が必要な場所で、マクロ{#FSNAME}がどのように使用されているかを憶えておいてください。ディスカバリルールが実行されるとき、検出されたファイルシステムとこのマクロが置き換えられます。

アイテムのプロトタイプが「無効」のステータスで作成される場合、検出されたエンティティに追加されますが、無効のステータスで追加されます。

次のように、対象とする各ファイルシステムの基準に対して複数のアイテムのプロパティを作成できます:

それから、同様の方法でトリガーのプロトタイプを作成します:

また、グラフのプロトタイプも同様に作成します:

ついに、以下に表示されるようなディスカバリルールが作成できました。この例では、5つのアイテムプロトタイプと2つのトリガーのプロトタイプ、1つのグラフのプロトタイプがあります。

以下のスクリーンショットでは、検出されたアイテム、トリガー、グラフが、ホストの設定でどのように見えるかを示しています。検出されたエンティティは、先頭にそれを検出したディスカバリルールにリンクしている金色の文字がついています。

ローレベルディスカバリで作成されたアイテム(トリガーやグラフも同様)は、手動では削除できません。しかし、検出されたエンティティ(ファイルシステム、インターフェースなど)が検出されなくなると(あるいはフィルターを通らなくなると)、自動的に削除されます。この例の場合、[存在しなくなったリソースの保持期間(日)]で定義された日数が経過すると、それらのエンティティは削除されます。

検出されたエンティティが「もう検出されません」となったとき、オレンジ色のライフタイムインジケータがアイテムのリストの中に表示されます。マウスポインタをそのインジケータの上に移動すると、そのアイテムが削除されるまでに何日間あるかを示すメッセージが表示されます。

3.2 ネットワークインターフェースのディスカバリ

ネットワークインターフェースのディスカバリは、ディスカバリルールのキーを「vfs.fs.discovery」ではなく「net.if.discovery」、フィルターやアイテム/トリガー/グラフのプロトタイプでのマクロを {#FSNAME}ではなく{#IFNAME}にすること以外は 、ファイルシステムのディスカバリと全く同じ方法でおこなわれます。

「net.if.discovery」に基づいて作成できるアイテムのプロトタイプの例はつぎのようなものです: “net.if.in[{#IFNAME},bytes]”, “net.if.out[{#IFNAME},bytes]”.

フィルターについての詳細な情報は、上記のファイルシステムのディスカバリを参照してください。

3.3 SNMP OIDのディスカバリ

この例では、スイッチ上でSNMPディスカバリを実行します。最初に[設定]→[テンプレート]を選択します。

テンプレートのディスカバリルールを編集するには、[ディスカバリ]列のリンクをクリックします。

それから、[ルールの作成]をクリックし、 以下のスクリーンショットのようにフォームに詳細を記入します。

ファイルシステムやネットワークインターフェースのディスカバリと違って、アイテムは「snmp.discovery」キーを持つ必要はありません。SNMP エージェントのアイテムタイプがあれば十分です。

また、上記の例と違って、ディスカバリのアイテムは、検出したエンティティそれぞれに対して2つのマクロ、{#SNMPINDEX} と {#SNMPVALUE}を生成します。戻り値からループバックインターフェースを抽出したい場合は、{#SNMPVALUE}をフィルターの「マクロ」の中に入力し、「^([^l]|l$)[^o]?」正規表現を[正規表現]のテキストフィールドに入力します。フィルターについての詳細な情報は、上記のファイルシステムのディスカバリを参照してください。

[SNMP OID]フィールドでは、これらのマクロに対して意味のある値を生成することができるOIDを入力する必要がああります。 この例で示そうとしていることを理解するために、スイッチ上でsnmpwalkを実行してみましょう。

$ snmpwalk -v 2c -c public 192.168.1.1 IF-MIB::ifDescr
IF-MIB::ifDescr.1 = STRING: WAN
IF-MIB::ifDescr.2 = STRING: LAN1
IF-MIB::ifDescr.3 = STRING: LAN2

マクロ {#SNMPINDEX} は、ifDescrの後にくるOIDの部分から値(この例では:1,2,3)を取得します。マクロ {#SNMPVALUE} は、OIDに一致する値(この例では:WAN, LAN1, LAN2)から来ます。 このようにして、「snmp.discovery」アイテムは、マクロ→値のペアを3セット返します。

{#SNMPINDEX} -> 1   {#SNMPVALUE} -> WAN
{#SNMPINDEX} -> 2   {#SNMPVALUE} -> LAN1
{#SNMPINDEX} -> 3   {#SNMPVALUE} -> LAN2

次のスクリーンショットでは、これらのマクロをアイテムのプロトタイプで使用する方法を示します。

再び、必要な数のアイテムのプロトタイプを作成します。

同様にトリガーのプロトタイプも作成します。

そしてグラフのプロトタイプも作成します。

この例でのディスカバリルールの概要は、以下の通りです:

サーバが動作したとき、「snmp.discovery」が返す値に基づいて実際のアイテム、トリガー、グラフが作成されます。ホストの設定では、それらは先頭にそれを検出したディスカバリルールにリンクしている金色の文字がついています。

3.4 カスタムLLDルールの作成

また、例えばデータベースサーバ上のデータベースなど、あらゆるタイプのエンティティを検出する完全にカスタムのLLDルールを作成することも可能です。

それをおこなうには、検出したオブジェクトを特定して、オプションとしてそれらのプロパティを、JSONで返すカスタムのアイテムを作成します。エンティティごとのマクロ数に制限はありません - その組み込みのディスカバリルールが1つまたは2つのマクロ(例えば、ファイルシステムのディスカバリに対して2つ)のどちらかを返している間は、もっと多くを返すこともできます。

返される JSON 形式は、以下の例でよくわかります。いまわたし達は「vfs.fs.discovery」をサポートしていない古い Zabbix 1.8 エージェントを作動させているけれども、ファイルシステムを検出する必要があると想定してみてください。以下に、監視対象のファイルシステムを検出し、ファイルシステム名とタイプを含むJSONを出力する、Linux用のシンプルな Perl のスクリプトを示します。これを使用する1つの方法は、「vfs.fs.discovery_perl」キーをもつ UserParameterとして使用することです:

#!/usr/bin/perl
 
$first = 1;
 
print "{\n";
print "\t\"data\":[\n\n";
 
for (`cat /proc/mounts`)
{
    ($fsname, $fstype) = m/\S+ (\S+) (\S+)/;
    $fsname =~ s!/!\\/!g;
 
    print "\t,\n" if not $first;
    $first = 0;
 
    print "\t{\n";
    print "\t\t\"{#FSNAME}\":\"$fsname\",\n";
    print "\t\t\"{#FSTYPE}\":\"$fstype\"\n";
    print "\t}\n";
}
 
print "\n\t]\n";
print "}\n";

そのアウトプット(明快にするためにフォーマットが変更されています)を以下に示します。カスタムディスカバリのチェックのJSON は、同じフォーマットに従う必要があります。

{
  "data":[
  
  { "{#FSNAME}":"\/",                           "{#FSTYPE}":"rootfs"   },
  { "{#FSNAME}":"\/sys",                        "{#FSTYPE}":"sysfs"    },
  { "{#FSNAME}":"\/proc",                       "{#FSTYPE}":"proc"     },
  { "{#FSNAME}":"\/dev",                        "{#FSTYPE}":"devtmpfs" },
  { "{#FSNAME}":"\/dev\/pts",                   "{#FSTYPE}":"devpts"   },
  { "{#FSNAME}":"\/",                           "{#FSTYPE}":"ext3"     },
  { "{#FSNAME}":"\/lib\/init\/rw",              "{#FSTYPE}":"tmpfs"    },
  { "{#FSNAME}":"\/dev\/shm",                   "{#FSTYPE}":"tmpfs"    },
  { "{#FSNAME}":"\/home",                       "{#FSTYPE}":"ext3"     },
  { "{#FSNAME}":"\/tmp",                        "{#FSTYPE}":"ext3"     },
  { "{#FSNAME}":"\/usr",                        "{#FSTYPE}":"ext3"     },
  { "{#FSNAME}":"\/var",                        "{#FSTYPE}":"ext3"     },
  { "{#FSNAME}":"\/sys\/fs\/fuse\/connections", "{#FSTYPE}":"fusectl"  }
  
  ]
}

そうすると、ディスバリルールの[フィルター]フィールドで、マクロとして{#FSTYPE} を、正規表現として「rootfs|ext3」を指定できます。

カスタムのLLDルールにマクロ名 FSNAME/FSTYPE を使用する必要はありません。どんな名前でも自由に使用することができます。

本ページは2013/05/12時点の原文を基にしておりますので、内容は必ずしも最新のものとは限りません。
最新の情報は右上の「Translations of this page」から英語版を参照してください。