Sun Java System Messaging Server 6.3 管理ガイド

付録 A SNMP サポート

Messaging Server では、SNMP (Simple Network Management Protocol) を利用したシステム監視機能がサポートされています。Sun Net Manager や HP OpenView (本製品には付属していない) などの SNMP クライアント (「ネットワークマネージャー」とも呼ばれる) を使って、Messaging Server の特定の部分を監視することができます。Messaging Server の監視の詳細については、第 27 章「Messaging Server を監視する」を参照してください。

この付録では、Messaging Server の SNMP サポートを有効にする方法について説明します。また、SNMP から得られる情報の種類についても簡単に説明します。ただし、この付録では、それらの情報を表示する方法については取り上げていません。SNMP クライアントを使って SNMP ベースの情報を表示する方法については、SNMP クライアントのマニュアルを参照してください。このマニュアルには、Messaging Server の SNMP 実装で使用できるデータの一部も紹介されています。MIB の詳細については、RFC 2788 および RFC 2789 を参照してください。

この章には、次の節があります。

A.1 SNMP の実装

Messaging Server には、Network Services Monitoring MIB (RFC 2788) と Mail Monitoring MIB (RFC 2789) という 2 つの標準化された MIB が実装されています。Network Services Monitoring MIB は POP、IMAP、HTTP、SMTP などのサーバーのネットワークサービスを監視するためのものです。Mail Monitoring MIB は MTA を監視するためのものです。Mail Monitoring MIB では、各 MTA チャネルのアクティブ状態と、その履歴を監視することができます。アクティブ状態の監視では、現在キューに入っているメッセージと開いているネットワーク接続に焦点があてられます。たとえば、キュー内にあるメッセージの数や、開いているネットワーク接続のソース IP アドレスなどです。一方、履歴の監視からは、累積による統計が提供されます。たとえば、処理したメッセージの合計数や、受信接続の合計数などです。

注 –

Messaging Server SNMP 監視機能の詳細については、RFC 2788 および RFC 2789 を参照してください。

SNMP は、Solaris および Red Hat Linux を実行するプラットフォームでサポートされています。Solaris 9 オペレーティングシステム上の Messaging Server は、Solstice Enterprise Agents (SEA) を使用しています。Solaris 10 オペレーティングシステム以降の Messaging Server では、オープンソースの Net-SNMP 監視フレームワークがサポートされ、Solaris 9 OS の Solstice Enterprise Agents (SEA) テクノロジはレガシー (サポート期間終了) ステータスに格下げされました。また、Net-SNMP は Linux プラットフォームで広く使用されています。Messaging Server は、Solaris 10 以降および Linux プラットフォームで Net-SNMP ベースの SNMP サブエージェントを使用します。

Net-SNMP フレームワークの採用により、Messaging Server の SNMP サブエージェントは次の新機能を提供します。

SNMP バージョン 2c および 3 のサポート。このサポートは、Net-SNMP フレームワークによって提供されます。以前の SNMP テクノロジである Solstice Enterprise Agents では、SNMP バージョン 1 のみがサポートされていました。SNMP の新しい 2 つのバージョンの主な利点は、拡張されたセキュリティー機能とアクセス制御です。
「スタンドアロン」の SNMP エージェントとして実行されるようにサブエージェントを設定できます。これにより、同じシステム上で実行される各種の SNMP エージェントを特定する追加的な手段が提供されます。
同じシステム上で実行される Messaging Server の複数の「インスタンス」を同時に監視できます。このサポートは、前述の項目 2 または SNMP バージョン 3 の「コンテキスト名」を使用することによって提供されます。これにより、フェイルオーバークラスタ内での Messaging Server の SNMP 監視が可能になります。

Messaging Server SNMP サポートには、次のような制限があります。

Solaris 9 OS 上では、SNMP を通じて監視できる Messaging Server のインスタンスは、ホストコンピュータ当たり 1 つのみである。
SNMP サポートは、監視用のみである。SNMP 管理はサポートされていない。
SNMP トラップは実装されない (RFC 2788 に、トラップを使用しない同様の機能が記述されている)。

A.1.1 Messaging Server での SNMP の動作

Messaging Server SNMP プロセスは SNMP サブエージェントであり、起動時にプラットフォームのネイティブ SNMP マスターエージェントに自動的に登録されます。クライアントからの SNMP 要求は、マスターエージェントに送られます。次に Messaging Server 宛の要求は、マスターエージェントから Messaging Server サブエージェントプロセスに送られます。最後に Messaging Server サブエージェントプロセスによって要求が処理され、その応答がマスターエージェントを通じてクライアントに送られます。図 A–1 に、このプロセスを示します。

図 A–1 SNMP の情報フロー

A.2 Solaris 9 で Messaging Server 用の SNMP サポートを設定する

SNMP 監視機能によって生じるオーバーヘッドは非常に小さなものですが、Messaging Server は SNMP サポートを無効にした状態で出荷されています。SNMP サポートを有効にするには、次のコマンドを実行します。

# su user-id-for-ims
# configutil -o local.snmp.enable -v 1
# start-msg snmp

SNMP を有効にすると、パラメータを指定せずに start-msg コマンドを実行するだけで、SNMP サブエージェントプロセスがその他の Messaging Server プロセスとともに自動的に起動するようになります。

Messaging Server SNMP サブエージェントが動作するためには、Solaris のネイティブ SNMP マスターエージェントが実行されていなければなりません。Solaris のネイティブ SNMP マスターエージェントは snmpdx デーモンであり、通常これは Solaris の起動プロセスの一部として起動します。

