Sun Java System Messaging Server 6 2005Q4 管理ガイド

付録 A SNMP サポート

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

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

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

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 8 および 9 と、Java Enterprise System が対応しているすべてのバージョンの Microsoft Windows が稼働しているプラットフォームでサポートされています。このほかのプラットフォームについては、今後のリリースで SNMP をサポートする予定です。Solaris での SNMP サポートは、Solaris のネイティブ SNMP テクノロジである Solstice Enterprise Agents (SEA) を利用しています。Solaris 8 システムに SEA をインストールする必要はありません。必要なランタイムライブラリはすでにインストールされています。

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

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

Messaging Server での SNMP の動作

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

図 A–1 SNMP の情報フロー

Solaris 8 で 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 を指定します。

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 を使用してください。

Unix プラットフォームにおけるほかの Sun Java System 製品との共存

SNMP サポートが提供されているほかの Netscape 製品または Sun Java System 製品では、プラットフォームのネイティブマスターエージェントを置き換えて SNMP サポートを有効にします。これらの Sun Java System 製品を Messaging Server と同じホストで実行し、両者を SNMP で監視する場合は、『Managing Servers with iPlanet Console 』の第 11 章の説明に従って Sun Java System Proxy SNMP Agent を設定します。これにより、Messaging Server SNMP サブエージェント (ネイティブ SNMP エージェント) がほかの Sun Java System 製品のネイティブではない Sun Java System SNMP サブエージェントと共存できるようになります。

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 クライアントでは、傾向の分析を行い、過去の傾向から急にそれた場合に警告を送信することができます。

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 変数は、拒否された受信接続の数ではなく、失敗したログイン試行の回数を示します。

applTable の使用法

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

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

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 秒が経過しています。

assocTable の使用法

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

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 メッセージファイルの数をカウントします。

mtaTable の使用法

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

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

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 メッセージファイルの数をカウントします。

mtaGroupTable の使用法

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

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

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

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

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

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 チャネルによって制御されているネットワーク接続を表していることになります。

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 の値をとり、そのチャネルのメッセージ配信中に発生した一時的または永久的なエラーの数を示します。

mtaGroupErrorTable の使用法

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