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

【ZABBIX】やっぱりLLD(ローレベルディスカバリ)は最高だぜ! はてなブックマーク - 【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 には、ディスカバリ機能が2つあります。version 1.8 移行に実装された「オートディスカバリ」と、今回の「ローレベルディスカバリ」は、どちらもディスカバリですが、’発見’すべき対象が異なるのです。

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

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

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

 

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

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

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

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

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

標準で検知可能な対象(ディスカバリ・-キー)は、3つです。

  • 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 を使うための手順は、シンプルです。

  1. ディスカバリルールを作成する
  2. アイテムのプロトタイプを作成する
  3. アイテムのトリガやグラフを作成する(オプション)

ただ、ディスカバリルールの作成方法は、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 その1、vfs.fs.discovery でファイルシステムの情報を取得する

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

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

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

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

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

  • 名前 … 「ファイルシステム検出」 このルール名は任意のものです
  • タイプ … 「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 のインターフェースを自動検出します。基本的に、その1のキー「vfs.fs.discovery」と全く同じですが、キーが「net.if.discovery」に変わります(変わります、というだけで、設定方法は同じです。興味が無ければ、その3 snmp.discovery に進んでください)。

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

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

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

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

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

■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 そのものの設定を見直してください。

では、試しに、その1で取得した、ファイルシステムの情報を、敢えて 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} として定義できます。

では、この除法を元に、SNMP を通してファイルシステムの一覧情報を取得します。

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

ここで独特なのが、LLD 用マクロ {#SNMPVLUE}と {#SNMPINDEX} の扱いです。これまでのディスカバリ・ルールやキーは「存在する何か」に対する値を指定していますが、snmp.discovery の場合は、「存在しない何か」に対して定義することが出来ます。

この前提で設定すると、SNMP のアイテムプロトタイプが、比較的簡単に設定できると思います。


ここで、プロトタイプのアイテムに対してマクロを使うのが重要な所です。一見したところ、普通のアイテムですが、キーと SNMP OID に対して {$SNMPINDEX} {$SNMPVALUE}の指定が入っている所がおおっきな違いです。

あとは、設定反映後、対象ホストまたはテンプレートの中に、LLD の結果で検出されたアイテムが、対象ホストのアイテムとして自動生成され、また、トリガやグラフも作成されているのも確認できると思います。

以上、おおまかに LDD の概念と設定について記述しましたが、LLD(ローレベルディスカバリ)の概念は、これまでの ZABBIX のテンプレートとはひと味違った趣があります。まずは、自分の手を動かして慣れてみるのが、機能に対する理解に繋がると思います。

サーバリソースに応じて、動的に監視対象を変更。ありそうで、なかったのが、この LLD ( Low Level Discovery ) です。現場にとって、手間や作業時間の軽減に繋がると思いますので、興味がありましたら、是非お試しいただければと思います( ^ω^)