要求を受信する UDP ポートは、SNMP サブエージェントによって自動的に選択されます。必要であれば、次のコマンドを使ってサブエージェントに固定の UDP ポートを割り当てることもできます。

# configutil -o local.snmp.port -v port-number

この設定は、あとでポート番号にゼロを指定することによって取り消すことができます。ゼロ (デフォルト) に指定すると、Messaging Server により、サブエージェントが使用可能な任意の UDP ポートを自動的に選択することが許可されます。

/etc/snmp/conf ディレクトリには、2 つの SNMP サブエージェント設定ファイルがあります。1 つは SNMP アクセス制御情報を含む ims.acl で、もう 1 つは SNMP MIB OID 登録情報を含む ims.reg です。

通常、これらのファイルを編集する必要はありません。Messaging Server によって提供される MIB は読み取り専用で、ims.reg ファイルでポート番号を指定する必要はありません。ポート番号を指定した場合は、configutil ユーティリティーでもポート番号を設定した場合を除き、ここで指定した値が使用されます。configutil でポート番号を設定した場合は、そのポート番号がサブエージェントで使用されます。これらのファイルを編集した場合は、変更を反映させるために SNMP サブエージェントをいったん停止してから再起動する必要があります。

# stop-msg snmp
# start-msg snmp

注 –

Messaging Server で SNMP サポートを有効にしている場合、Solaris 10 OS 上で発行される SNMP 経由のすべてのクエリーは、デフォルトポート 16161 に接続する必要があります。たとえば、オープンソースの SNMP ツール snmpwalk を使用して Messaging Server のネットワーク/メール統計を照会する場合は、オプション -p 16161 を指定します。

A.3 Solaris 10 OS 用の SNMP サポートを設定する

デフォルトでは、Messaging Server 内での SNMP 監視は無効になっています。このデフォルト設定は、デフォルトの Messaging Server 設定によって提供されるサービスの数を最小限に抑えることを目的としています。このデフォルト設定を、SNMP 監視を使用することでパフォーマンスに不利な条件が発生するという意味には解釈しないでください。実際には、Messaging Server の SNMP サポートによるリソース消費はごくわずかであり、Messaging Server への影響を最小限に抑えるように意図されています。以上のことから、当然ながら、Messaging Server の SNMP サポートを使用する前に、設定手順を 1 回実行する必要があります。さらに、Messaging Server などのサブエージェントを実行するためには、通常、プラットフォームの Net-SNMP マスターエージェントである snmpd のデフォルト設定を変更する必要があります。この変更については、次の節で取り上げます。

A.3.1 Net-SNMP の設定

Messaging Server の Net-SNMP ベースの SNMP サブエージェントは、AgentX プロトコルを使用してプラットフォームの SNMP マスターエージェントと通信します (RFC 2741)。Net-SNMP のマスターエージェントである snmpd は、AgentX プロトコルを使用できるように設定する必要があります。そのためには、プラットフォームの snmpd.conf ファイルに次の行が含まれていることを確認します。

master agentx

この行が含まれていない場合は、この行を追加し、snmpd デーモンを再起動します。このデーモンに SIGHUP シグナルを送信するだけでは十分ではありません。snmpd デーモンの再起動後、snmpd が AgentX 通信のために作成した UNIX ドメインソケットを探します。Solaris および Linux システムでは、このソケットはデフォルトで特殊ファイル /var/agentx/master として表示されますが、その場所と名前は snmpd.conf によって変更されている場合があります。

Solaris 10 OS の snmpd 設定を次に示します。

%cp /etc/sma/snmp/snmpd.conf /etc/sma/snmp/snmpd.conf.save
% cat >> /etc/sma/snmp/snmpd.conf
# Messaging Server's subagent requires the AgentX protocol
master agentx
^D
% cat >> /etc/sma/snmp/snmpd.conf
% ls -al /var/agentx/
srwxrwxrwx 1 root root 0 Aug 9 13:58 /var/agentx/master

また、Red Hat Enterprise Linux AS 3 システムのデフォルトの snmpd.conf ファイルは、「パブリック」の SNMP コミュニティーによって参照される可能性がある情報を制限しています。このため、その制限を削除するか、制限を緩和して Messaging Server のサブエージェントから提供される MIB を含める必要があります。初期のテストでは、後者をお勧めします。この作業は、次に示すように、「systemview」という名前のビューに OID サブツリーの mib-2.27 と mib-2.28 を追加することによって行います。実際の配備では、サイトごとに全体的なセキュリティーポリシーを考慮する必要があります。SNMP サブエージェントによって提供される情報は「読み取り専用」です。

% cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.save
% cat >>/etc/snmp/snmpd.conf
# Messaging Server's subagent requires the AgentX protocol
master agentx
# Messaging Server's subagent exports mib-2.27 and .28
# Add the mib-2.27 and .28 OID subtrees to the systemview
view systemview included .1.3.6.1.2.1.27
view systemview included .1.3.6.1.2.1.28
^D
% /sbin/service snmpd restart
% ls -al /var/agentx/master
srwxr-xr-x 1 root root 0 Aug 8 21:20 /var/agentx/master

また、SNMP v3 コンテキスト名を使用して、同じホストコンピュータ上で同時に実行されている複数の Messaging Server インスタンスの MIB を識別する場合は、SNMP v3 クエリーで使用する SNMP v3 ユーザー名およびパスワードを少なくとも 1 つ設定する必要があります。

A.3.2 Messaging Server サブエージェントの設定

