iPlanet Messaging Server 5.1 管理者ガイド

前へ目次索引次へ
iPlanet Messaging Server 5.1 管理者ガイド

付録 A SNMP サポート

iPlanet Messaging Server では、SNMP (Simple Network Management Protocol) を利用したシステムモニタ機能がサポートされています。Sun Net Manager や HP OpenView (本製品には含まれていません) などの SNMP クライアント (ネットワークマネージャとも呼ばれる) を使用すると、iPlanet Messaging Server の特定の部分をモニタできます。
この章では、Messaging Server に対する SNMP サポートを有効にする方法について説明します。また、SNMP から得られる情報の種類についても簡単に説明します。ただし、この章では、それらの情報を表示する方法については取り上げていません。SNMP クライアントを使って SNMP ベースの情報を表示する方法については、SNMP クライアントのマニュアルを参照してください。このマニュアルには、Messaging Server の SNMP 実装で使用できるデータの一部も紹介されています。MIB の詳細については、RFC 2788 および RFC 2789 を参照してください。
この章には、以下の項目があります。

SNMP の実装

Solaris 8 で iPlanet Messaging Server 用の SNMP サポートを設定する

SNMP クライアントからモニタする

UNIX 上での他の iPlanet 製品との共存

Messaging Server からの SNMP 情報

SNMP の実装

iPlanet 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 プラットフォームでのみサポートされています。今後のリリースでは、このほかのプラットフォームでもサポートされる予定です。Solaris の SNMP サポートには、ネイティブ Solaris SNMP テクノロジーである Solstice Enterprise Agents (SEA) が利用されています。SEA を Solaris 8 システムにインストールする必要はありません。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 で iPlanet 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 ポート番号
この設定は、後でポート番号にゼロを指定することで取り消すことができます。ゼロ (デフォルト設定) を指定すると、Messaging Server は、使用可能な任意の UDP ポートを自動的にサブエージェントに選択させます。
/etc/snmp/conf ディレクトリには、2 つの SNMP サブエージェント設定ファイルがあります。1 つは SNMP アクセスコントロール情報を含む ims.acl で、もう 1 つは SNMP MIB OID 登録情報を含む ims.reg です。
通常は、この 2 つのファイルを編集する必要はありません。Messaging Server によって提供される MIB は読み取り専用なので、ims.reg ファイルにポート番号を指定する必要はありません。このファイルにポート番号を指定した場合は、configutil ユーティリティでポート番号を設定した場合を除き、その番号が使用されます。configutil でポート番号を設定した場合は、そのポート番号がサブエージェントで使用されます。ファイルを編集した場合は、変更を反映させるために SNMP サブエージェントをいったん停止してから再起動する必要があります。
# stop-msg snmp
# start-msg snmp

SNMP クライアントからモニタする

RFC 2788 および RFC 2789 のベース OID は次のとおりです。
mib-2.27 = 1.3.6.1.2.1.27
mib-2.28 = 1.3.6.1.2.1.28
SNMP クライアントに上記の OID をポイントして、SNMP コミュニティに「パブリック」としてアクセスします。
使用中の SNMP クライアントに MIB のコピーを読み込みたい場合は、<server-root>/plugins/snmp ディレクトリにある ASCII 形式の MIB を利用できます。ファイル名は rfc2788.mib と rfc2789.mib です。これらの MIB を SNMP クライアントソフトウェアに読み込む方法については、SNMP クライアントソフトウェアのマニュアルを参照してください。これらの MIB で使用される SnmpAdminString データのタイプは、古いバージョンの SNMP クライアントでは認識されないことがあります。その場合には、同じディレクトリにある rfc2248.mib と rfc2249.mib を使用してください。

UNIX 上での他の iPlanet 製品との共存

