目次 表示
GroundWork Monitor の全バージョンでは、SNMP ポーリングの直接サポートを提供し、さらに GroundWork Monitor の商用版では SNMP トラップの新たなサポートを追加しています。
簡単に言うと、GroundWork Monitor は、SNMP ポーリングによりメモリ使用率やネットワークトラフィックのレベルなど、共通の統計のためにネットワークデバイスの問い合わせができ、ネットワークデバイスは SNMP トラップにより、重大な障害が発生したらいつでも GroundWork Monitor に一方的に通知することができます。
例えば、SNMP ポーリングは、1-2 時間おきにデバイスの現在のディスク使用レベル読むことができ、このデータを使って監視したり長期間の使用傾向を図化したり、使用率が異常と判断されたらアラームを発生させることに使用できます。しかし、そのポーリングの間に急に重大なディスク不足が起こったら、この使い方では、ディスク容量不足を数時間検出できないことになります。このような状況下において、すぐにエラー状態を示唆するSNMPトラップメッセージを一方的に送出できれば、その問題のあるデバイスに対応するのに最適です。
すべての SNMP メッセージは、User Datagram Protocol(UDP)で運搬されます。これには SNMP クエリと送りつけられるトラップメッセージが同様に含まれます。トランスポートプロトコルとしの UDP の使用はいくつかの利点がありますが、送ることのできるメッセージのサイズに相当に厳しい制約を強いります。SNMPメッセージがサイズの制限に収まるであろうことを確実にするため、SNMPプロトコルは、メッセージを比較的小さく保つさまざなのエンコードと、圧縮技術を使用します。しかし、このことはメッセージ自体がバイナリであり、目で見て解読できないことも意味します。
実際は、SNMP メッセージにはイベントに関係するすべてメッセージは含まれませんが、その代わりに背後にあるメッセージにユニークに関係付けられたメッセージ ID を使用します。一方、そのイベントに関する情報(そのイベントの重大度やメッセージテキストの全体など)は、メッセージ受信側で独立して保守されているManagement Information Base (MIB)と呼ぶ辞書ファイルの中に保存されています。このモデルでは、送り側のステーションは元メッセージ内の ID 値を提供するだけでよく、メッセージを送らなくとも、受け側がその ID 値をオペレータ(人)に見せることができる実際のイベントメッセージと対応付けます。
例えば SNMP 管理ステーションでは、メッセージはネットワークインタフェースがオンラインになった後、"Link up on interface 2(インタフェース2のリンクがアップした)"というイベントを記録することができます。しかし、その元になる SNMP メッセージは(アクティブになったインタフェースのための変数値といっしょに)そのイベントのための固定の識別子の値のみが含まれますが、"Link up" のメッセージ全体は含まれません。その代わりにトラップ送出側は、コード値を受信システムがローカルにある MIB と関連付けて、固定位置の変数データを置き換えて正しいメッセージを表示することができると期待します。
同様に、SNMPメッセージは、それ以外の ID が辞書の中で正しく参照されている限り、それ自体の外側でオブジェクトID を参照することができます。例えば、上述の "Link up on interface2" メッセージの数値は、一般的なメッセージ内に記述された数値の記法を使用します。そのような事情なので、このイベントのためのトラップ辞書は、変数値の記法ルールを定義する必要がありませんが、その代わりに単に親定義を参照することが可能です。
全体として、このアプローチはメッセージと辞書ファイルを非常に小さくかつ効果的にしますが、人にはメッセージデータが不可解になります。そのため、人にそのデータが使えるようにするためには、このモデルでは、SNMP管理ステーションのトラップメッセージ辞書とそれらのIDアサインを保守して、入ってきたメッセージがそのフルテキストのイベントメッセージにマッピングされ、メッセージ変数データがデコードされて必要な場所に適用されるようにする必要があります。
デフォルトでは、GroundWork Monitor の商用版は少数の共通メッセージを捕捉する基本 SNMPトラップハンドラを提供します。それら共通メッセージは、さまざまな Guava アプリケーションを通して参照するために GroundWork の Foundation データベースに格納され、また通知メッセージを発生させるために Nagios に渡されます。
より具体的に言うと、GroundWork Monitor は、ネットワークから届いた SNMPトラップの受信、処理、および保存のために下記のコンポーネントを使用します:
入ってきた SNMPトラップは、Net-SNMPソフトウェアパッケージで提供されるsnmptrapdによって受信されます。snmptrapd は、ネットワークから入ってくる SNMPトラップメッセージを受け取るのに必要なネットワークリスナーを提供します。
トラップメッセージが受信されると、snmptrapd は入ってきたメッセージを SNMP Trap Translator ソフトウェアパッケージの一部である snmptthandler プログラムに渡し、それがスプールファイルにトラップメッセージを順番に放出します。これにより、snmptrapd はメッセージを高速に処理することができます。
定期的に、SNMP Trap Translator パッケージに含まれている snmptt デーモンは新しいメッセージがないかスプールファイルを調べ、構造化テキストに変換します。そして一斉にアウトプットを GroundWork の Foundation データベースと Nagios の NSCA パッシブインタフェースに渡します。この変換プロセスにより、SNMP メッセージを他のテキスト形式のイベントメッセージと同様に処理することができます。
Foundation データベースのリスナーによって受け取られたトラップメッセージは、元のホストデバイスと関連付けられ、SNMPTRAPイベントメッセージとして記録されます。データベースが更新されたら、そのトラップデータはオペレータが、グローバルのイベントビューアかホスト固有のステータスアプレットを使って表示することができます。
一方、NSCA インタフェースを介して Nagios によって受け取られたトラップメッセージは、次のチェック間隔まで、Nagios のコマンドファイル内に保存されます。その後、これらのパッシブチェックが Nagios に処理されたら、入ってきたメッセージは元のホストファイルと関係付けられ、そのホストに関連した snmptraps_last サービスのイベントとして処理されます。ここにおいて、そのメッセージは、通知メッセージを生成するなど、Nagios 内で実行可能などのようなアクションでも実行するために使用することができます。
全体として、この設計では、個々のソフトウェア・コンポーネントが設定されると、GroundWork Monitor は総合的な SNMP 監視と管理ステーションとして機能することができます。
GroundWork Monitor の以前のバージョンは、異なるソフトウェア・コンポーネントを使用した若干異なるアーキテクチャを使用しています。GroundWork Monitor の以前のバージョンから提供されている SNMP トラップを使用されている場合、バージョン 5.2 でそれらのカスタマイズが正しく動作させるためには、旧い構成ファイルを変換する必要があります。GroundWork Monitor は、その手続きをいくらか自動化するための/usr/local/groundwork/tools/snmp_mibs/upgrade_snmptt_conf.sh の中で変換スクリプトを提供します。
GroundWork Monitor は、 UDP ポート162 に入ってくるトラップメッセージを監視する snmptrapd デーモンを含む、Net-SNMP ソフトウェアパッケージ全体を取り込んでいます。snmptrapdはデフォルトで有効になっており、インストール後自動的に起動されます。
注意:GroundWork Monitorは snmptrapd 専用の起動スクリプトを提供しませんが、その代わりに SNMPTT サービスを初期化するのに使う /etc/init.d/snmptt の起動スクリプトの中でそのデーモンをスタートさせます。もし snmptrapd デーモンをリスタートする必要があれば、そのコントロールスクリプトを使うべきです。
ネットワークインタフェースのため、デフォルトのポートについてSNMPリスナーをひとつだけアクティブにすることができますので、他の目的のために他のトラップ・リスナーを既に使用している場合、リスナーを異なるネットワークインタフェースやポート番号を使うよう構成設定する、あるいは、両方の構成ファイルを統合(他ソースからの snmptrapd を既に使用している場合、構成ファイルをマージするだけで使えるかもしれません)する必要があります。
GroundWork Monitorにバンドルされた snmptrapd デーモンのための構成設定は、/usr/local/groundwork/etc/snmp/snmptrapd.conf に格納されています。デフォルトの構成ファイルは、SNMPトラップを捕まえてそれらを処理するため snmptthandler に渡す最低限のディレクティブを含みますが、必要であれば追加の構成ディレクティブが追加されるでしょう。
注意:デフォルトの構成ファイルでは何のフィルタも定義されていませんので、入ってきたすべてのトラップメッセージはデフォルト設定で捕捉されます。特定のホストや特定の SNMPコミュニティについて、SNMPトラップのハンドリングを制限する必要があれば、この構成ファイルをしかるべく編集する必要があります。さもなければ、あなたのネットワークデバイスに、GroundWork Monitor サーバへ SNMPトラップを送り始めるように指示するだけで、メッセージが何らのローカルの構成要求もなしに、すぐに受信され処理されます。
SNMP トラップメッセージの生のフォームは、GroundWork Monito rや Nagios で直接使用していない、分かりにくいバイナリ書式を使っています。そのため、GroundWork Monitor は生のSNMPトラップを、取り扱いやすい構造化されたテキスト形式メッセージに変換するために、オープンソースのSNMPトラップ・トランスレータ(SNMP Trap Translator :SNMPTT) パッケージを使用しています。
具体的には、snmptrapd は、入ってきたSNMPトラップをトラップメッセージを入来スプールファイルの中に次々と保存するsnmptthandler というプログラムに渡します。1、2分ごとに独立した snmptt デーモンが、新しいトラップメッセージを探しにそのスプールファイルを読んで、そのメッセージを構造化テキスト形式変換します。そして、その出力をしかるべきローカルインタフェースを介して GroundWork の Foundation データベースと Nagios の NSCAエ ージェントに渡します。
snmptt は、どのようにトラップメッセージを変換して伝えるかを定義する、複数の構成ファイルを使います。第一、そして最も重要なのが /usr/local/groundwork/etc/snmp/snmptt.ini で、snmptt デモーンが期待通りに働くための必要なグローバルオプション(データベース接続とロギングオプションなど)含んでおり、また snmptt デーモンに指定されたトラップメッセージをどのように処理か指示する従属するトラップ固有の構成ファイルに対するポインターを含んでいます。
実際の翻訳と処理プロセスは、トラップ固有の構成ファイルによってコントロールされます。例えば、/usr/local/groundwork/etc/snmp/snmptt.conf は、ひとにぎりの普遍的な SNMPトラップメッセージのための処理ディレクティブを含みます。また、GroundWork Monitor は、2、3の、それ自体の構成ファイル(CISCO-GENERAL-TRAPS.conf 構成ファイルは CISCO のネットワーク装置で共通的に見られる SNMP トラップのためのマッピング情報を含む、など)を保存する、特定デバイスのための定義済みの翻訳ファイルを含んでいます。これらの翻訳特有の構成ファイルは、あらかじめ snmptt.ini コントロールファイルの中にリストされており、対応するSNMPトラップメッセージを処理するのに使用されます。
まだ定義されていないSNMP トラップ のトラップメッセージ全体と重要度の詳細を捕らえる必要がある場合、しかるべき SNMPの MIB ファイルからこの情報を取り出し、そのトラップメッセージを(snmptt デーモンにどこにメッセージを送るかを指示する情報と共に)コントロールファイルのひとつに追加する必要があります。GroundWork Monitor はこのプロセスの一部を単純化し、自動化するためのさまざまなツールを提供しますが、通常、いくらかの手動での調整が必要です。
新しいトラップ翻訳定義追加の仕方についての情報は、新規トラップ定義の追加のセクションを参照してください。
snmptt デーモンが変換したトラップメッセージを GroundWork の Foundation イベントデータベースに渡す必要があるとき、その出力をループバック・インタフェース(127.0.0.1)上の TCPポート 4913 の Foundation のネットワーク・リスナーに渡し、そのデータがしかるべき重大度レベルを付けた SNMPTRAP イベントであるとのフラグを立てます。そして、SNMPTRAP の Foundation アダプタはそのデータを調べ、そのイベントを GroundWork の Foundation データベースの LogMessage テーブルに追加します。
注意:snmptt は、デフォルトで、snmptt.iniやそれに付随する構成ファイル内にリストされていない未知の SNMP トラップメッセージを含めて、すべてのトラップメッセージをGroundWork Foundation リスナーに送るように構成されています。そのメッセージは、重要度レベルが "unknown"、メッセージテキストが "unknown trap" として表示されるでしょう。新しいトラップ定義を snmptt 構成に追加する情報については、新規トラップ定義の追加セクションを参照してください。
デフォルトでは、SNMPTRAP アダプタは重複したイベントメッセージを連続して受け取ったら統合します。トラップイベントが、その統合基準に適合した場合、重複したイベントメッセージは廃棄され、既存レコードの "count" フィールドがインクリメントされ、"last insert date" フィールドが更新されます。具体的には統合機能は、下記のフィールドでレコードの重複を決定し、すべてのフィールドが一致すれば、その重複は廃棄されます:
OperationStatus
Host
Severity
IP Address
MonitorStatus
Event_OID_numeric
Event_Name
Category
Variable_Bindings
上記に対する例外として、前のイベントの MonitorStatus(モニタリング状態)と受信イベントのモニタリング状態が異なる場合があります。この場合、新規のイベントメッセージが生成されます。このルールは、コンソールのメッセージは時間の順番でソートされ、常に現在の状態が以前の状態の上に表示されることを保証します。
もし望むなら、トラップの統合を無効にすることができます(そうすると、SNMP トラップを受信するたびに新しいイベントレコードが作られることになります)。また、必要であれば統合サービスのためのフィールドを変えることもできます。統合機能のため使われるフィールドは、GWCollageDB データベースの ConsolidationCriteria テーブルの SNMPTRAP エントリの中に格納されています。
イベントレコードがイベントデータベースに挿入されると、そのトラップメッセージは、Event Console(イベントコンソール)アプリケーションで参照することができます(左のナビゲーションツリーの中の SNMPTRAP オプションを選ぶと、SNMP イベントだけが表示され他のメッセージはフィルタされます)。ホストを選んでホストステータス画面の "Console(コンソール)" 部の下を見ると、ホストに関連した最新の SNMP トラップメッセージは、Status(ステータス)アプリケーションで参照することができます。
snmptt デーモンは、入ってきたトラップをループバック・インタフェース(127.0.0.1)上の TCP ポート 5667 の NSCA パッシブインタフェースを介して、Nagios に渡し、そのデータに発生もとのホストの snmptraps_last サービスのパッシブチェック結果のフラグを立てます。ここから、Nagios は定期的に入来パッシブチェックキューを処理し、入来イベントを発生元ホストと関連する snmptraps_last サービス定義と関係付けようと試みます。
より具体的にいうと、snmptt デーモンは翻訳されたトラップメッセージを提供し、またそのトラップが良性、ワーニング、クリティカルイベント、あるいは未知のメッセージのどれかを示す Nagios 固有の結果コードを提供します。そして、Nagios は、いつ通知を開始して他のアクションを実行するかを決めるためトラップの重要度を使うことができ、service status(サービスステータス)フィールド内にトラップのテキストを表示することができます。
注意:snmptt は、snmptt.ini やそれに付随する構成ファイル内にリストされていない未知の SNMPトラップメッセージを含めて、すべてのトラップメッセージを NSCA リスナーに送るよう構成されています。そのメッセージは、重要度レベルが "unknown"、メッセージテキストが "unknown trap" として表示されるでしょう。新しいトラップ定義を snmptt 構成に追加する情報については、新規トラップ定義の追加(Adding New Traps Definitions)セクションを参照してください。
このプロセスが機能するためには、Nagios の NSCA パッシブインタフェースが有効になっている必要があり、発生元のホストが必ず Nagios 内で定義され、発生元のホストが関係付けられた snmptraps_last サービス定義を持つ必要があります。
注意:Nagios の NSCA パッシブインタフェースはデフォルトではアクティブではありませんので、SNMPトラップメッセージを受け取れるように事前に開始しておく必要があります。/etc/init.d/nsca の init スクリプトがこの目的のために提供されています。NSCA サービスが常に必要であれば、この init スクリプトをシステムの init スクリプト内に含めるべきでしょう。
また、GroundWork Monitor には関連するサービスプロファイルが提供されていますが、Nagios のデフォルトのサービス定義には snmptraps_last サービスが含まれていないことに注意してください。
このサービスを使うためには、下記の手順を行います:
GroundWork のメインメニューから、Configuration(コンフィギュレーション)アプリケーションを選びます。
上部メニューバーの Profiles(プロファイル)メニューをクリックします。
左側ウィンドウの Profile importer(プロファイルインポート)メニュー項目をクリックします。これにより、使用可能なすべてのホストとサービスプロファイルがメインウィンドウに表示されるようになります。
利用可能なプロファイルのリストの中から"service-profile-snmp-traps.xml" のエントリを探し、その隣のチェックボックをアクティブ(チェック付け)にします。
メインウィンドウの最下部までスクロールし、Import(インポート)ボタンをクリックします。これにより、snmptraps_last サービス定義が現在の構成にインストールされます。
上記の手順が完了したら、snmptraps_last service サービス定義が使用できるようになり、どの定義済みホストにでも関係付けることができます。
全述のとおり、SNMP トラップ・トランスレータ・ツールキットは、デコードしたメッセージを Foundation データベースと Nagios NSCA に渡すために、入ってきたバイナリのトラップメッセージを構造化テキストに変換します。これが正しく構成されたとき、snmptt デーモンは正しい完全にフォーマットされたテキスト形式のメッセージを生成することができ、そのトラップメッセージに適当な重大度レベルを関連付けます。しかし、SNMPトラップ・トランスレータは、当初はわずかの共通のトラップメッセージのために構成されているだけで、それ以外のすべての場合にはsnmpttデーモンは、適切な重大度レベルを付けられないし、意味のある状態テキストメッセージも提供できません(その代わりに総称的な"unknown"トラップメッセージが使われます)。
まだ定義されていない SNMP トラップのトラップメッセージ全体と重大度を捉える必要がある場合、しかるべき SNMPの MIB ファイルからこの情報を抽出して、そのトラップメッセージを(snmptt デーモンにそのメッセージをどこに送るかを指示する情報とともに)コントロールファイルのひとつに追加する必要があります。GroundWork Monito rはこのプロセスの一部を単純化し自動化するためのさまざまのツールを提供しますが、通常、いくらかの手動での調整が必要です。
実際には、/usr/local/groundwork/tools/snmp_mibs/convert_mib.shスクリプトが指定された MIB ファイルを読んで、その中に含まれているトラップ定義を見つけます。MIB ファイルに問題(満たされない依存関係や書式エラーなど)がなければ、convert_mib.shスクリプトが、snmptt と共に使用するため、snmptt が正しく処理を行って、それらのトラップメッセージを中継するために必要なすべてのトラップ定義とオプションを含むローカルの.confファイルを作成します。ここで出力の.conf ファイルは、snmptt.ini コントロールファイルに追加することができ、snmptt デーモンが再初期化された後に新しいメッセージが処理されるでしょう。しかし、(満たされない依存関係や書式エラーなどのために)元の MIB ファイルを変換することができない場合、SNMP トラップが捕捉できるようになるためには追加の手続きが必要です。
手順の最初のステップは、捕まえて変換したいトラップメッセージを含む SNMP の MIB ファイルを見つけることです。ほとんどの装置ベンダーは必要な MIB ファイルを、それらのインストレーションソフトウェアとともに提供します。また、インターネットの中にはさまざまなサードパーティの MIB リポジトリがあり、それらは MIB ファイルを見つけるのに便利です。
MIB ファイルが入手できたら、snmptt 構成ファイルに自動変換するために、唯一のパラメータとして MIB ファイル名を指定して、/usr/local/groundwork/tools/snmp_mibs/convert_mib.sh スクリプトを使います。変換処理が成功したら、新しいファイルがローカルのディレクトリの中に入力ファイルとして、同一の名前の後に .conf の添え字付きで作成されます。
例えば下の図は、"convert_mib.sh /tmp/UCD-SNMP-MIB.MIB" コマンドを示します。このコマンドは、convert_mib.shスクリプトに"/tmp/UCD-SNMP-MIB.MIB" ファイルを読ませ、MIB ファイルの SNMP トラップ定義を見つけさせて、カレントディレクトリの中に "UCD-SNMP-MIB.MIB.conf" というSNMPトラップ・トランスレータの構成ファイルを作成させます。この例では、出力ファイルには、ucdStart と ucdShutdown の二つの NMP トラップの定義が含まれます。
その変換スクリプトは出力ファイルを上書きするのではなく、データを追加します。もし、既存の構成ファイルを完全に新しく再生成したい場合は、先に現在ある構成ファイルを削除してから、スクリプトを再度実行する必要があることに注意してください。
望ましい構成ファイルが作成されたら、一致トラップを解釈するのに使用する前に、それを /usr/local/groundwork/etc/snmp/snmptt.ini コントロールファイルに追加する必要があります。新しい構成ファイルをコントロールファイルに追加するには、テキストエディタで snmptt.ini を開き、ファイルの最後に向かって "[TrapFiles]" セクションを探し、そこと "END" ディレクティブまでの間のどこかに、その新しい構成ファイルのフルパスとファイル名を追加します。管理を容易にするため、新しい構成ファイルを、先に /usr/local/groundwork/etc/snmp/ ディレクトリにコピーしておくことを推奨します。
snmptt.ini ファイルを更新した後、以下のコマンドで snmptt デーモンをリスタートします: $ /etc/init.d/snmptt restart
上記の手順が完了したら、SNMPトラップ・トランスレータは、新たに定義された SNMP トラップの処理を開始し、GroundWork FoundationとNagiosに対して、正しいテキスト文字列と重大度レベルを生成するようになります。しかし、MIB ファイルが変換されない場合、手動での多少の調整が必要になるでしょう。
注意:ベンダー間でのインプリメンテーションの違いによって、いくつかの MIB は、MIB バリデータツールによって正当であると確認されないでしょう。MIB ファイルの問題の支援には GroundWork 社のサポートに連絡ください。
ほとんどの MIB ファイルは、多少、ある種のタイプのデータを他の MIB ファイルに依存しています。例えば、SNMP トラップは他の MIB ファイルで定義されている一般的なデータタイプを再利用しているかもしれませんし、その場合、そのトラップ定義はその MIB が MIB 変換ユーティリティで使えるようにしない限りは使用できないでしょう。
GroundWork Monitor は、いくつかの共通の MIB 依存を既に含んでいますので、ほとんどの場合、依存関係の問題は通告されないでしょう。例えば、前のセクションのキャプチャー画面で、MIB ファイルにいくつかの依存があるにもかかわらず、convert_mib.sh スクリプトが、UCD-SNMP-MIB.MIB ファイルを成功裏に処理することを示しています。しかし、これは GroundWork Monitor が依存する MIB を既に取り込んでいたので、変換ユーティリティが利用できたに過ぎません。
ひとつあるいはそれ以上の MIB 依存の欠落により、変換スクリプトが失敗した場合、あなたはどの MIB ファイルが欠けているかを判断し、それらをしかるべき場所にインストールする必要があります。これには、二つの方法のどちらか一方を行う必要があります。
最も簡単な方法は、MIB バリデーションツールを使って必要な MIB ファイルを判断し、追加しようとする MIB ファイルをアップロードすることです。そうすると MIB バリデータは、元の MIB で必要とされるすべての依存 MIB のリストを表示します。このツールを使うには、メインメニューから "Tools(ツール)"アイテムを選んで、トップのメニューバーから "MIB Validator(MIBバリデータ)"メニューをクリックします。MIB バリデータツールがロードされたら、検証したい MIB ファイルのパスを指定し、"Check(チェック)"ボタンをクリックします。上のポップアップ図に "UCD-SNMP-MIB.mib" というファイルを検証するために使用したこのツールを示します。
MIB ファイルが MIB バリデ-タ・ツール内で指定されていない何らかの依存関係を持っていた場合、それらは入力 MIB がチェックされた際に、リストアップされるでしょう。例えば、下図は、上記の場合の出力、つまり、UCD-SNMP-MIB.mib ファイルがSNMPv2-SMI MIB に依存すると言う表示を示します:
テキストエディタで開くことで、 MIB ファイルを調べることができます。依存関係は、"IMPORTS" という単語で始まり、インポートされるオブジェクトのリストが続くテキスト行で表され、そして "FROM" の節にソースMIBファイルの名前が続きます。例えば、Dell 社 PowerConnect-3248 スイッチの MIB ファイルの下記のテキストのブロックは、複数の従属する MIB を参照しています:
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, Integer32, IpAddress,
NOTIFICATION-TYPE, internet, Counter32
FROM SNMPv2-SMI
DisplayString, RowStatus, TruthValue
FROM SNMPv2-TC
EnabledStatus
FROM P-BRIDGE-MIB
BridgeId, Timeout, dot1dStpPortEntry, dot1dStpPort
FROM BRIDGE-MIB
PortList
FROM Q-BRIDGE-MIB
ifIndex
FROM IF-MIB;
上記の例では、その MIB ファイルは、SNMPv2-SMI、SNMPv2-TC、P-BRIDGE-MIB、BRIDGE-MIB、Q-BRIDGE-MIB、および IF-MIB に依存しています。それらの MIB ファイルは、元の MIB 内の SNMP トラップメッセージが snmptt によって変換できるようになる前に必要となります。
MIBの依存関係を判断すると、しかるべき MIB ファイルを見つけ出して、それらを GroundWork Monitor の MIB リポジトリに追加しなければなりません。
明確にするため、convert_mib.shスクリプトは、SNMPトラップ・トランスレータ・パッケージと共に提供される構成ファイルが作成されるとき、しかるべきオプションとコマンドライン・パラメータが使用されることを保証する /usr/local/groundwork/bin/snmpttconvertmib の Perl スクリプトのフロントエンドであることを理解することが重要です。しかし、snmpttconvertmib スクリプトは、標準 MIBデータをデコードするタスクのための Net-SNMP ソフトウェアパッケージと共に提供される /usr/local/groundwork/bin/snmptranslate ユーティリティを使用します。つまり、Net-SNMPソフトウェアパッケージは、トラップが最初にテキストの変換されるとき、依存する MIB を見つけることに最終的な責任を持ちます。
Net-SNMP ユーティリティのすべては、共通 MIBファイルのために共通のキャッシュディレクトリ、つまり、/usr/local/groundwork/share/snmp/mibs ディレクトリを使います。このディレクトリの中に格納されているどの MIBファイルでも、MIBデータをテキスト形式に変換し表示する目的で Net-SNMP ユーティリティが使用することができ、これには snmptt 構成ファイルが作成されるときに常に活用される一時的変換を含みます。
したがって、MIB依存が変換スクリプトに認識されるために、依存 MIBファイルは /usr/local/groundwork/share/snmp/mibs ディレクトリに追加されなければなりません。そのファイルがそのディレクトリにコピーされ(そして、しかるべきファイルのパーミッションが定義され)たら、変換スクリプトを再度呼ぶことができます。そしてトラップのテキストを作成するのにsnmptranslateユーティリティが最後に呼ばれた時、依存MIBファイルが見つけ出され、自動的に使用されるでしょう。
デフォルトでは、/usr/local/groundwork/share/snmp/mibs ディレクトリに数ダースの共通依存 MIBファイルが含まれています。それに加えて、 GroundWork Monitor はいくつか他の共通 MIBファイルを /usr/local/groundwork/share/mibs のディレクトリツリーの下 (これは Net-SNMP のキャッシュディレクトリとは異なります)に含んでおり、これらの MIBファイルは必要に応じて Net-SNMP キャッシュディレクトリにコピーすることができます。
MIBファイルが、GroundWork Monitor によって提供されない追加の依存を持つ場合、あなたはその装置のベンダーのサポートサイトや他のインターネットMIBリポジトリサイト上の依存MIBファイルを見つける必要があるかもしれません。
上述の Dell 社 PowerConnect-3248 スイッチの MIB の例を使って、その MIBファイルが SNMPv2-SMI、SNMPv2-TC、P-BRIDGE-MIB、BRIDGE-MIB、Q-BRIDGE-MIB、および IF-MIBに依存していることがいえます。そして、Net-SNMP キャッシュディレクトリがすでに SNMPv2-SMI、SNMPv2-TC と IF-MIB を含んでいますが、BRIDGE-MIB、P-BRIDGE-MIB と Q-BRIDGE-MIB のMIBファイルを含んでいません。しかし、それらのファイルは /usr/local/groundwork/share/mibs/ietf リポジトリの中には存在しません。つまり、それらは /usr/local/groundwork/share/snmp/mibs ディレクトリにコピーするだけでよく、そこで convert_mib.sh が次に実行されたらいつでも、それらは snmptranslate ユーティリティで使用できるようになります。
複数のネストレベルの依存がある場合があり、それにより、元々想定されたものより多くの MIBファイルを Net-SNMP キャッシュディレクトリにコピーする必要がある可能性に注意してください。例えば、Q-BRIDGE-MIB は RMON2-MIB に依存していて、それは、次に TOKEN-RING-RMON-MIBに依存します。上述の PowerConnect-3248 の MIBファイルをエラーなしに処理するため、それらすべてのMIBファイルが Net-SNMP キャッシュディレクトリに追加される必要があります。
多くのSNMP MIBファイルにさまざまのエラーが含まれています。それらの内いくつかは良性で、他は snmptt がそのMIBをどう翻訳するか判断できないほど十分に問題があるでしょう。後者の場合、異なるバージョンのMIBファイルを探すか、そのファイル自体を編集(これは極端な場合の例外とし以外は行うべきではありません - SNMP MIB 定義は非常に複雑な記述フォーマットを使用しており、悪い状態をもっと悪くすることが簡単だからです)する必要があるかもしれません。