Messaging Server の SNMP サブエージェントの基本的な操作については、サブエージェントを有効にし、手動の開始コマンドを 1 回発行するだけで済みます。その後は、Messaging Server が開始または終了するたびに、サブエージェントも同様に開始または終了します。この設定を有効にするのに必要なコマンドは、Solaris と Linux のどちらでも次のとおりです。

% configutil -o local.snmp.enable -v 1
% start-msg snmp

実行後、コマンド行から snmpwalk コマンドを実行することにより、サブエージェントをテストできます。Solaris および Linux に対応する例については、次のスクリーンショットを参照してください。rfc2248.txt ファイルと rfc2249.txt ファイルは、それぞれ Network Services MIB と MTA MIB のコピーです。Solaris システムでは、これらのファイルが NETWORK-SERVICES-MIB.txt および MTA-MIB.txt という名前で /etc/sma/snmp/mibs/ ディレクトリにも存在する場合があります。これらのファイルを snmpwalk ツールに指定しなくてもかまいませんが、指定すると、snmpwalk は個々の MIB 変数をオブジェクト識別子 (OID) の数値ではなく名前で出力します。

Solaris 上での基本テスト:

% D=/opt/SUNWmsgsr/examples/mibs /usr/sfw/bin/snmpwalk -v 1 -c public \
    -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.27
NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/SUNWmsgsr MTA on mail.siroe.com
...
% D=/opt/SUNWmsgsr/examples/mibs /usr/sfw/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.28
MTA-MIB::mtaReceivedMessages.1 = Counter32: 1452
MTA-MIB::mtaStoredMessages.1 = Gauge32: 21
...

Linux 上での基本テスト:

% export D=/opt/sun/messaging/examples/mibs
% /usr/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.27
NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/sun/messaging MTA on mail.siroe.com
...
% /usr/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.28
MTA-MIB::mtaReceivedMessages.1 = Counter32: 21278
MTA-MIB::mtaStoredMessages.1 = Gauge32: 7
...

A.3.3 スタンドアロン SNMP エージェントとしての実行

スタンドアロン SNMP エージェントとして実行されるように Messaging Server の SNMP サブエージェントを設定する場合は、最初にエージェントが SNMP 要求を待機する Ethernet インタフェースと UDP ポートを決定する必要があります。デフォルトでは、UDP ポート 161 を使用し、利用可能なすべての Ethernet インタフェースで待機します。ほとんどの場合、プラットフォームの SNMP マスターエージェントである snmpd を妨害しないようにポート番号を変更する必要があります。HA フェイルオーバーなど、状況によっては、Ethernet インタフェースも、利用可能なすべてのインタフェース (INADDR_ANY) から IP アドレスで識別される特定のインタフェースに変更する必要があります。Ethernet インタフェースと UDP ポートという 2 つの概念は、local.snmp.listenaddr オプションと local.snmp.port オプションによって制御されます。

Ethernet インタフェースと UPD ポートを選択したら、local.snmp.standalone オプションの値を 1 に設定し、サブエージェントを再起動するようにしてください。再起動後のサブエージェントは、snmpd やほかのサブエージェントとは独立した SNMP エージェントとして動作します。

たとえば、IP アドレスが 10.53.1.37 である Ethernet インタフェースの UDP ポート 9161 で待機するスタンドアロンエージェントとして実行するには、次に示すコマンドを発行します。

スタンドアロンエージェントとして実行するための設定:

% configutil -o local.snmp.port -v 9161
% configutil -o local.snmp.listenaddr -v 10.53.1.37
% configutil -o local.snmp.standalone -v 1
% stop-msg snmp
% start-msg snmp
% snmpwalk -v 1 -c public 10.53.1.37:9161 .
SNMPv2-SMI::mib-2.27.1.1.2.1 = STRING: "/opt/SUNWmsgsr MTA on mail.siroe.com"
...

A.3.4 複数の Messaging Server インスタンスの監視

ここでは、同じホストコンピュータ上で実行されている複数の Messaging Server インスタンスを監視する 2 つの方法について説明します。1 つはサブエージェントをスタンドアロンモードで実行する方法で、Messaging Server の個々のインスタンスがホストコンピュータ間を動的に移動する可能性がある高可用性フェイルオーバー (HA) 設定に適しています。もう 1 つは SNMP v3 コンテキスト名を使用する方法で、複数の Messaging Server インスタンスの場所が 1 つのシステムに限られており、SNMP 監視ソフトウェアによってポーリングされる IP アドレスの数を制限するのが望ましい場合 (たとえば、監視ソフトウェアのライセンスに IP アドレス単位で課金されるコンポーネントが含まれる場合など) に、ある程度のメリットがあります。この 2 つ目の方法は、HA フェイルオーバー設定にも使用できますが、その場合はスタンドアロンモードの方法と同じ数の IP アドレスをポーリングする必要があります。

A.3.5 高可用性フェイルオーバー用のスタンドアロンエージェントの使用

Messaging Server の SNMP 監視が必要な高可用性フェイルオーバー設定では、「A.3.3 スタンドアロン SNMP エージェントとしての実行」の説明に従って、Messaging Server の SNMP サブエージェントをスタンドアロンエージェントとして実行することをお勧めします。サブエージェントをスタンドアロンモードで実行する場合は、Messaging Server の各 HA インスタンスの local.snmp.listenaddr オプションをそのインスタンスのフェイルオーバー IP アドレスの値に設定するようにしてください。管理を簡単にするため、各インスタンスは同じ UDP ポートを使用するべきですが、各物理クラスタホスト上で実行されている snmpd デーモンが使用するポートとは異なるポートを使用するようにしてください。通常、これらのデーモンは UDP ポート 161 を使用するので、local.snmp.port オプションを使用して明示的に異なるポート番号を指定してください。

