SNMPについて、お話します。

ネットワーク監視では主に以下の3つの監視方法があります。

ネットワークに到達できるかを監視（ping）
特定サービスが稼働しているかを監視（ポート接続）
機器が正常に動作しているかを監視（SNMP）

これらは全て手動で行おうと思えばできますが、やりたくないですよね。

それを自動的にやってくれるのが監視ツールです。現代で使われている監視ツールは上記3つの機能は標準で備えているものがほとんどです。本記事ではそんな監視機能の中でも、3番の「SNMP」について深堀していきます。

Contents

SNMP について
- コミュニティ名
- バージョン
SNMP のもう少し細かいお話
- MIB と OID
主な OSS 監視ツールについて
監視の考え方

SNMP について

Simple Network Management Protocol の略です。RFC 1157 で定義されています。

SNMP はトラフィック量やエラーパケットの数、起動からの経過時間、CPU やメモリの使用状況といった詳細情報を集めることができます。SNMP マネージャと SNMP エージェントから構成され、基本的には SNMP マネージャからの要求にエージェントが応答することで情報が蓄積されていきます。

あらかじめ設定したシチュエーションになった場合に SNMP エージェントからマネージャに情報送信することも可能です。これを SNMP トラップといいます。

SNMP エージェントはネットワーク機器だとビルトインされていることが多いですし、例えば Windows Server だと役割と機能の追加からインストールし、Redhat 系の Linux だと yum でインストールしたりします。

SNMP マネージャは専用のソフトウェアを使います。これがいわゆる監視ツールと呼ばれるやつです。監視ツールは有償のものもありますが、OSS の監視ツールがよく利用されます。

コミュニティ名

SNMP マネージャはリクエストを送るだけで全ての SNMP エージェントの情報を取得できるわけではありません。SNMP エージェントに設定されている「コミュニティ名」を知っていなければ、情報を取得することは出来ません。SNMP パケットにはコミュニティ名が含まれています。

SNMP のコミュニティ名にはパスワードの側面も含まれているため、デフォルトの「public」のまま運用してはいけません。また、コミュニティ名は大文字/小文字を区別する点に注意してください。

参考サイト：SNMPコミュニティ名、そのデフォルトの価値は | @IT

また、SNMP エージェントではコミュニティ名に対して Read/Write を設定しなければなりません。要は MIB に対するアクセス権限です。コミュニティに Write が許可されていた場合、例えば特定インタフェースをダウンさせたり、機器自体をシャットダウンさせたりすることができます。

監視目的の場合、Read モードのみが使われることが多いです。

参考サイト：
【図解】SNMPの仕組み～利用ポート,監視方法(マネージャのMIBポーリング/trap受信),tcp/udp,writeの実装例〜 | SEの道標
SNMP – community / version | ネットワークエンジニアとして

バージョン

SNMPのバージョンには、正確には「SNMPv1、SNMPv2、SNMPv2c、SNMPv3」の4つのバージョンがあります。しかし「SNMPv2」は、ほぼ使用されることなく「SNMPv2c」へ移行したことから、多くのネットワーク製品でサポートしているSNMPバージョンは「SNMPv1、SNMPv2c、SNMPv3」の3つです。

SNMP – community / version | ネットワークエンジニアとしてより引用

それぞれのバージョンの違いは以下のとおりです。

SNMP バージョン	RFC	説明
SNMPv1	RFC 1157	SNMPコミュニティによる平文認証。SNMPトラップにおける再送確認なし。
SNMPv2c	RFC 1901	SNMPコミュニティによる平文認証。SNMPトラップにおける再送確認あり。
SNMPv3	RFC 2273~ 5	ユーザ単位の暗号化されたパスワード認証。SNMPトラップにおける再送確認あり。

推奨はv3ですが、v2cが広く使用されています。SNMPv1とSNMPv2cに互換性があることもあり、現在でもSNMPv1が使用されている環境もよくみかけます。

ただし、SNMPv1 および SNMPv2c は SNMP パケットを全く暗号化せずに平文で流すため、セキュリティ的に非常に脆弱であることを理解しなくてはなりません。唯一のセキュリティの砦はコミュニティ名のみです。まあ SNMP パケットにコミュニティ名も含まれているのでアレですが。なので、「SNMP エージェント側で Read Only に設定する」「特定 IP からのポーリングのみ許可する」などの最低限の対策は必要です。

SNMPv2c から登場した「INFORM」

実は、SNMPv2c と SNMPv3 にはトラップと似た機能で「INFORM」というものが実装されています。例えばアライドテレシスの CentreCom x210 の場合、通知メッセージを「TRAP形式/InformRequest形式」で選択できます。

TRAP との違いは、INFORM は SNMPマネージャからの応答を要求します。そのため，応答の有無でインフォームリクエストの到達を確認できます。これによって，ネットワークの輻輳などに対してもインフォームリクエストの再送で対応できます。

SNMPv1 と SNMPv2c の最大の違いと言える機能ですが、SNMP マネージャも INFORM に対応している必要があります。

参考サイト：AlaxalA コンフィグレーションガイド Vol.2

SNMP のもう少し細かいお話

改めてですが、SNMP ではマネージャがエージェントから管理情報を集める方法として以下の2つがあります。

マネージャーがエージェントに対して定期的にリクエストを送り、エージェントからレスポンスが返ってくる（ポーリング）
エージェントがマネージャに対して自発的に発信する（トラップ）

トラフィック情報などの管理情報は通常ポーリングで収集します。一方トラップはトラブルなどが起こったことで大至急マネージャに情報を伝えるために使われます。

ポート番号

SNMP は機器にかかる負荷を考え、UDP が利用されます。使用されるポート番号は以下のとおりです。

ポーリング：エージェントの「161番」宛

