【ネットワーク監視入門】SNMP MIBの基本とmibdump活用ガイド

記事タイトルとURLをコピーする

みなさんこんにちは。マネージドサービス部MSS課の塩野(正)です。

今回は、New Relicのネットワーク監視の中で必ず理解しておかなければいけない概念的な話を取り上げてみました。 内容としてはそこまで難しくないものになりますが、設定の際に必ず目にするファイルを見て「お、おぅ・・・」とならないようにするための話と理解頂ければ幸いです。

目次

概要

ネットワーク運用・監視を始める人にとって、SNMPやMIBは不可欠なキーワードです。しかし言葉だけ聞くと難しそうに感じますが、仕組みを知れば活用の幅が大きく広がります。

本記事では、MIBの基本概念からmibdumpツールを使った変換方法、そして変換後のJSONファイル構造まで、MIB情報を効率的に活用するための知識を体系的に解説してみました。

SNMPとMIBの基本概念

SNMPとは

SNMP(Simple Network Management Protocol)は、ネットワーク機器の状態監視と管理を行うためのプロトコルです。SNMP は「監視する側(SNMPマネージャ)」と「監視される側(エージェント)」から構成される仕組みになっています。SNMP のバージョンによって内部構造が少し異なっており、v1やv2cの場合は下記のような形になります。

SNMP v3からセキュリティが大幅に強化されて認証情報を管理できるようになりました。SNMPv3では、USM(User-based Security Model)により認証と暗号化のレベルを選択できます:

  • noAuthNoPriv: 認証なし、暗号化なし
  • authNoPriv: 認証あり、暗号化なし
  • authPriv: 認証あり、暗号化あり

暗号化による通信保護は「authPriv」を選択した場合のみ有効になります。また、VACM(View-based Access Control Model)によるアクセス制御機能も提供されており、ユーザーごとに参照可能なMIB範囲を制限できます。

MIBとは

MIB(Management Information Base)は、機器の状態や性能を数値や文字列で管理する「情報のリスト」です。エージェントがMIBという情報データベースを持っており、機器ごとに異なる定義がなされています。

MIBは階層構造のデータベースで、監視項目をOID(Object Identifier)という識別子で管理します。これにより、ネットワーク機器の様々な情報を体系的に整理し、アクセスできるようになっています。

OIDの役割とMIBファイルの種類

OIDの階層構造

MIB内のデータは、OID(オブジェクトID)という番号の系列(例:「1.3.6.1.2.1.1.1.0」)で一意に管理されます。OIDはツリー状の構造で表現され、上位から下位の情報へ分岐していきます。

1 (iso)
└── 3 (org)
    └── 6 (dod)
        └── 1 (internet)
            └── 2 (mgmt)
                └── 1 (mib-2)
                    ├── 1 (system)
                    ├── 2 (interfaces)
                    └── 3 (at)

MIBファイルの種類

MIBファイルには主に2つの種類があります。

  1. 標準MIB: RFC等で定義された共通の監視項目
  2. 拡張(プライベート)MIB: メーカー独自の情報を管理

拡張MIBを使用することで、メーカー固有の機能や詳細な性能情報も監視対象に含められます。MIBファイルはASN.1という言語で記述され、複数ファイルに分割されることもあります。

SNMP監視における代表的なMIB値

機器監視では、MIBに定義されたOIDによって、CPUやメモリ、インタフェースの状態などの情報を取得します。以下は代表的なMIB値の例です。 実際に監視を行う際は、監視対象機器のマニュアルやメーカーサイト、または保守ベンダーより必要なMIBファイルや使いたい機器のOID一覧を入手してください。

システム情報系

  • sysDescr (1.3.6.1.2.1.1.1.0): システムの説明
  • sysUpTime (1.3.6.1.2.1.1.3.0): システム稼働時間
  • sysName (1.3.6.1.2.1.1.5.0): システム名

インタフェース情報系

  • ifDescr (1.3.6.1.2.1.2.2.1.2.X): インタフェース名(Xはインタフェースインデックス)
  • ifOperStatus (1.3.6.1.2.1.2.2.1.8.X): インタフェースの動作状態
  • ifInOctets (1.3.6.1.2.1.2.2.1.10.X): 受信バイト数(32bit)
  • ifHCInOctets (1.3.6.1.2.1.31.1.1.1.6.X): 受信バイト数(64bit、高速IF推奨)
  • ifSpeed (1.3.6.1.2.1.2.2.1.5.X): インタフェース速度(32bit、最大約4.29Gbps)
  • ifHighSpeed (1.3.6.1.2.1.31.1.1.1.15.X): インタフェース速度(Mbps単位、10G以上で使用)