ここで推奨する方法に従って Messaging Server の SNMP サポートを設定すると、Messaging Server の各インスタンスがどの物理クラスタホスト上で実行されているかに関係なく、監視ステーションは各インスタンスのフェイルオーバー IP アドレスまたはホスト名によってインスタンスを監視できます。さらに、Messaging Server のスタンドアロン SNMP エージェントは、それぞれがそのインスタンス固有のフェイルオーバー IP アドレスによって識別される固有の仮想 Ethernet インタフェースでのみ待機するため、互いに競合しないことが保証されます。これらの仮想 Ethernet インタフェースは、HA フェイルオーバーフレームワークによって自動的に作成されます。UDP ポートが注意深く選択されているため、エージェントはクラスタ内のシステム上で実行されている snmpd デーモンと競合しません。

A.3.6 SNMP v3 コンテキスト名による複数インスタンスの識別

「A.3.3 スタンドアロン SNMP エージェントとしての実行」の説明に従ってスタンドアロンモードで Messaging Server の SNMP サポートを使用することによるマイナス面は特にありませんが、サイトによっては、同じシステム上で同時に実行されている複数の Messaging Server インスタンスを監視する機能を維持しながら、従来のサブエージェントモードを使用するのが望ましい場合があることがわかっています。たとえば、ライセンスモデルによってポーリングできる IP アドレスの数が制限される SNMP 監視システムの場合などです。この目的を達成するには、local.snmp.standalone を 0 に設定したままで Messaging Server の SNMP サブエージェントを実行し続けます。また、local.snmp.enablecontextname オプションに 0 以外の値を指定することにより、異なる SNMP v3 コンテキスト名を使用するように Messaging Server の各インスタンスを設定します。service.defaultdomain の値とは異なるコンテキスト名を使用する必要がある場合は、その名前を local.snmp.contextname オプションに設定します。Messaging Server の SNMP サブエージェントの各インスタンスは、再起動後、適切なコンテキスト名を含む SNMP v3 クエリーによって監視できます。同じシステム上で実行されている 2 つの Messaging Server インスタンスの MIB はそのインスタンスの SNMP v3 コンテキスト名によって識別されるため、MIB のオブジェクト識別子 (OID) の競合は発生しません。

A.3.7 Messaging Server の Net-SNMP ベースの SNMP サブエージェントオプション

次のオプションは、Messaging Server の Net-SNMP ベースの SNMP サブエージェントにのみ適用されます。このようなサブエージェントは、Solaris 10 以降および Linux プラットフォームで使用されます。次に示すオプションは、Solaris 9 以前のオペレーティングシステムを実行する Solaris プラットフォーム用に提供されていた旧バージョンの SNMP サブエージェントには適用されません。

次に示すオプションは、configutil のオプションです。したがって、オプションの値を調べるには、次の形式のコマンドを使用します。

% configutil -o option-name

option-name は、値を表示するオプションの名前です。オプションの値を設定または変更するには、次の形式のコマンドを使用します。

% configutil -o option-name -v option-value

option-value は、設定する値です。これらのオプションの変更を有効にするには、次のように再起動する必要があります。

% stop-msg snmp
% start-msg snmp

各オプションの説明とデフォルト値を次に示します。

表 A–1 SNMP サブエージェンのトオプション


