iPlanet Messaging Server 5.2 管理者ガイド: 付録 A SNMP サポート

前へ目次索引 DocHome 次へ

iPlanet Messaging Server 5.2 管理者ガイド

付録 A SNMP サポート

iPlanet Messaging Server では、SNMP (Simple Network Management Protocol) を利用したシステムモニタ機能がサポートされています。Sun Net Manager や HP OpenView などの SNMP クライアント (ネットワークマネージャとも呼ばれる) を使って、iPlanet Messaging Server の特定の部分をモニタすることができます。ただし、SNMP クライアントは本製品に付属していません。iPlanet Messaging Server のモニタの詳細は、第 15 章「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 サポートを設定する」

「Windows プラットフォーム用の 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 プラットフォームだけです。このほかのプラットフォームについては、今後のリリースで 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 で 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 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

Windows プラットフォーム用の SNMP を設定する

SNMP モニタ機能によって生じるオーバーヘッドは非常に小さなものですが、Messaging Server は SNMP サポートを無効にした状態で出荷されています。SNMP サポートを有効にするには、DOS プロンプトから以下のコマンドを発行します。
X:¥> server_root¥msg-instance¥configutil /o local.snmp.enable /v 1
X:¥> %SYSTEMROOT%¥SYSTEM32¥regsvr32.exe server_root¥bin¥msg¥imta¥bin¥madmand.dll
次に、Windows サービスユーティリティを使って SNMP サービスを再起動します。このサービスユーティリティは、Microsoft 管理コンソールと呼ばれることもあります。
Messaging Server SNMP サポートが動作するためには、Windows SNMP サービスが実行されていなければなりません。デフォルトでは、Windows SNMP サービスは Windows NT とともにインストールされません。Windows SNMP サービスは手作業でインストールする必要があります。
Windows NT で、以下のように SNMP サービスをインストールします。

コントロールパネルで、「ネットワーク」アイコンをマウスの右ボタンでクリックします。

「ネットワーク」ウィンドウで、「サービス」タブを選択します。

「サービス」ダイアログで、「追加」ボタンをクリックします。

「ネットワークサービスの選択」ポップアップウィンドウの「ネットワークサービス」リストボックスで、「SNMP サービス」を選択します。次に、「OK」ボタンをクリックします。

これで、Windows で SNMP サービスがインストールされます。インストールを完了するために Windows NT CD-ROM が必要になることもあります。
SNMP サービスのインストールの詳細は、Microsoft の Windows のマニュアルを参照してください。
Messaging Server の SNMP サポートを無効にするには、以下のコマンドを発行します。
X:¥> server_root¥msg-instance¥configutil /o local.snmp.enable /v 0
X:¥> %SYSTEMROOT%¥SYSTEM32¥regsvr32.exe /u server_root¥bin¥msg¥imta¥bin¥madmand.dll
次に、Windows サービスユーティリティから SNMP サービスを再起動します。
Windows プラットフォームでは、start-msg snmp コマンドと stop-msg snmp コマンドには効力はありません。Messaging Server の SNMP サポートは Windows SNMP サービス内で実行されます。SNMP サポートを開始または停止するには、Windows SNMP サービスを開始または停止する必要があります。

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

Unix プラットフォームにおける他の iPlanet 製品との共存

SNMP サポートが提供されている他の Netscape 製品または iPlanet 製品では、プラットフォームの原初マスターエージェントを置き換えて SNMP サポートを有効にします。これらの iPlanet 製品を Messaging Server と同じホストで実行し、両者を SNMP でモニタする場合は、『iPlanet 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 クライアントでは、傾向の分析を行い、過去の傾向から急にそれた場合に警告を送信することができます。

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

    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 送信サーバの動作ステータスは、それぞれのサーバに設定された 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²

    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 には、MTA の各チャネルが列挙されます。この列挙型のインデックス (mtaGroupIndex) は、mtaGroupAssociationTable テーブルと mtaGroupErrorTable テーブルでも使われています。

レポートされているチャネルの名前で、この場合は autoreply チャネルです。

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

現在チャネルのメッセージキューに保管されている .HELD メッセージファイルの数をカウントします。

mtaGroupTable の使用法

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

mtaGroupAssociationTable

これは 3 次元のテーブルで、各エントリは assocTable へのインデックスを表しています。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²

    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 に問題があるなどです。

前へ目次索引 DocHome 次へ
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最新更新日 2002 年 2 月 27 日