トラップ：マネージャの「162番」宛

SNMP では、基本的に以下の5つのコマンドを駆使して対象機器と情報をやり取りします。

SNMPメッセージ	送信側	意味
Get Request	SNMP マネージャ	SNMP エージェントから得たい情報を、OID を指定して要求
GetNext Request	SNMP マネージャ	直前に指定した OID の次の OID を指定して要求
Set Request	SNMP マネージャ	SNMP エージェントの設定変更を行いたい場合、OID を指定して要求
Get Response	SNMP エージェント	SNMP マネージャから要求された OID に対して、値を挿入して返信
TRAP	SNMP エージェント	SNMP エージェントが機器の状態に変化があった場合、自発的に送信

上記表に記載があるように情報を送受信する際は「OID」を指定します。

MIB と OID

MIB（Management Information Base）と OID（Object ID）について紹介します。

MIB とは SNMP の管理情報のフォーマットのことです。MIB のフォーマットはツリー構造になっており、RFC1213 で定義されています。また、MIB に則り保持しているデータ(データベース)ファイルそのものを MIB と言ったりもします。

MIB のツリー構造の各ノードには ID が割り当てられており、それらを並べることで OID と呼ばれる識別子になります。例えばホスト名（sysName）の格納場所は「.1.3.6.1.2.1.1.5」というように OID で表現可能です。

SNMP マネージャと SNMP エージェントで共通する MIB というフォーマットがあるからこそ、5つのコマンドにあったようにマネージャは「この OID の情報をくれ」といった要求ができます。

MIB のダウンロード

「MIB をダウンロードする必要がある」なんて言葉があります。MIB のフォーマットは共通のはずだし、MIB のファイルをダウンロードする？などと思ってしまいますが、実は違います。

MIB には「標準 MIB」と「拡張 MIB」と呼ばれるものがあり、要は共通フォーマット（OIDと紐づく情報が固定されている）が「標準 MIB」。ベンダが独自の情報を格納できる（OID に紐づけられる）部分が「拡張 MIB」となります。

MIB（Management Information Base） | ITBOOK より引用

つまり「MIB をダウンロードする」とは、「拡張 MIB の OID 情報をダウンロードする」と言い換えることができます。

拡張 MIB を利用しているエージェントは当然専用エージェントになるので、専用マネージャがあるはずです。そのマネージャは拡張 MIB の情報を通常持っているはずですが、なんらかの事情（バージョンが古いなど）で持っていない場合に MIB をダウンロードします。

主な OSS 監視ツールについて

監視ツールの監視の種類は、トラフィック量といったリソースの利用状況を見る「性能監視」と、死活/障害を監視する「障害監視」の2つに大別できます。

これから紹介する各 OSS の監視ツールにはそれぞれ強みと弱みがあり、下図のように表現されることがあります。

「日経ITエンジニアスクールネットワーク監視最強の指南書」より引用

これらの監視ツールの中で今圧倒的に人気があるのが「Zabbix」です。これは Google トレンドで検索数を比較すると一目瞭然ですし、書籍、イベントの状況を鑑みても断言できます。

2019年8月末時点でのGoogleトレンドの結果

Zabbix（ザビックス）

性能監視と障害監視の両方の機能を備えている為、「統合監視ツール」と呼ばれることがあります。Zabbix エージェントという専用のエージェントをインストールして情報を収集します。

Zabbix エージェントをインストールできないネットワーク機器などは、SNMP エージェント機能があれば SNMP による監視が可能です。SNMP エージェント機能がなくても ping による死活監視やポート監視ができます。

Hinemos（ヒネモス）

独立行政法人情報処理推進機構（IPA）が推進する平成16年度オープンソースソフトウェア活用基盤整備事業の1つである「分散ファシリティ統合マネージャの開発」の委託を受け、NTTデータが開発した監視ツールです。

基本的な機能は無料ですが、クラウドとの連携などの一部機能が有料です。国内ベンダが開発しているため日本語の情報が多いのが特徴といえます。

Nagios（ナギオス）

歴史が長く、広く利用されていた監視ツールです。障害監視に向きます。過去に取得した情報はデータベースではなくファイルに記録するため検索が困難です。また、保存するのは障害履歴だけなので過去のトラフィック量を参照するといった用途は不向きです。

Cacti（カクタイ）

SNMP エージェント機能を備えたサーバやネットワーク機器の性能監視に向く監視ツールです。Zabbix のように専用エージェントは存在しません。トラフィック量やリソースの使用状況をグラフで表示可能で、導入や設定が容易なのも特徴の一つです。

ただし、障害監視の機能はほとんどなく、例えば障害発生時にメール通報を行う機能は標準で備えておらず、別途プラグインが必要となります。また、専用エージェントが存在しないためサーバで稼働するアプリケーションの詳細などの監視はできません。

MRTG

Multi Router Traffic Grapher の略。歴史が長く、ネットワーク監視ツールの代名詞的存在だったが、近年登場した監視ツールに比べると機能的に劣り、インストールや設定の手間もかかります。

Munin（ムニン）

あまり人気がありません。トラフィック量などの性能監視に向き、見やすいグラフを容易に作成できます。Cacti に似ていますが、そちらより使いやすいという声もあります。

監視の考え方

これらの監視ツールを導入することで監視を行うことが可能になるわけですが、監視設定の考え方を記載します。

監視項目を統一する必要は無い

監視をするうえで、監視対象の項目を統一する必要はありません。監視対象ごとに重要度があるはずなので、重要度のより高いものにリソースを費やした方が健全です。そのため、「重要度が高くない機器は ping での死活監視で十分」という考えも十分にあり得ます。こうすることでどうでもいい通報で重要な通報が埋もれてしまうことも防ぎます。