オプション (デフォルト)	説明
local.snmp.enable (0)	Messaging Server の SNMP サブエージェントは、このオプションの値を `1` または `true` に指定した場合にのみ実行されます。その場合、Messaging Server は通常の起動およびシャットダウン手順の一環としてサブエージェントの停止と開始を自動的に実行します。このオプションは、デフォルトでは 0 に設定され、サブエージェントの実行を無効にします。サブエージェントを有効にする前に、プラットフォームのマスターエージェントが「A.3.3 スタンドアロン SNMP エージェントとしての実行」の説明に従って適切に設定されていることを確認してください。
local.snmp.standalone (0)	Messaging Server の SNMP サポートは、通常、SNMP サブエージェントとして実行され、プラットフォームの SNMP マスターエージェントである `snmpd` を介して SNMP 要求を受信します。この実行モードはデフォルトであり、このオプションの値を 0 または `false` に設定することによって選択されます。しかし、「A.3.3 スタンドアロン SNMP エージェントとしての実行」で説明したように、サブエージェントを「スタンドアロン」モードで実行することにより、`snmpd` とは独立した SNMP エージェントとしてサブエージェントを動作させることができます。サブエージェントをスタンドアロンモードで実行すると、1 つの SNMP エージェントになり、`local.snmp.listenaddr` オプションおよび `local.snmp.port` オプションでそれぞれ指定された Ethernet インタフェースおよび UDP ポートで SNMP 要求を直接待機します。このようにスタンドアロンモードで実行するには、このオプションの値に 1 または `TRUE` を指定します。スタンドアロンモードで実行しても、システム上で実行されているほかの SNMP マスターエージェントやサブエージェントを妨害することはありません。
local.snmp.listenaddr (INADDR_ANY)	スタンドアロンモードでの実行時に SNMP 要求を待機する Ethernet インタフェースのホスト名または IP アドレスです。デフォルトでは、利用可能なすべてのインタフェースで待機します。これは、値に `INADDR_ANY` を指定した場合に相当します。特定のインタフェースに関連付けられた IP アドレスまたはホスト名を指定することにより、そのインタフェースを選択できます。選択するインタフェースは、物理インタフェースと仮想インタフェースのどちらでもかまいません。 `local.snmp.standalone` に 0 または `FALSE` を指定すると、このオプションは無視されます。
local.snmp.cachettl (30)	キャッシュされた監視データの秒単位の有効時間 (TTL) です。このオプションは、サブエージェントが同じ監視データを報告し続け、そのデータを Messaging Server から取得した新しい情報で更新するまでの期間を制御します。メッセージループ情報を除き、デフォルトでは最大 30 秒間データがキャッシュされます。ループ情報は、`.HELD` ファイルのスキャンによって判定され、10 分ごとに 1 回だけ更新されます。その理由は、ディスク上のすべてのメッセージキューをスキャンする際のリソースコストです。サブエージェントは自身の監視データを継続的に更新しません。データは SNMP 要求の受信時にのみ更新され、キャッシュされたデータの有効期限が切れます。つまり、キャッシュされたデータの TTL が無効になります。TTL が 30 秒に設定され、SNMP 要求が 5 分ごとに 1 回だけ行われる場合、サブエージェントは SNMP 要求を受信した時点で Messaging Server から新しいデータを取得します。つまり、Messaging Server からのデータは 5 分ごとに 1 回だけ取得されます。一方、SNMP 要求が 10 秒間隔で行われた場合、サブエージェントは要求の一部に対して最大 29 秒間キャッシュされたデータで応答します。つまり、Messaging Server は 30 秒ごとに 1 回だけポーリングされます。
local.snmp.servertimeout (5)	サブエージェントは、監視対象サービスへの TCP 接続を実際に開き、プロトコル交換を実行することによって、各サービスの実行状態を判定します。このタイムアウト値は、秒単位で測定され、サブエージェントがプロトコル交換の各手順への応答を待機する期間を制御します。デフォルトでは、5 秒のタイムアウト値が使用されます。
local.snmp.directoryscan (1)	このオプションは、サブエージェントがディスク上のメッセージキュー内にある `.HELD` メッセージファイルおよびもっとも古いメッセージファイルのスキャンを実行するかどうかを制御するために使用されます。これらの情報は、MIB 変数の `mtaGroupLoopsDetected`、`mtaGroupOldestMessageStored`、および `mtaGroupOldestMessageId` に相当します。このオプションの値を 1 または `true` に設定すると、これらの情報のキャッシュが保持され、必要に応じて更新されます。キューに何千ものメッセージが格納され、これらの特定の MIB 変数に関心がないサイトでは、このオプションの値を 0 または `false` に設定することを検討するようにしてください。
local.snmp.enablecontextname (0)	サブエージェントには、自身の MIB を SNMP v3 コンテキスト名の下に登録する機能があります。MIB が登録されると、その MIB は SNMP 要求にコンテキスト名を指定する SNMP v3 クライアントからのみ要求されます。コンテキスト名を使用すると、複数の独立したサブエージェントが Network Services MIB と MTA MIB を同じ OID ツリーの下に (つまり、同じ SNMP マスターエージェントの下に) 登録できるようになります。詳細は、「A.3.4 複数の Messaging Server インスタンスの監視」を参照してください。 SNMP v3 コンテキスト名の使用を有効にするには、このオプションの値に 1 または `true` を指定します。このように指定すると、サブエージェントはそのコンテキスト名に `service.defaultdomain` オプションの値を使用するようにデフォルト設定されます。コンテキスト名にほかの値を使用するには、`local.snmp.contextname` オプションを使用します。
local.snmp.contextname (service.defaultdomain)	`local.snmp.enablecontextname` によって SNMP v3 コンテキスト名の使用が有効になっている場合は、このオプションを使用して、サブエージェントがその MIB に使用するコンテキスト名を明示的に設定できます。このオプションに指定する値は、文字列値であり、SNMP v3 コンテキスト名として使用するのに適した文字列である必要があります。`local.snmp.enablecontextname` の値が 0 または `false` である場合、このオプションは無視されます。

A.4 SNMP クライアントから監視する

RFC 2788 および RFC 2789 のベース OID は次のとおりです。

mib-2.27 = 1.3.6.1.2.10.27

mib-2.28 = 1.3.6.1.2.1.28

SNMP クライアントをこれら 2 つの OID にポイントし、SNMP コミュニティーに「パブリック」としてアクセスします。

お使いの SNMP クライアントに MIB のコピーを読み込みたい場合は、msg-svr-base/lib/config-templates ディレクトリにある ASCII 版の MIB を利用できます。ファイル名は rfc2788.mib と rfc2789.mib です。これらの MIB を SNMP クライアントソフトウェアに読み込む方法については、SNMP クライアントソフトウェアのマニュアルを参照してください。これらの MIB で使用される SnmpAdminString データタイプは、古いバージョンの SNMP クライアントで認識されないことがあります。その場合には、同じディレクトリにある同等のファイル、rfc2248.mib と rfc2249.mib を使用してください。

A.5 Messaging Server の SNMP の情報

この節では、SNMP を通じて提供される Messaging Server 情報について簡単に説明します。詳細は、RFC 2788 および RFC 2789 で個々の MIB テーブルを参照してください。RFC/MIB の用語では、メッセージングサービス (MTA、HTTP など) がアプリケーション (appl)、Messaging Server ネットワーク接続がアソシエーション (assoc)、および MTA チャネルが MTA グループ (mtaGroups) と呼ばれていることに注意してください。

Messaging Server の複数のインスタンスを同時に監視できるプラットフォームでは、applTable に複数の MTA とサーバーのセット、またほかのテーブルに複数の MTA が存在する場合があります。

注 –

MIB でレポートされる累積値 (配信済みメッセージの合計数や IMAP 接続の合計数など) は、再起動後にゼロにリセットされます。

