【ZABBIX】やっぱりLLD(ローレベルディスカバリ)は最高だぜ！

ZABBIX 2.0 の新機能、ローレベルディスカバリ(Low Level Discovery、以下 LLD)は、自動的にアイテム・トリガ・グラフを生成してくれるもの。サーバ内の状況に応じ、動的に監視対象を変化させる事ができます。

本記事は、LLD の概要と、実際に設定を行うチュートリアルで構成しました。既に公式ドキュメントを読まれた方には、不要かと思います。自分が理解に時間がかかってしまったので、、これから LLD を始める方が迷わないようにと、チュートリアル形式で記事をまとめてみました（SNMP の効率的な OID データ収集に関しては、途中記事を飛ばして読んでいただいて構いません。）

本記事の概要

Zabbix 2.0 からローレベルディスカバリ機能(LLD)が使えるようになった。
検出用の標準キーは3種類（vfs.fs.discovery＝ファイルシステム検出、net.if.discovery＝NIC検出、snmp.discovery＝SNMP検出）
ディスカバリルール作成は、1. 検出用のキー作成 → 2. アイテムのプロトタイプ作成 → 3. トリガやグラフのプロとトタイプ作成
サーバ内の状況にあわせて、動的にアイテム生成するので作業効率向上。
やっぱり、ローレベルディスカバリは最高だぜ！　←結論

■ふたつのディスカバリ機能

ZABBIX には、ディスカバリ機能が２つあります。version 1.8 移行に実装された「オートディスカバリ」と、今回の「ローレベルディスカバリ」は、どちらもディスカバリですが、’発見’すべき対象が異なるのです。

左図は、ZABBIX のオートディスカバリ機能の概要図です。ZABBIX ‘設定’の項目にある「ディスカバリ」によって設定します。

これは、ZABBIXサーバが、指定条件（ネットワーク範囲や稼働中のサービス）に対して定期的に監視を行います。

もし、条件に一致する対象が発見されたら、自動的にルールを追加したり、操作を行う機能です。

一方のローレベルディスカバル( LLD )は、サーバの「中」が検出対象です。

どちらも’ディスカバリ’の名前がつくため、混同しがちです。でも、機能は別モノであるという風に、まずは認識しましょう。

■ローレベルディスカバリとは？

ZABBIX のテンプレート機能は、複数台のサーバ管理を楽にしてくれる機能です。ですが、OSのバージョンの違いや、ハードウェア構成によっては、テンプレートを元に個別に調整が必要な場合がありました。例えば、特定のサーバではハードディスクの本数が違ったり、NIC の数が違っていたり。あるいは、SNMP のスイッチ系の監視でも、機器によってポートの構成が違うことで、せっかくテンプレートがあっても手が掛かる事が多かったのではないでしょうか。

そこで登場したのが、ロウレベルディスカバリ機能(Low Level Discovery、以下 LLD ) ですLLD を使えば、サーバや SNMP の状況に応じて、自動的にアイテム・トリガ・グラフを生成することが出来ます。また、自分でスクリプトを書けば、任意の情報を元に LLD を構成することが出来ます（JSON形式で扱えるものであれば、ZABBIX は認識可能です）。

標準で検知可能な対象（ディスカバリ・－キー）は、３つです。

vfs.fs.discovery … ファイルシステム検出
net.if.discovery … ネットワークインターフェース検出
snmp.discovery … SNMP OID 検出

vsf.fs.discovery と net.if.discoery は、標準テンプレート ‘Template OS Linux’ にも組み込まれているため、知らずに使われている方も多いと思います。

snmp.discovery は、前の2者とは少し性質が異なります。任意の SNMP OID に対して、得られたデータを元にインデックスを作成し、そのインデックスを元に、新たに別の SNMP OID が取得出来ます。

LLD を使うための手順は、シンプルです。

ディスカバリルールを作成する
アイテムのプロトタイプを作成する
アイテムのトリガやグラフを作成する（オプション）

ただ、ディスカバリルールの作成方法は、vfs.fs.discovery(ファイルシステム) と net.if.discovery (NIC) の二組と、SNMP OID 検出用の snmp.discovery では微妙に異なります。

以下、それぞれ、実際に設定しながら作業をすすめましょう。

■ LLD を使うには

LLD を使うためには、ZABBIX エージェントまたは SNMP を ZABBIX 上の対象ホストのインターフェースに登録する必要があります。

vfs.fs.discovery … ZABBIX エージェントとの通信
net.fi.discovery … ZABBIX エージェントとの通信
snmp.discovery … SNMP ( snmpget や snmpwalk )

まずは、それぞれの設定が適切に行われているか、確認します。

ZABBIX エージェントが利用可能であれば、ZABBIX サーバのコマンドラインで、次のように値が取得出来るようになります。

$ zabbix_get -s 192.168.10.2 -k net.if.discovery
{
        "data":[
                {
                        "{#IFNAME}":"lo"},
                {
                        "{#IFNAME}":"eth0"},
                {
                        "{#IFNAME}":"eth1"},
                {
                        "{#IFNAME}":"eth2"}]}