Messaging Server を実行している UNIX プラットフォーム上で、SNMP をサポートしている他の Netscape 製品または iPlanet 製品を使用する場合は、そのプラットフォームのネイティブマスターエージェントを無効にする必要があります。これらの iPlanet 製品を Messaging Server と同じホストで実行し、両者を SNMP でモニタする場合は、『Managing Servers with Netscape Console』の第 7 章 (http://docs.iplanet.com/docs/manuals/console/42/html/7_snmp.htm#1024620) の説明に従って iPlanet Proxy SNMP Agent を設定します。これにより、Messaging Server SNMP サブエージェント (ネイティブ SNMP エージェント) が他の iPlanet 製品のネイティブでない iPlanet 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 情報によって、サイト固有のしきい値と監視の有効数値が得られます。優れた SNMP クライアントであれば、それらの値の傾向を分析し、過去の傾向から急にそれた場合に警告を出すことができます。

applTable

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

applTable:

applName.1¹ = mailsrv-1² MTA on mailsrv-1.west.sesta.com

applVersion.1 = 5.1

applUptime.1 = 7322³

applOperStatus.1 = up⁴

applLastChange.1 = 7422³

applInboundAssociations.1 = 5

applOutboundAssociations.1 = 2

applAccumulatedInboundAssociations.1 = 873

applAccumulatedOutboundAssociations.1 = 234

applLastInboundActivity.1 = 1054822³

applLastOutboundActivity.1 = 1054222³

applRejectedInboundAssociations.1 = 0⁵

applFailedOutboundAssociations.1 = 17

applDescription.1 = iPlanet Messaging Server 5.1

applName.2¹ = mailsrv-1 HTTP WebMail server on mailsrv-1.west.sesta.com

...

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

...

注:

上の例の.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 送信サーバの動作ステータスを判別するために Messaging Server は、各サーバに設定された TCP ポートを介して実際にこれらのサーバに接続し、適切なプロトコル (たとえば、HTTP では HEAD リクエストと応答、SMTP では HELO コマンドと応答など) を使用して簡単な処理を行います。これによって、各サーバのステータス (up (1)、down (2)、または congested (4) ) が決定されます。

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

MTA の場合、動作ステータスはジョブコントローラのステータスとなります。MTA が稼動中 (up) として表示された場合は、ジョブコントローラが稼動していることを意味します。また、MTA が停止中 (down) として表示された場合は、ジョブコントローラが停止していることを意味します。この 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²

assocApplicationProtocol.1.1¹ = applTCPProtoID.25³

assocApplicationType.1.1 = peerinitiator(3)⁴

assocDuration.1.1 = 400⁵

...

注:

.x.y という形式の接尾辞のうち、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²

mtaFailedConvertedMessages.1 = 0

mtaLoopsDetected.1 = 0³

注:

.x という形式の接尾辞は、アプリケーションに対応する 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¹ = autoreply²

...

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 = 0³

mtaGroupFailedConvertedMessages.1.3 = 0

mtaGroupCreationTime.1.3 = 0

mtaGroupHierarchy.1.3 = 0

mtaGroupOldestMessageId.1.3 = <01IFBV8AT8HYB4T6UA@red.iplanet.com>

mtaGroupLoopsDetected.1.3 = 0⁴

mtaGroupLastOutboundAssociationAttempt.1.3 = 1054222

注:

.x.y という形式の接尾辞のうち、x の部分はアプリケーションインデックス (applIndex) であり、applTable のどのアプリケーションがレポートされているのかを示しています。この場合は MTA です。y の部分は、レポートされているアプリケーションの各接続を調べる際に使用されます。この列挙型のインデックス (mtaGroupIndex) は、mtaGroupAssociationTable テーブルと mtaGroupErrorTable テーブルでも使われています。

レポート対象のチャネルの名前で、この場合は autoreply チャネルです。

変換チャネルは、ゼロ以外の値しかとりません。

現在チャネルのメッセージキューに保管されている .HELD メッセージファイルの数です。

mtaGroupTable の使用法

*Rejected* と *Failed* の傾向分析を行うと、チャネルの潜在的な問題を発見できる場合があります。
mtaGroupStoredVolume と mtaGroupStoredMessages の比が突然変化した場合は、キューに大きなジャンクメールがある可能性があります。
mtaGroupStoredMessages が急激に変化した合は、大量の迷惑メールが送信されているか、何らかの理由で配信に失敗している可能性があります。
mtaGroupOldestMessageStored の値が、配信不能メッセージの通知時間 (notices チャネルキーワード) に使用されている値よりも大きい場合は、差出人に戻すという処理でも対処できないメッセージがある可能性があります。差出人に戻す処理は毎晩夜間に行われるため、テストには mtaGroupOldestMessageStored > (最大時間 + 24 時間) を使用してください。
mtaGroupLoopsDetected がゼロよりも大きい場合は、メールループが発生しています。

mtaGroupAssociationTable

これは 3 次元のテーブルで、各エントリは assocTable に対するインデックスを表しています。このテーブルには、applTable 内の各 MTA に対して、2 次元のサブテーブルが 1 つずつ用意されています。この 2 次元のサブテーブルには、対応する MTA の各チャネルに対して 1 つの行があります。また、各チャネルに対し、そのチャネルが現在使用しているアクティブなネットワーク接続ごとにエントリが 1 つずつあります。エントリの値は assocTable へのインデックスです (エントリの値と、参照されている MTA の applIndex によってインデックスが付けられています)。この assocTable 内のエントリは、そのチャネルが保持しているネットワーク接続です。
簡単に言うと、mtaGroupAssociationTable テーブルは assocTable に示されているネットワーク接続を、mtaGroupTable の対応するチャネルに関連付けているものです。
以下に、mtaGroupAssociationTable (mib-2.28.3.1) のデータ例を示します。

mtaGroupAssociationTable:

mtaGroupAssociationIndex.1.3.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¹ = 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¹ = 0

...

mtaGroupInboundErrorCount.1.3.4000000¹ = 0

...

注:

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

mtaGroupErrorTable の使用法

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

前へ目次索引次へ
Copyright (c) 2001 Sun Microsystems, Inc. 既存部分の一部: Copyright (c) 2001 Netscape Communications Corp. All rights reserved.

最終更新日 2001 年 5 月 24 日