各サイトには、監視に関してそれぞれ異なるしきい値と重要な値があります。うまく機能している SNMP クライアントでは、傾向の分析を行い、過去の傾向から急にそれた場合に警告を送信することができます。

A.5.1 applTable

applTable には、サーバー情報があります。これは 1 次元のテーブルであり、MTA の行が 1 つと、WebMail HTTP、IMAP、POP、SMTP、および SMTP 送信サーバーが有効の場合は、これらに対応する行がそれぞれ 1 つずつ含まれています。このテーブルには、バージョン情報、作動時間、現在の動作のステータス (up、down、congested)、現在の接続数、接続の累積合計数、およびその他の関連するデータがあります。

次に、applTable (mib-2.27.1.1) のデータ例を示します。

            
applTable:

    applName.1  = mailsrv-1  MTA on mailsrv-1.west.sesta.com      (1)
    applVersion.1 = 5.1
    applUptime.1 = 7322                         (2)
    applOperStatus.1 = up                       (3)
    applLastChange.1 = 7422                     (2)
    applInboundAssociations.1 =                 (5)
    applOutboundAssociations.1 =                (2)
    applAccumulatedInboundAssociations.1 = 873
    applAccumulatedOutboundAssociations.1 = 234
    applLastInboundActivity.1 = 1054822          (2)
    applLastOutboundActivity.1 = 1054222         (2)
    applRejectedInboundAssociations.1 = 0        (4)
    applFailedOutboundAssociations.1 = 17
    applDescription.1 = Sun Java System Messaging Server 6.1
    applName.2 1 = mailsrv-1 HTTP WebMail svr. mailsrv-1.sesta.com (1)
    ...
    applName.3 = mailsrv-1 IMAP server on mailsrv-1.west.sesta.com
    ...
    applName.4 = mailsrv-1 POP server on mailsrv-1.west.sesta.com
    ...
    applName.5 = mailsrv-1 SMTP server on mailsrv-1.west.sesta.com
    ...
    applName.6 = mailsrv-1 SMTP Submit server on mailsrv-1.west.sesta.com
    ...

注:

アプリケーション (.appl*) の .1、.2 などのサフィックスは行番号 (applIndex) です。applIndex の値は、MTA に対しては値 1、HTTP サーバーに対しては値 2 というように決められています。したがって、上の例では、テーブルの最初の行は MTA のデータを、2 番目のサフィックスがある行は HTTP サーバーのデータを提供しています。

等号に続く名前は、監視されている Messaging Server インスタンスの名前です。上の例の場合、インスタンス名は「mailsrv-1」です。
これらは SNMP TimeStamp 値で、イベント発生時の sysUpTime の値です。一方 sysUpTime は、SNMP マスターエージェントが起動してから経過した時間で、100 分の 1 秒を単位とする値です。
HTTP、IMAP、POP、SMTP、および SMTP 送信サーバーの動作ステータスは、それぞれのサーバーに設定された TCP ポートを通じて実際にこれらのサーバーに接続し、適切なプロトコル (たとえば、HTTP では HEAD 要求と応答、SMTP では HELO コマンドと応答など) で簡単な処理を行うことにより決定されます。この接続試行によって、各サーバーのステータス (up (1)、down (2)、または congested (4)) が決定されます。

これらの試みは、サーバーに対する通常の受信接続として認識され、各サーバーの applAccumulatedInboundAssociations MIB 変数に影響を与えます。

MTA の場合、動作ステータスはジョブコントローラのステータスとなります。MTA が稼働中として表示された場合は、ジョブコントローラが起動していることになります。また、MTA が非稼働中として表示された場合は、ジョブコントローラが停止していることになります。この MTA の動作ステータスは、MTA のサービスディスパッチャーのステータスには左右されません。MTA の動作ステータスは、up または down の値だけをとります。ジョブコントローラに「congested (混雑)」という概念があるとはいえ、MTA のステータスにこの状態が表示されることはありません。
HTTP、IMAP、および POP サーバーの場合、applRejectedInboundAssociations MIB 変数は、拒否された受信接続の数ではなく、失敗したログイン試行の回数を示します。

A.5.1.1 applTable の使用法

各サーバーを監視する上で重要なことは、リストされているアプリケーションのそれぞれについてサーバーステータス (applOperStatus) を監視するということです。

applLastInboundActivity に示されている最後の受信アクティビティーから長い時間が経過している場合は、何かの不具合が発生して接続が切断されている可能性があります。applOperStatus=2 (down) の場合は、監視中のサービスが稼働していません。applOperStatus=1 (up) の場合は、ほかに問題があることが考えられます。

A.5.2 assocTable

このテーブルには、MTA に対するネットワーク接続情報が表示されます。これは 2 次元のテーブルで、アクティブな各ネットワーク接続に関する情報があります。ほかのサーバーに関する接続情報は提供されません。

次に、applTable (mib-2.27.2.1) のデータ例を示します。

assocTable:

    assocRemoteApplication.1.1  = 129.146.198.167        (1)
    assocApplicationProtocol.1.1 = applTCPProtoID.25     (2)
    assocApplicationType.1.1 = peerinitiator(3)          (3)
    assocDuration.1.1 = 400                              (4)
...

注:

.x.y という形式のサフィックス (1.1) では、x はアプリケーションインデックス (applIndex) であり、applTable のどのアプリケーションがレポートされているかを示します。この場合は MTA です。y の部分には、レポートされているアプリケーションの各接続が列挙されます。