これは、コマンドラインでキー ‘net.if.discovery’ を直接指定し、対象サーバ上のネットワークインターフェースを一覧表示してくれます。ちなみに、ここで表示される {#IFNAME} は、マクロとして利用できることができます（通常のマクロ {$xxx} とは異なる事に注意してください。あくまで LLD が条件判別をするためのマクロです）。

ここで見えているデータを元に、LLD 機能が動作します。LLD のディスカバリルールを構成しているのは、LLD 用のアイテムと、プロトタイプです。

「LLD アイテム」…実機上に存在しているもの（ファイルシステムやNIC)
「プロトタイプ」…アイテム、トリガ、グラフの元となるプロトタイプ（雛形）

LLDのディスカバリで検出したデータが「アイテム」となり、そのアイテムが存在するものとして「アイテムのプロトタイプ」を定義します。ここは ZABBIX の中での新しい概念です。仮に、何か検出されたものと仮定して、予め雛形としてのアイテムを生成し、それに対してトリガやグラフを作成します。ちょっと抽象的ですが、プログラミングでいう所の変数のようなものです。慣れないと、少し抽象的機能に思えてしまいますが、変数と思えば腑に落ちます（そういう意味では、LLD のディスカバリ用のル－ルは、関数作成のようなものかもしれません）。

それでは、実際に LLD の設定を行ってみましょう。設定は、対象となるホストかテンプレート上の ‘ディスカバリ’ ルールに追加します。

■LLD その１、vfs.fs.discovery でファイルシステムの情報を取得する

ファイルシステム一覧を表示する vfs.fs.discovery を試します。この値が出力できると、パーティション名をトリガとし、ディスク使用率や空き容量の表示、アラート作成、グラフ生成ができるようになります（標準テンプレート Template OS Linux には登録済みです）。

ここでは、ファイルシステムのデータを元に、パーティション（マウントポイント）一覧の情報を取得してみます。

‘設定’→’ホスト’または’テンプレート’から、対象となるホストの【ディスカバリ】をクリックします。

【ディスカバリルールの作成】を押します。

ここで入力する項目を、１つ１つみていきます。