高速インタフェース監視の注意点

高速なネットワークインタフェース(1Gbps以上)を監視する場合は、以下の点に注意が必要です:

  • 32bitカウンタの制限: ifInOctets/ifOutOctetsは32bitカウンタのため、高速インタフェースでは短時間でオーバーフローします
  • 64bitカウンタの使用: IF-MIBのifHCInOctets/ifHCOutOctets(64bit)の利用を推奨
  • 速度情報: 10Gbps以上のインタフェースではifHighSpeedを使用してください

OID構造の重要ポイント

  • スカラオブジェクト: 単一の値を持つオブジェクトで、OIDの末尾に必ず「.0」が付きます(例:sysName.0
  • テーブルオブジェクト: 複数の値を持つオブジェクトで、カラムOIDの末尾にインデックス番号が付きます(例:ifInOctets.10はインタフェースインデックス10の受信バイト数)

この構造を理解していないと、snmpgetでOIDを指定しても値が取得できない典型的な原因となります。

コマンド操作例(snmpget、snmpwalk)

SNMP監視の現場で使う代表的なコマンドは「snmpget」と「snmpwalk」です。

snmpget

指定したOIDの値を単体で取得するコマンドです。

snmpget -v 2c -c public 192.168.1.1 1.3.6.1.2.1.1.3.0

snmpwalk

指定したOID以下のすべての値を一覧取得するコマンドです。

# SNMPv2c
snmpwalk -v 2c -c public 192.168.1.1 1.3.6.1.2.1.2

# SNMPv3(認証+暗号化)
snmpwalk -v3 -l authPriv -u username -a SHA -A 'authpassword' -x AES -X 'privpassword' 192.168.1.1 1.3.6.1.2.1.1

パラメータの説明

  • -v: SNMPバージョン(1, 2c, 3)
  • -c: コミュニティ名(SNMPv1/v2cの場合)
  • -l: セキュリティレベル(SNMPv3の場合:noAuthNoPriv, authNoPriv, authPriv)
  • -u: ユーザー名(SNMPv3の場合)
  • -a: 認証プロトコル(SNMPv3の場合:SHA, MD5)
  • -A: 認証パスワード(SNMPv3の場合)
  • -x: 暗号化プロトコル(SNMPv3の場合:AES, DES)
  • -X: 暗号化パスワード(SNMPv3の場合)
  • 最後の引数: 対象のOID

これらのコマンドを使用することで、ネットワーク機器から直接SNMP情報を取得し、監視システムの動作確認や問題の切り分けが可能になります。

mibdumpによるMIBファイルの変換

変換の必要性

多くの監視・管理ツールでは、MIBファイルをツールに読み込ませるために変換が必要な場合があります。mibdumpというツールを使うことで、MIB(.myや.txtファイル)をJSON形式に変換することが可能です。これにより、MIB情報をプログラムや監視システムで扱いやすくなります。

インストール手順

前提条件

mibdumpはPythonで作成されたツールのため、事前にPython環境が必要です。

# Pythonバージョンの確認(Python 3.8以上推奨、3.9以上が理想)
python3 --version

# pipが使用可能か確認
pip3 --version

mibdumpのインストール

mibdumpはpysmiパッケージに含まれています。以下のコマンドでインストールできます。

# pysmiを使用してmibdumpをインストール
pip3 install pysmi

インストール後、mibdumpコマンドが使用可能になります。バージョンや動作確認は以下のコマンドで行えます。

# インストール確認
mibdump --help

変換手順

  1. MIBファイルの入手
    機器メーカーのサイトよりmibファイルを入手ください。

      # メーカーサイトからMIBファイルをダウンロード
      wget http://example.com/mibs/VENDOR-MIB.my
    
  2. mibdumpによる変換
    下記コマンドを使用して、mibファイルをjson形式に変換します。

      # 基本的な変換コマンド(VENDOR-MIBは変換対象のMIBモジュール名)
      mibdump --mib-source=file:///source_mib_file_dir --destination-format json --destination-directory /tmp VENDOR-MIB
    
      # 説明文も含めて出力する場合
      mibdump --mib-source=file:///source_mib_file_dir --destination-format json --destination-directory /tmp --generate-mib-texts VENDOR-MIB
    
  3. 変換結果の確認
    変換後、指定したディレクトリにJSON形式のファイルが生成されます(例:/tmp/VENDOR-MIB.json)。これらのファイルはJSON構造でMIB情報を格納しており、プログラムからの読み込みや人の目でみた内容の確認が容易になります。

変換後ファイルの構成と活用ポイント

ファイルの構造

mibdumpで変換されたJSONファイルは、MIB情報を構造化された形式に変換されます。変換後のJSONファイルには以下のような構造でMIB情報が格納されます。

JSONファイルの主要構成要素

mibdumpで変換されたJSONファイルは、MIBモジュール内の各シンボル(オブジェクト、通知、データ型定義など)をトップレベルのキーとして持ちます。各要素はclassnodetypeなどの属性により、その種類や役割を識別できる構造になっています。

通知系情報(NOTIFICATION-TYPE)

通知(Notification/Trap) JSONファイル内で"class": "notificationtype"として識別される要素です。SNMPトラップやインフォームで送信される通知の定義が含まれます。

通知の種類とバージョン別対応

SNMPバージョンによって通知の定義方法が異なります:

  • SNMPv1: Generic TrapとEnterprise Trapで定義
    • Generic Trap: 標準的な通知(coldStart、linkDown、linkUpなど)
    • Enterprise Trap: ベンダー固有の通知(機器特有のアラートやイベント)
  • SNMPv2c/v3: NOTIFICATION-TYPEで定義
    • 必須VarBindとしてsnmpTrapOID.0とsysUpTime.0が含まれる
    • より構造化された通知定義が可能
  • Notification Objects: 通知と一緒に送信される追加情報(発生時刻、影響を受けるポートなど)

通知のJSON構造
JSONファイル内では、通知は以下の要素で定義されます。

  • 通知名とOID
  • class属性("notificationtype")
  • 関連するオブジェクトのOIDリスト
  • 通知の説明文
  • ASN.1での構文定義

オブジェクト系情報(OBJECT-TYPE)

JSONファイル内で"class": "objecttype"として識別される要素です。実際の監視データや設定値を表現します。

1. モジュール識別情報(moduleidentity)
MIBモジュールの識別情報や依存関係を管理するセクションです("class": "moduleidentity"として識別)。 モジュール名、ルートOID、説明文、他のMIBからのインポート情報などが含まれます。これはOBJECT-TYPEとは別の要素です。

2. OIDツリー構造
各オブジェクトはOIDで階層的に管理され、オブジェクト名、データ型、アクセス権限、説明文などの属性情報とともに格納されます。

3. テーブル構造の表現
テーブルは下記のような階層的なOID構造で表現されます。

ifTable (テーブル層)
└── ifEntry (エントリ層)
    ├── ifIndex (カラム層)
    ├── ifDescr (カラム層)
    └── ifSpeed (カラム層)

テーブルの重要ポイント

  • table → entry → columnsの3層構造
  • indexでテーブルの主キーを定義
  • 各カラムは独立したOIDを持つ

4. メトリクス種別の分類
監視データの性質に応じた分類情報

  • カウンター系:累積値(ifInOctets, ifOutOctetsなど)
  • ゲージ系:瞬間値(ifSpeed, cpuUtilizationなど)
  • 設定値系:設定情報(ifAdminStatus, sysNameなど)

5. データ型定義

カスタムデータ型の定義情報が含まれます。基本データ型、値の範囲、制約条件、説明文などが定義されます。

6. 制約情報

各オブジェクトに対するサイズ制限、値の範囲、許可される値のリストなどの制約情報が格納されます。

まとめ

本記事では、SNMP/MIBの基本概念から、mibdumpツールを使ったMIBファイルのJSON変換、そして変換後のファイル構造まで幅広く解説してみました。

特に重要なポイントとして、MIBファイルは単なるテキストファイルではなく、ネットワーク機器の監視情報を体系的に管理する「設計図」であることを理解していただけましたでしょうか。OIDの階層構造によって情報が整理され、テーブル構造では「table → entry → columns」の3層で複雑なデータが表現されています。

mibdumpによるJSON変換することで、これらの情報をプログラムで扱いやすくすることができます。また変換後のJSONファイルは「通知系」と「オブジェクト系」に大別され、それぞれが監視システムの異なる側面を担います。ネットワーク機器の監視を行う際には、この「通知系」と「オブジェクト系」を使い分けることで、通知系は障害やアラートの管理に、オブジェクト系は定期的な性能監視に活用することができるでしょう。

この記事がどなたかのお役に立てれば幸いでございます。

◆ 塩野 正人
◆ マネージドサービス部 所属
◆ X(Twitter):@shioccii
◆ 過去記事はこちら

前職ではオンプレミスで仮想化基盤の構築や運用に従事。現在は運用部隊でNew Relicを使ってサービス改善に奮闘中。New Relic User Group運営。