リモート SMTP クライアントのソース IP アドレスです。
ネットワーク接続で使用されているプロトコルを示す OID です。aplTCPProtoID は TCP プロトコルを意味します。.n は使用中の TCP ポートを表すサフィックスで、.25 は TCP ポート 25 で使用されているプロトコルである SMTP を示しています。
リモート SMTP クライアントがユーザーエージェント (UA) であるか、またはその他の MTA であるかを知ることはできません。このため、サブエージェントは常に peer-initiator をレポートし、ua-initiator をレポートすることはありません。
これは SNMP TimeInterval で、その単位は 100 分の 1 秒です。上の例では、接続を開始してから 4 秒が経過しています。

A.5.2.1 assocTable の使用法

このテーブルは、アクティブな問題を診断するために使用されます。たとえば、急に 200,000 個の受信接続が発生した場合など、このテーブルで接続元を確認することができます。

A.5.3 mtaTable

これは 1 次元のテーブルで、applTable の各 MTA に対してそれぞれ 1 つの行があります。各行には、mtaGroupTable で選択された変数に対し、その MTA 内のすべてのチャネル (グループと呼ばれる) における合計が示されます。

次に、applTable (mib-2.28.1.1) のデータ例を示します。

mtaTable:

    mtaReceivedMessages.1 = 172778        
    mtaStoredMessages.1 = 19
    mtaTransmittedMessages.1 = 172815
    mtaReceivedVolume.1 = 3817744
    mtaStoredVolume.1 = 34
    mtaTransmittedVolume.1 = 3791155
    mtaReceivedRecipients.1 = 190055
    mtaStoredRecipients.1 = 21
    mtaTransmittedRecipients.1 = 3791134
    mtaSuccessfulConvertedMessages.1 = 0 (1)
    mtaFailedConvertedMessages.1 = 0
    mtaLoopsDetected.1 = 0               (2)

注:

.x というサフィックス (.1) は、applTable におけるアプリケーションの行番号を示します。上の例の .1 は、このデータが applTable 内にある最初のアプリケーションのものであることを意味しています。つまり、このデータは MTA に関するものです。

変換チャネルは、ゼロ以外の値しかとりません。
現在 MTA のメッセージキューに保管されている .HELD メッセージファイルの数をカウントします。

A.5.3.1 mtaTable の使用法

mtaLoopsDetected がゼロでない場合は、メールのループ問題があります。問題を解決するために、MTA キューの.HELD ファイルを見つけ、診断します。

システムが変換チャネルを使ってウイルススキャンを行い、ウイルスに感染したメッセージを拒否した場合は、mtaSuccessfulConvertedMessages によって、感染したメッセージの数と、その他の変換失敗の数がレポートされます。

A.5.4 mtaGroupTable

この 2 次元のテーブルには、applTable 内の各 MTA に対するチャネル情報があります。この情報には、保存された (キュー内にある) メッセージ数や、配信されたメールメッセージ数などのデータが含まれています。各チャネルに対して保存されたメッセージの数 (mtaGroupStoredMessages) を監視することは、とても重要です。この値が通常の範囲を超えて大きくなった場合は、メールがキュー内にたまっています。

次に、mtaGroupTable (mib-2.28.2.1) のデータ例を示します。

mtaGroupTable:

mtaGroupName.1.1 = tcp_intranet                1
        ...
mtaGroupName.1.2 = ims-ms
        ...
mtaGroupName.1.3 = tcp_local
    mtaGroupDescription.1.3 = mailsrv-1 MTA tcp_local channel
    mtaGroupReceivedMessages.1.3 = 12154
    mtaGroupRejectedMessages.1.3 = 0
    mtaGroupStoredMessages.1.3 = 2
    mtaGroupTransmittedMessages.1.3 = 12148
    mtaGroupReceivedVolume.1.3 = 622135
    mtaGroupStoredVolume.1.3 = 7
    mtaGroupTransmittedVolume.1.3 = 619853
    mtaGroupReceivedRecipients.1.3 = 33087
    mtaGroupStoredRecipients.1.3 = 2
    mtaGroupTransmittedRecipients.1.3 = 32817
    mtaGroupOldestMessageStored.1.3 = 1103
    mtaGroupInboundAssociations.1.3 = 5
    mtaGroupOutboundAssociations.1.3 = 2
    mtaGroupAccumulatedInboundAssociations.1.3 = 150262
    mtaGroupAccumulatedOutboundAssociations.1.3 = 10970
    mtaGroupLastInboundActivity.1.3 = 1054822
    mtaGroupLastOutboundActivity.1.3 = 1054222
    mtaGroupRejectedInboundAssociations.1.3 = 0
    mtaGroupFailedOutboundAssociations.1.3 = 0
    mtaGroupInboundRejectionReason.1.3 =
    mtaGroupOutboundConnectFailureReason.1.3 =
    mtaGroupScheduledRetry.1.3 = 0
    mtaGroupMailProtocol.1.3 = applTCPProtoID.25
    mtaGroupSuccessfulConvertedMessages.1.3 = 03     2
    mtaGroupFailedConvertedMessages.1.3 = 0
    mtaGroupCreationTime.1.3 = 0
    mtaGroupHierarchy.1.3 = 0
    mtaGroupOldestMessageId.1.3 = <01IFBV8AT8HYB4T6UA@red.iplanet.com>
    mtaGroupLoopsDetected.1.3 = 0                    3
    mtaGroupLastOutboundAssociationAttempt.1.3 = 1054222

注:

.x.y という形式のサフィックス (例: 1.1、1.2、1.3) では、x はアプリケーションインデックス (applIndex) であり、applTable のどのアプリケーションがレポートされているかを示します。この場合は MTA です。y には、MTA の各チャネルが列挙されます。この列挙型のインデックス (mtaGroupIndex) は、mtaGroupAssociationTable テーブルと mtaGroupErrorTable テーブルでも使われています。