名前 … 「ファイルシステム検出」このルール名は任意のものです
タイプ … 「Zabbix エージェント」固定です。
キー … 「vfs.fs.discovery」こちらも固定です。
ホストインターフェース … 対象ホストの Zabbix エージェント用ポートが表示されます。
更新間隔 … 「30秒」は標準ものです。もっと長くしても良いと思います。
存在しなくなったリソースの保持期間（日）…「30日」も標準です。少し長すぎるかも。
フィルター … 不要な情報の除去が出来ます。たとえば、コマンドラインでキーの情報を取得(zabbix_get -s 192.168.10.2 -k vfs.fs.discovery) すると、/proc や /sys など、ファイル用としては使わないシステム用のパーティションも見えてしまいます。それをフィルタすることができます。vfs.fs.discovery では、取得した値を元にマクロ「{#FSNAME}」と「{$FSTYPE}」が定義されますので、この情報を元にフィルタすることが出来ます。
- マクロ {$FSTYPE} … ファイルシステムの種別をフィルタのキーにします。他にも {$FSNAME} をキーにすることも出来ます。
- 正規表現「^{ext3|ext4|tmpfs}$」は、システム領域を除いたファイルシステムが ext3 または ext4 または tmpfs のみを取得するという指定です。
  ※ ‘Templage OS Linux’ では、正規表現が「@File systems for discovery」となっています。これは ‘管理’→’一般設定’→’正規表現’で定義されている「^(btrfs|ext2|ext3|ext4|jfs|reiser|xfs|ffs|ufs|jfs|jfs2|vxfs|hfs|ntfs|fat32)$」
  を参照しています。

最後に【保存】を押すと、設定が有効になります。記述ミス等なければ、「有効」なルールとして、画面に表示されていると思います。

次に、この発見したルールに基づいてアイテムと作成します。例として、ディスクの使用率を表示するアイテムを作成します。LLD では、このアイテムのことを、アイテムのプロトタイプと言います。「アイテムのプロトタイプ」をクリックします。

画面が切り替わったら、右上【アイテムのプロトタイプ作成】をクリックします。

名前 … 「ディスク使用率 $1 %」 $1 は、アイテムで取得した値を表示するマクロです
タイプ … 「Zabbix エージェント」ここは固定です。
キー … ここが、アイテムのプロトタイプ設定の上でのキモになります。{#FSNAME} は自動生成マクロであり、ディスカバリ・ルールで取得した値が自動的に反映されます。$ で始まるマクロが普通のマクロなら、# で始まるマクロは、ディスカバリルール専用のマクロと認識しておくと、区別が付きそうです。
※ ‘vfs.fs.size’ は、普通のアイテムの記述方法と同じです。{$FSNAME}が入るため、複雑に見えますが、単純にこういうマクロ（変数）と割り切るとスッキリします。
その他の項目 …　通常のアイテム作成と変わりません。

最後に【保存】を押すと設定が有効になります。

それでは、設定が反映している事を確認しましょう。’設定’→’ホスト一覧’を開きます（テンプレートで LLD を作成した場合は、テンプレートを適用したホストを確認します）。開くと、アイテム数が自動的に増えているのが確認出来ます。

ここで「アイテム(7)」と表示されている所に注目します。ディスカバリ・ルールを指定する前は、アイテムが0件でしたが、ルール指定により、自動的に7件分のアイテムが作成されていることがわかります。「アイテム」をクリックすると、自動認識されたパーティション情報が表示されます。

ここでアイテムが表示されていれば、設定は完了です。あとは、必要に応じて「アイテムのプロトタイプ」のキーを変更したり、通常通り、トリガやグラフの定義を行う事が出来ます。

ここまでの動作が出来れば、vfs.fs.discovery を使いこなしたと言えるでしょう。対象となるホストによって、動的に変化するファイルシステムの値を、LLD 専用のマクロ {#FSNAME} や {$FSTYPE} を使い、プロトタイプとなるアイテムを定義する、という事です。

それでは、次は NIC を検出します。

■LLD その2、net.if.discovery でNICの情報を取得する

ファイルシステムの次は、NIC のインターフェースを自動検出します。基本的に、その１のキー「vfs.fs.discovery」と全く同じですが、キーが「net.if.discovery」に変わります（変わります、というだけで、設定方法は同じです。興味が無ければ、その3 snmp.discovery に進んでください）。

では、NIC を自動的に検出し、監視対象にします。

‘設定’→’ホスト’または’テンプレート’から、対象となるホストの【ディスカバリ】をクリックします。

【ディスカバリルールの作成】を選びます。

ここで重要なのは、キーで「net.if.discovery」を選ぶところと、フィルターです。{$IFNAME}に対してフィルタ（除外）条件を指定しているのは、先の正規表現の’Network interfaces for discovery’です（lo で始まるループバックデバイスをフィルタ＝除外しています）。

あとは、表示されるアイテムの内容は、その１と同じなので以下割愛です。

■LLD その3、snmp.discovery で任意の OID を取得する

「snmp.discovery」は、Zabbix 2.0 で搭載された、最高の機能だと、私は思っています。これは、他のディスカバリ機能と決定的に違うのは、ZABBIX エージェントを必要としない点です。snmp.discovery は、SNMP の通信のみを見ます。つまり、OS の入らない機器やスイッチに対する監視を強化する方法として、SNMP を取得できる ZABBIX が、楽に様々な設定を自動取得するのが、snmp.discovery と言えるのです。

snmp.discover の動作も、単純です。

任意の SNMP OID から得られた結果を「インデックス」として記録し
そのインデックスを元に、任意の「SNMP OID」の情報を取得する

ただ、これだけなのです。

※前提として、zabbix-server の動いている環境が、監視対象に snmp で情報を取得できる必要があります。機器固有・OS 固有の兼もあるので、本稿は割愛。少なくとも、zabbix-server から、「snmpwalk -v 2c -c <コミュ名> <ホスト名>」で情報が取得できない場合は、対象機器・ホストのsnmpd そのものの設定を見直してください。

では、試しに、その１で取得した、ファイルシステムの情報を、敢えて SNMP で取得します（ファイルシステムである必要は無いのですが、あくまでサンプルとして。実環境では、UP しているポート情報を指定すると、色々捗りそうです）。

それでは、snmp.discoverry に戻りましょう。たとえば、SNMP OID 「 .1.3.6.1.2.1.25.3.8.1.2」で取得できる、パーティション情報を自動取得する方法を検討します。snmpwalk を使って取得する結果は、次のようになります。

$ snmpwalk -On -v 2c -c public 192.168.10.2 .1.3.6.1.2.1.25.3.8.1.2
.1.3.6.1.2.1.25.3.8.1.2.1 = STRING: "/"
.1.3.6.1.2.1.25.3.8.1.2.5 = STRING: "/boot"
.1.3.6.1.2.1.25.3.8.1.2.6 = STRING: "/var
.1.3.6.1.2.1.25.3.8.1.2.7 = STRING: "/dev/shm"
.1.3.6.1.2.1.25.3.8.1.2.8 = STRING: "/var/www/html"

ここで注目するのは「.1.3.6.1.2.1.25.3.8.1.2」（緑字)をのぞき、赤の「1」「5」「6」…が独立していて、かつ、「1」には「/」、「5」には「/boot」、「6」には「/var」が対応している点です。これって、規則制がありますよね。緑の部分は共通で、赤の部分に対して値がある。この赤字の部分が、マクロ{#SNMPINDEX} として定義できます。そして、「/」「/var」「/dev/sdm」は {#SNMPVALUE} として定義できます。