レポートされているチャネルの名前です。この場合は tcp_intranet チャネルです。
変換チャネルは、ゼロ以外の値しかとりません。
現在チャネルのメッセージキューに保管されている .HELD メッセージファイルの数をカウントします。

A.5.4.1 mtaGroupTable の使用法

*Rejected* と *Failed* の傾向分析を行うと、チャネルの潜在的な問題を発見できる場合があります。

mtaGroupStoredVolume と mtaGroupStoredMessages の比が突然変化した場合は、キュー付近に大きなジャンクメールがある可能性があります。

mtaGroupStoredMessages が急激に変化した合は、不特定多数宛のメールが送信されているか、何らかの理由で配信に失敗している可能性があります。

mtaGroupOldestMessageStored の値が、配信不能メッセージの通知時間 (notices チャネルキーワード) に使用されている値よりも大きい場合、これはバウンスでも処理できないメッセージを示している可能性があります。バウンスは毎日夜間に行われるため、テストには mtaGroupOldestMessageStored > (最大時間 + 24 時間) を使用してください。

mtaGroupLoopsDetected がゼロよりも大きい場合は、メールループが検出されています。

A.5.5 mtaGroupAssociationTable

これは 3 次元のテーブルで、各エントリは assocTable へのインデックスを表しています。applTable 内の各 MTA に対し、それぞれ 2 次元のサブテーブルがあります。applTable 内の各 MTA に対し、それぞれ 2 次元のサブテーブルがあります。この 2 次元のサブテーブルには、対応する MTA の各チャネルに対して 1 つの行があります。また、各チャネルに対し、そのチャネルが現在使用しているアクティブなネットワーク接続ごとにエントリが 1 つずつあります。エントリの値は assocTable へのインデックスです。エントリの値と、参照されている MTA の applIndex インデックスによってインデックスが付けられています。この assocTable 内のエントリは、そのチャネルが保持しているネットワーク接続です。

簡単に言うと、mtaGroupAssociationTable テーブルは assocTable に示されているネットワーク接続を、mtaGroupTable の対応するチャネルに関連付けているものです。

次に、mtaGroupAssociationTable (mib-2.28.3.1) のデータ例を示します。

mtaGroupAssociationTable:

    mtaGroupAssociationIndex.1.3.1 = 1 1
    mtaGroupAssociationIndex.1.3.2 = 2
    mtaGroupAssociationIndex.1.3.3 = 3
    mtaGroupAssociationIndex.1.3.4 = 4
    mtaGroupAssociationIndex.1.3.5 = 5
    mtaGroupAssociationIndex.1.3.6 = 6
    mtaGroupAssociationIndex.1.3.7 = 7

注:

.x.y.z という形式のサフィックスでは、x はアプリケーションインデックス (applIndex) であり、applTable 内のどのアプリケーションがレポートされているかを示します。この場合は MTA です。y は mtaGroupTable 内のどのチャネルがレポートされているかを示します。上の例で、3 は tcp_local チャネルを表しています。z には、チャネルへ向かって開かれたか、チャネルから開かれたアソシエーションが列挙されます。

この値は assocTable へのインデックスです。特に、x とこの値は、それぞれ applIndex の値と、assocTable への assocIndex インデックスになります。言い換えると、applIndex を無視した場合、assocTable の最初の行は tcp_local チャネルによって制御されているネットワーク接続を表していることになります。

A.5.6 mtaGroupErrorTable

これも 3 次元のテーブルで、メッセージの配信中に各 MTA の各チャネルで発生した一時的および永久的なエラーの数を示します。インデックス値が 4000000 のエントリは一時的なエラー、5000000 のエントリは永久的なエラーです。一時的なエラーの場合は、メッセージが再度キューに入れられ、あとで再び配信が試みられます。永久的なエラーの場合は、メッセージが拒否されるか、配信不能として戻されます。

次に、mtaGroupErrorTable (mib-2.28.5.1) のデータ例を示します。

mtaGroupErrorTable:

    mtaGroupInboundErrorCount.1.1.4000000 1 = 0
    mtaGroupInboundErrorCount.1.1.5000000 = 0
    mtaGroupInternalErrorCount.1.1.4000000 = 0
    mtaGroupInternalErrorCount.1.1.5000000 = 0
    mtaGroupOutboundErrorCount.1.1.4000000 = 0
    mtaGroupOutboundErrorCount.1.1.5000000 = 0

    mtaGroupInboundErrorCount.1.2.4000000 1 = 0
    ...

    mtaGroupInboundErrorCount.1.3.4000000 1 = 0
    ...

注:

.x.y.z という形式のサフィックスでは、x はアプリケーションインデックス (applIndex) であり、applTable 内のどのアプリケーションがレポートされているかを示します。この場合は MTA です。y は mtaGroupTable 内のどのチャネルがレポートされているかを示します。上の例では、1 により tcp_intranet チャネルが、2 により ims-ms チャネルが、3 により tcp_local チャネルが指定されています。z は 4000000 または 5000000 の値をとり、そのチャネルのメッセージ配信中に発生した一時的または永久的なエラーの数を示します。

A.5.6.1 mtaGroupErrorTable の使用法

エラー数が急激に増加した場合は、異常な配信問題があると考えられます。たとえば、tcp_ channel の値が急激に増加した場合は、DNS またはネットワークの問題が考えられます。ims_ms チャネルの値が急激に増加した場合は、メッセージストアへの配信の問題が考えられます。たとえば、パーティションに空き容量がない、または stored に問題があるなどです。