第 22 章 Messaging Server をモニターする

一般的に、十分に計画され的確に設定されたサーバーは、管理者の手を煩わすことなく動作を続けます。したがって、管理者の役割は、サーバーが問題の兆候を示していないか、モニターすることです。この章では、Messaging Server のモニター機能について説明します。この章には、以下の節があります。

自動モニターと自動再起動

Messaging Server では、サービスを透過的にモニターする方法と、サービスに障害が発生したり、応答しなくなった場合 (サービスがハングまたはフリーズした場合) にサービスを自動的に再起動する機能が提供されています。この機能ですべてのメッセージストア、MTA、および MMP サービス (IMAP、POP、HTTP、ジョブコントローラ、ディスパッチャ、MMP サーバーなど) をモニターできます。この機能は、ENS、SMS、LMTP、TCP/SNMP サーバーなどのほかのサービスはモニターしません (LMTP および TCP/SNMP はジョブコントローラでモニターされる)。詳細は、「障害が発生したサービスや応答がないサービスの自動再起動」を参照してください。

また、この機能によって次に示すログファイル msg_svr_base/data/log/watcher が生成されます。このログファイルにはすべてのサーバーの起動と停止が記録されます。この記録は、システムの状態をモニターするために非常に重要です。

毎日のモニター作業

毎日の実施を必要とする作業のうち、特に重要なものは、ポストマスターメールのチェック、ログファイルのモニター、およびstored ユーティリティの設定です。これらの作業について、以降で説明します。

ポストマスターメールをチェックする

Messaging Server には、ポストマスター電子メール用に設定されている定義済み管理メーリングリストがあります。このメーリングリストに含まれているユーザーは、ポストマスター宛に送信されたメールを自動的に受信します。

ポストマスターメールのルールは RFC822 に定義されています。RFC822 では、すべての電子メールサイトでポストマスターという名前のユーザーまたはメーリングリスト宛に送信されたメールを受け取り、このアドレスに送信されたメールを実際のユーザーに配信することを要求しています。postmaster@host.domain に送られるすべてのメッセージは、ポストマスターアカウントまたはメーリングリストに送られます。

通常、ユーザーは、ポストマスターアドレス宛に自分のメールサービスに関する電子メールを送信します。ポストマスターは、たとえば、ローカルユーザーからはサーバー応答時間に関するメールを受信し、ほかのサーバー管理者からはサーバーへのメール送信時に発生した問題に関するメールを受信します。ポストマスターメールは毎日チェックする必要があります。

また、ポストマスターアドレスに特定のエラーメッセージを送信するようにサーバーを設定することもできます。たとえば、MTA がメッセージをルーティングまたは配信できないときは、ポストマスターアドレスに送信される電子メールによってそのことを知ることができます。また、ポストマスターに例外状態の警告 (ディスク容量の低下やサーバー応答の不良) を送ることもできます。

ログファイルをモニターおよび管理する

Messaging Server は、サポートしている主なプロトコル (SMTP、IMAP、POP、HTTP) またはサービスごとに一連のログファイルを作成します。ログファイルは、msg_svr_base/data/log にあります。ログファイルは定期的にモニターする必要があり、サーバーに問題がある場合は特に必要です。

ログ記録はサーバーパフォーマンスに影響することがあります。より詳細なログ記録を指定するほど、一定期間にログファイルが多くのディスク容量を占有することになります。効果的に定義する必要がありますが、現実的なログローテーション、有効期間、サーバーのバックアップポリシーなどを考慮する必要があります。サーバーのログポリシーの定義の詳細については、第 20 章「ログ記録とログ解析」を参照してください。

stored ユーティリティを設定する

stored ユーティリティは、以下のような、サーバーの自動モニターおよび管理を実行します。

stored ユーティリティは、毎日深夜 12 時に自動的にクリーンアップと (有効期限による) 失効の操作を行います。詳細は、「stored」を参照してください。

システムのパフォーマンスをモニターする

この章では、Messaging Server のモニターリングの機能に注目しています。ただし、サーバーが動作しているシステムも、同時にモニターすることが必要です。適切に設定されたサーバーであっても、設定が適切ではないシステム上では、本来の性能を発揮しないことがあるからです。また、サーバーエラーの発生は、ハードウェアの処理能力がメールシステムの動作には十分ではない場合もあります。この章では、システムパフォーマンスのモニターの詳細についてすべて説明しているわけではありません。これらの手順の多くはプラットフォーム固有のものであり、プラットフォーム固有のシステムのマニュアルを参照することが必要になる場合もあります。パフォーマンスをモニターする手順を以下に示します。

終端間メッセージ配信時間をモニターする

電子メールは時間どおりに配信する必要があります。これがサービス契約の要件になっていることもあります。また、メールをできるだけ速く配信することは良いポリシーでもあります。終端間の時間が遅いことは、多くの事柄を示している可能性があります。たとえば、サーバーが正しく作動していない、1 日の特定の時間にメッセージが処理不能になる、既存のハードウェアリソースの容量を超えている、などです。

終端間メッセージ配信時間の不良の兆候

終端間メッセージ配信時間をモニターするには

ディスク容量をモニターする

ディスクの空き容量の不足は、メールサーバーで発生する問題や故障のうち、特に頻繁におきる原因の 1 つです。MTA キューやメッセージストアへ書き込むとき、そのための容量が不足していると、メールサーバーにエラーが発生します。さらに、ログファイルをモニターおよびクリーンアップしないと、ログファイルが制御できないほど大きくなり、ディスク容量を使い果たすことがあります。

stored のクリーンアップ機能が失敗し、削除されたメッセージがメッセージストアから消去されていないと、ディスク容量が急激に不足することがあります。MTA メッセージキューが大きくなりすぎたり、メッセージストアが利用可能なディスク容量より大きくなったり、モニターしていないログファイルが制御できないほど大きくなったりすることも、ディスク容量の低下を招きます。ログファイルには、LDAP、MTA、および Message Access など、多数のものがあり、それらの各ログファイルは別のディスクに保存することができることに注意してください。

ディスク容量に関する問題の兆候

容量の低下によって発生する兆候は、ディスクやパーティションによって異なります。MTA キューがオーバーフローして SMTP 接続を拒否したり、メッセージが ims_master キューに残されたままでメッセージストアに配信されなくなったり、ログファイルがオーバーフローすることがあります。

ディスク容量をモニターするには

システムの構成に従って、さまざまなディスクやパーティションをモニターする必要があります。たとえば、MTA キューが 1 つのディスクやパーティション上にあり、メッセージストアが別の場所にあり、ログファイルがさらに別の場所にあるとします。この場合、それらの容量のそれぞれをモニターする必要があり、その容量をモニターする方法は異なることがあります。

メッセージストアをモニターする

メッセージストアのディスク容量は、75% を超えないようにすることをお勧めします。メッセージストアのディスク使用量をモニターするには、configutil ユーティリティを使用して以下の警告属性を設定します。

これらのパラメータを設定することによって、システムがディスク容量をモニターする頻度と、どのような状況で警告を送信するかを指定することができます。たとえば、システムがディスク容量を 600 秒毎にモニターするようにするには、次のコマンドを指定します。

使用可能なディスク容量が 20% を下回ったら常に警告を受け取るようにするには、次のコマンドを指定します。

これらのパラメータの詳細については、表 22-1 を参照してください。

MTA キューとログ領域をモニターする

MTA キューのディスクおよびログ領域のディスク使用量をモニターする必要があります。

CPU 使用状況をモニターする

CPU 使用状況が高い場合は、使用状況のレベルに対して CPU 容量が不足しているか、または適切なサイクルより多くの CPU サイクルを使用しているプロセスがあることを示しています。

CPU 使用状況に関する問題の兆候

システムの応答が悪く、ユーザーのログインに時間がかかり、配信速度が遅くなります。

CPU 使用状況をモニターするには

CPU 使用状況のモニターは、プラットフォーム固有のタスクです。関連するプラットフォームのマニュアルを参照してください。

MTA をモニターする

メッセージキューのサイズをモニターする

メッセージキューが過度に大きくなる場合は、メッセージが配信されていない、配信が遅延されている、あるいは入るのが速すぎてシステムがメッセージを配信できないことを示していることがあります。これは、膨大なメッセージがシステムに送られるサービス拒否攻撃に遭っている、ジョブコントローラが実行されていないなど、さまざまな原因によって発生します。

メッセージキューに関する問題の兆候

メッセージキューのサイズをモニターするには

メッセージキューをモニターする最良の方法は、imsimta qm を使用することです。「imsimta qm counters」を参照してください。

キューディレクトリ (msg_svr_base/data/queue/) 内のファイルの数をモニターすることもできます。ファイルの数はサイト固有であるので、「多すぎる」ものを見つけるための基準を作る必要があります。これは、キューファイルのサイズを 2 週間以上記録して、おおよその平均をとることによって行います。

配信エラーの頻度をモニターする

配信エラーは、外部サイトへのメッセージの配信試行のエラーです。配信エラーの頻度の大幅な増加は、DNS サーバーの故障や、接続への応答時のリモートサーバーのタイムアウトなど、ネットワークに関する何らかの問題の兆候です。

配信エラーの頻度に関する問題の兆候

表面的な問題の兆候はありません。多数の Q レコードは、mail.log_current に現れます。

配信エラーの頻度をモニターするには

配信エラーは、ログエントリコード Q とともに MTA ログに記録されます。msg_svr_base/data/log/mail.log_current ファイル内のレコードを確認します。

mail.log:06-Oct-2003 00:24:03.66 501d.0b.9 ims-ms Q 5 durai.balusamy@Sun.COM rfc822;durai.balusamy@Sun.COM durai@ims-ms-daemon <00ce01c38bda$c7e2b240$6501a8c0@guindy> Mailbox is busy

受信 SMTP 接続をモニターする

指定した IP アドレスからの受信用 SMTP 接続の数が異常に増加した場合は、以下の状況を示しています。

認証されていない SMTP 接続の兆候

受信用 SMTP 接続をモニターするには

最初に、システムで特定の読み取りが異常かどうかを判断するために、SMTP 接続の適切な数とその状態 (ESTABLISHED、CLOSE_WAIT など) を決定する必要があります。

多数の接続が SYN_RECEIVED 状態にある場合は、ネットワークがうまく稼働していなかったり、サービス拒否攻撃が行われていることもあります。さらに、SMTP サーバープロセスの有効期間は制限されています。これは、dispatcher.cnf ファイルの MTA 設定変数 MAX_LIFE_TIME によって制御されます。デフォルトは 86,400 秒 (1 日) です。同様に、MAX_LIFE_CONNS は、サーバープロセスがその有効期間中に処理できる接続の最大数を指定します。特定の SMTP サーバーが長時間稼働している場合は、調査することもできます。

ディスパッチャおよびジョブコントローラのプロセスをモニターする

MTA が機能するためには、ディスパッチャおよびジョブコントローラプロセスが動作している必要があります。種類ごとに 1 つのプロセスが必要です。

ディスパッチャおよびジョブコントローラのプロセスダウンの兆候

ディスパッチャがダウンしていたり十分なリソースがない場合、SMTP 接続は拒否されます。

ジョブコントローラがダウンしている場合、キューのサイズが大きくなります。

ディスパッチャおよびジョブコントローラのプロセスをモニターするには

メッセージアクセスをモニターする

imapd、popd、および httpd をモニターする

これらのプロセスによって、IMAP、POP、および Web メールサービスにアクセスします。これらのいずれかが実行されていないか応答がない場合、サービスは正しく機能しません。サービスが実行されていても過負荷の場合は、モニターすることでそれを検出し、より適切に設定し直すことができます。

imapd、popd、および httpd に関する問題の兆候

接続が拒否されたり、システムが遅すぎて接続できません。たとえば、IMAP が実行されていないときに IMAP に直接接続しようとすると、以下のようなメッセージが表示されます。

telnet 0 143
Trying 0.0.0.0...
telnet: Unable to connect to remote host: Connection refused

クライアントと接続しようとすると、以下のようなメッセージが表示されます。

Client is unable to connect to the server at the location you have specified. The server may be down or busy.

imapd、popd、および httpd をモニターするには

watcher によってモニターすることができます。「障害が発生したサービスや応答がないサービスの自動再起動」を参照してください。

SNMP によってモニターすることができます。

SNMP を設定している場合は、これらのプロセスをモニターすることをお勧めします。付録 A 「SNMP サポート」を参照してください。サーバー情報は、Network Services Monitoring MIB にあります。

ログファイルをチェックします。

msg_svr_base/log/service ディレクトリを確認します。このディレクトリで service を http、IMAP、または POP にすることができます。このディレクトリで、ログファイルの数を確認します。1 つは service (imap、pop、http) というファイル名です。ほかのファイル名には、サービスの名前、シーケンス番号、およびサービス名に連結された日付が使われます。
例 :

imap imap.29.1010221593 imap.31.1010394412 imap.33.1010567224

サービス名だけを含むファイルは、最新のログです。それ以外のファイルは、シーケンス番号 (ここでは 29、31、33) 順に並べられ、シーケンス番号が一番大きいファイルが次に新しいファイルです (第 20 章「ログ記録とログ解析」を参照)。

サーバーが停止した場合は、以下のように表示されることがあります。

imap.12.1065431243:[07/Oct/2003:01:15:43 -0700] gotmail-2 imapd[20525]: General Warning: Sun Java System Messaging Server IMAP4 6.1 (built Sep 24 2003) shutting down

counterutil を使ってチェックできます。「counterutil」および『Sun Java System Messaging Server Administration Reference』を参照してください。

プラットフォーム固有のコマンドを実行して、imapd、popd、および httpd プロセスが実行中かどうかを確認します。たとえば、Solaris では、ps コマンドを使用し、imapd、popd、および mshttpd を検索することができます。

「推奨される stored パラメータ」に記載されているサーバー応答設定パラメータを設定することによって、指定したサーバーのパフォーマンスしきい値に対する警告を設定することができます。

「immonitor-access」を参照してください。

stored をモニターする

stored は、存続期間決定ポリシーを実行したり、ディスクに保存されているメッセージを消去して、メッセージデータベースのデッドロック操作やトランザクション操作などの、さまざまな重要なタスクを実行します。stored が実行を停止すると、最終的には Messaging Server に問題が発生します。start-msg が実行されているときに stored が起動していないと、ほかのプロセスも起動しません。stored の詳細については、『Sun Java System Messaging Server Administration Reference』を参照してください。

stored に関する問題の兆候

stored をモニターするには

LDAP Directory Server をモニターする

slapd をモニターする

LDAP ディレクトリサーバー (slapd) は、メッセージングシステムのディレクトリ情報を提供します。slapd がダウンしていると、システムは正しく作動しません。slapd 応答時間が遅すぎると、ログイン速度、および LDAP 検索を必要とするほかのトランザクションに影響を及ぼします。

slapd に関する問題の兆候

slapd をモニターするには

メッセージストアをモニターする

メッセージはデータベースに保存されています。ディスク上のユーザーの分散、メールボックスのサイズ、ディスクの要件は、ストアのパフォーマンスに影響します。この節には、以下の項があります。

メッセージストアデータベースのロック状態をモニターする

データベースロックの状態は、さまざまなサーバープロセスで保持されます。これらのデータベースロックは、メッセージストアのパフォーマンスに影響することがあります。デッドロックの場合、メッセージが適切な速度でストアに挿入されないため、結果として ims-ms チャネルキューが大きくなります。キューをバックアップするのにはいくつかの正当な理由があります。したがって、キューの長さの履歴をとっておくと、問題を診断するのに便利です。

メッセージストアのデータベースロックに関する問題の兆候

メッセージストアのデータベースロックをモニターするには

mboxlist ディレクトリ内のデータベースログファイルの数をモニターする

データベースログファイルは、sleepycat トランザクションのチェックポイントログファイル (msg_svr_base/store/mboxlist ディレクトリ内) を指します。作成されるログファイルは、データベースのチェックポイントが発生しないという問題の兆候です。また、stored の問題による場合もあります。

データベースログファイルの問題の兆候

通常は、2 つまたは 3 つのログファイルがあります。ログファイルがそれ以上ある場合は、潜在的に重大な問題があることを示しています。メッセージストアはメッセージと制限容量のためにいくつかのデータベースを使用します。それらに問題があるとすべてのメールサーバーに問題が発生することがあります。

データベースログファイルをモニターするには

msg_svr_base/store/mboxlist ディレクトリを調べて、2 つまたは 3 つのファイルしかないことを確認してください。

モニター用のユーティリティとツール

immonitor-access

immonitor-access は、Messaging Server のコンポーネントおよびプロセスの次のステータスをモニターします。メール配信 (SMTP サーバー)、メッセージアクセスとストア (POP サーバーおよび IMAP サーバー)、ディレクトリサービス (LDAP サーバー)、および HTTP サーバー。このユーティリティでは、さまざまなサービスの応答時間と、メッセージの送受信にかかるラウンドトリップの総時間を測定します。ディレクトリサービスは、ディレクトリ内の指定したユーザーをルックアップし、応答時間を測定することで監視します。メール配信は、メッセージを送信することで (SMTP) 監視し、メッセージアクセスおよびストアはそのメッセージを受信することで監視します。HTTP サーバーの監視は、起動して実行中であるかどうかを調べることだけに制限されます。

手順については、『Sun Java System Messaging Server Administration Reference』を参照してください。

stored

stored ユーティリティはサーバー上で保守タスクを実行しますが、モニターも実行できます。指定されている場合は、サーバーの状態、ディスク容量、サービスへの応答時間を定期的にチェックでき、ポストマスターへの電子メールメッセージの形式で警告を発することができます (739 ページを参照)。

警告は、電子メールメッセージの形式で、stored からポストマスターに送られ、指定された状態を警告します。一定のしきい値を超えたときに stored が送信する電子メール警告のサンプルを以下に示します。

Subject:   ALARM:server response time in seconds of "ldap_siroe.com_389" is 10
Date:      Tue, 17 Jul 2001 16:37:08 -0700 (PDT)
From:     postmaster@siroe.com
To:          postmaster@siroe.com

Server instance:/opt/SUNWmsgsr
Alarmid:serverresponse
Instance: ldap_siroe_europa.com_389
Description:server response time in seconds
Current measured value (17/Jul/2001:16:37:08 -0700): 10 10
Lowest recorded value: 0 0
Highest recorded value: 10 10
Monitoring interval:600 seconds
Alarm condition is when over threshold of 10
Number of times over threshold: 1 1

stored でディスクおよびサーバーのパフォーマンスをモニターする頻度と、どのような状況下で警告を送るかを指定することができます。これは、configutil コマンドを使用して警告パラメータを設定することによって行います。有用な stored パラメータとそのデフォルト設定を表 22-1 に示します。

表 22-1 推奨される stored パラメータ
パラメータ	説明 (括弧内はデフォルト)
alarm.msgalarmnoticehost	(localhost) 警告メッセージの送信先のマシン
alarm.msgalarmnoticeport	(25) 警告メッセージの送信時に接続する SMTP ポート
alarm.msgalarmnoticercpt	(Postmaster@localhost) 警告通知の送信先
alarm.msgalarmnoticesender	(Postmaster@localhost) 警告の差出人のアドレス
alarm.diskavail.msgalarmdescription	ディスク利用度警告の説明
alarm.diskavail.msgalarmstatinterval	(3600) ディスク利用度のチェック間隔 (秒)。ディスク使用状況をチェックしない場合は、0 に設定する
alarm.diskavail.msgalarmthreshold	(10) 利用可能なディスク容量の割合。この値を下回ると警告が送信される
alarm.diskavail.msgalarmthresholddirection	(-1) 利用可能なディスク容量がしきい値 (-1) より低いか、しきい値 (1) より高いときに警告を発行するかどうかを指定する
alarm.diskavail.msgalarmwarninginterval	(24) ディスク利用度のアラームが繰り返される間隔 (時)
alarm.serverresponse.msgalarmdescription	サーバー応答警告の説明
alarm.serverresponse.msgalarmstatinterval	(600) サーバー応答のチェックの間隔 (秒)。サーバーの応答を確認しない場合は、0 に設定する
alarm.serverresponse.msgalarmthreshold	(10) サーバー応答時間 (秒) がこの値を超えると、警告が発行される
alarm.serverresponse.msgalarmthresholddirection	(1) サーバー応答時間がしきい値より大きい (1) か、しきい値より小さい (-1) ときに、警告を発行するかどうかを指定する
alarm.serverresponse.msgalarmwarninginterval	(24) サーバー応答警告が繰り返される間隔 (時)

counterutil

このユーティリティは、さまざまなシステムカウンタから取得した統計情報を提供します。以下は、現在利用できるカウンタオブジェクトのリストです。

# /opt/SUNWmsgsr/sbin/counterutil -l
Listing registry (/opt/SUNWmsgsr/data/counter/counter)
numobjects = 11
refcount = 1
created = 25/Sep/2003:02:04:55 -0700
modified = 02/Oct/2003:22:48:55 -0700
       entry = alarm
       entry = diskusage
       entry = serverresponse
       entry = db_lock
       entry = db_log
       entry = db_mpool
       entry = db_txn
       entry = imapstat
       entry = httpstat
       entry = popstat
       entry = cgimsg

それぞれのエントリはカウンタオブジェクトを表し、このオブジェクトに使用できるさまざまなカウントを提供します。この節では、alarm、diskusage、serverresponse、db_lock、popstat、imapstat、および httpstat カウンタオブジェクトについてのみ説明します。counterutil コマンドの使用法については、『Sun Java System Messaging Server Administration Reference』を参照してください。

counterutil の出力

counterutil にはさまざまなフラグがあります。このユーティリティのコマンドの形式は次のとおりです。

# counterutil -o imapstat -i 5 -n 10
Monitor counteroobject (imapstat)
registry /gotmail/iplanet/server5/msg-gotmail/counter/counter opened
counterobject imapstat opened

count = 1 at 972082466 rh = 0xc0990 oh = 0xc0968

global.currentStartTime [4 bytes]:17/Oct/2000:12:44:23 -0700
global.lastConnectionTime [4 bytes]:20/Oct/2000:15:53:37 -0700
global.maxConnections [4 bytes]: 69 69
global.numConnections [4 bytes]: 12480 12480
global.numCurrentConnections [4 bytes]: 48 48
global.numFailedConnections [4 bytes]: 0 0
global.numFailedLogins [4 bytes]: 15 15
global.numGoodLogins [4 bytes]: 10446 10446
...

counterutil を使用した警告統計

これらの警告統計は、stored が送信する警告を指します。警告カウンタは以下の統計を提供します。

表 22-2 counterutil alarm 統計
サフィックス	説明
alarm.countoverthreshold	しきい値を超えた回数
alarm.countwarningsent	送信された警告の数
alarm.current	現在のモニター値
alarm.high	これまでに記録された最高値
alarm.low	これまでに記録された最低値
alarm.timelastset	最後に現在の値が設定された時間
alarm.timelastwarning	最後に警告が送信された時間
alarm.timereset	最後にリセットが行われた時間
alarm.timestatechanged	最後に警告状態が変わった時間
alarm.warningstate	警告状態 (yes(1) または no(0))

counterutil を使用した IMAP、POP、および HTTP 接続の統計

現在の IMAP、POP、および HTTP 接続の数、ログインに失敗した回数、開始時間からの接続合計などの情報を得るために、コマンド counterutil -o CounterObject -i 5 -n 10 を使用することができます。ここで、CounterObject は、カウンタオブジェクト popstat、imapstat、または httpstat を表します。imapstat サフィックスの意味を表 22-3 に示します。popstat および httpstat オブジェクトは、同じ情報を同じ形式と構造で提供します。

表 22-3 counterutil imapstat 統計
サフィックス	説明
currentStartTime	現在の IMAP サーバープロセスの開始時間
lastConnectionTime	最後に新しいクライアントが受け入れられた時間
maxConnections	IMAP サーバーが処理した同時接続の最大数
numConnections	現在の IMAP サーバーが処理した接続の総数
numCurrentConnections	アクティブな接続の現在の数
numFailedConnections	現在の IMAP サーバーが処理した失敗した接続の数
numFailedLogins	現在の IMAP サーバーが処理した失敗したログインの数
numGoodLogins	現在の IMAP サーバーが処理した成功したログインの数

counterutil を使用したディスク使用状況の統計

表 22-4 counterutil diskstat 統計
サフィックス	説明
diskusage.availSpace	ディスクパーティションで利用できる合計容量
diskusage.lastStatTime	最後に統計がとられた時間
diskusage.mailPartitionPath	メールパーティションのパス
diskusage.percentAvail	利用できるディスクパーティション容量の割合
diskusage.totalSpace	ディスクパーティションの合計容量

サーバー応答の統計

コマンド : counterutil -o serverresponse は以下の情報を生成します。この情報は、サーバーが稼働中かどうかと、サーバーの応答速度をチェックする際に便利です。

表 22-5 counterutil serverresponse 統計
サフィックス	説明
http.laststattime	最後に http サーバー応答がチェックされた時間
http.responsetime	http の応答時間
imap.laststattime	最後に imap サーバー応答がチェックされた時間
imap.responsetime	imap の応答時間
pop.laststattime	最後に pop サーバー応答がチェックされた時間
pop.responsetime	pop の応答時間
ldap_host1_389.laststattime	最後に ldap_host1_389 サーバー応答がチェックされた時間
ldap_host1_389.responsetime	ldap_host1_389 の応答時間
ugldap_host2_389.laststattime	最後に ugldap_host2_389 サーバー応答がチェックされた時間
ugldap_host2_389.responsetime	ugldap_host2_389 の応答時間

ログファイル

Messaging Server は、SMTP、IMAP、POP、および HTTP のイベント記録をログに保存します。Messaging Server ログファイルの作成と管理用のポリシーはカスタマイズ可能です。

ログ記録はサーバーのパフォーマンスに影響を与えることがあるため、サーバーに負担がかからないよう、非常に慎重に検討する必要があります。詳細は、第 20 章「ログ記録とログ解析」を参照してください。

imsimta counters

MTA は、アクティブなチャネルのそれぞれに対して、Mail Monitoring MIB (RFC 1566) に基づいてメッセージトラフィックのカウンタを累積します。チャネルカウンタは、使用している電子メールシステムの傾向や調子を示すためのものです。チャネルカウンタは、メッセージトラフィックを正確に計算するためのものではありません。正確な計算については、第 20 章「ログ記録とログ解析」に記載されている MTA ログを参照してください。

MTA チャネルカウンタは、利用可能な最軽量メカニズムを使用して実装されるため、実際の操作での影響はわずかです。チャネルカウンタはさらに処理を行おうとはしません。つまり、セクションのマッピングの試行が失敗した場合やセクション内のロックの 1 つをほぼ即座に取得できない場合は、情報が記録されず、システムが停止している場合は、メモリ内セクションに含まれている情報は永久に失われます。

imsimta counters -show コマンドによって MTA チャネルメッセージの統計が得られます (以下を参照)。最小値が何も示されないときは、これらのカウンタを調べる必要があります。チャネルによっては、実際の最小値は負の値です。負の値は、カウンタがゼロになった (たとえば、カウンタのクラスタレベルのデータベースが作成された) 時点でチャネルのキューに入れられたメッセージがあることを示します。これらのメッセージがキューから取り出されるとき、関連するチャネルのカウンタは減少し、それによって最小値が負になります。このようなカウンタの場合、正確な「絶対」値は、初期化以降にカウンタが保持していた最小値を差し引いた現在の値です。

Channel          Messages    Recipients    Blocks
-------          --------    ----------    -------
tcp_local
   Received       29379       79714      982252                      (1)
   Stored            61         113       -2004                      (2)
   Delivered      29369       79723      983903 (29369 first time)    (3)
   Submitted      13698       13699       18261                      (4)
   Attempted          0           0           0                      (5)
   Rejected           1          10           0                      (6)
   Failed           104         104        4681                      (7)

   Queue time/count        16425/29440 = 0.56                        (8)
   Queue first time/count  16425/29440 = 0.56                        (9)

   Total In Assocs           297637
   Total Out Assocs           28306

1) Received は、tcp_local という名前のチャネルのキューに入れられたメッセージの数です。つまり、ほかのチャネルによって directory チャネルのキューに入れられたメッセージ (mail.log* ファイル内の E レコード) です。

2) Stored は、チャネルキューに保存された配信されるメッセージの数です。

3) Delivered は、チャネル tcp_local によって処理された (キューから取り出された) メッセージの数です (つまり、mail.log* ファイル内の D レコード)。キューからの取り出しとは、正常な配信 (別のチャネルのキューに入れること) か、またはメッセージが差出人に戻ってきたためにキューから取り出すことのいずれかを指します。通常これは、Received の数から Stored の数を引いた数に相当します。

MTA は、最初の試行でキューから取り出されたメッセージ数も記録します。

4) Submitted は、チャネル tcp_local によって別のチャネルのキューに入れられたメッセージ (mail.log ファイル内の E レコード) の数です。

5) Attempted は、キューから取り出す際に一時的な問題が発生したメッセージ (mail.log* ファイル内の Q または Z レコード) の数です。

6) Rejected は、拒否されたキューからの取り出し試行 (mail.log* ファイル内の J レコード) の数です。

7) Failed は、失敗したキューからの取り出し試行 (mail.log* ファイル内の R レコード) の数です。

8) Queue time/count は、配信されるメッセージがキューに入っていた時間の平均時間です。これは、最初の試行で配信されたメッセージ ( ( 9) を参照) と、追加の配信試行が必要になった (通常はそのためにキューの中で長い間待機している) メッセージの両方が対象になっています。

9) Queue first time/count は、最初の試行で配信されたメッセージがキューに入っていた時間の平均時間です。

送信されたメッセージの数が配信されたメッセージの数より大きくなっていることに注意してください。この原因のほとんどは、メッセージがチャネルのキューから取り出される (配信される) たびに少なくとも 1 つ (場合によっては複数) の新しいメッセージがキューに入れられる (送信される) ためです。たとえば、メッセージが異なるチャネル経由で 2 人の受取人に届けられる場合は、2 つのメッセージがキューに入れられる必要があります。すなわち、メッセージがバウンスされる場合は、差出人にコピーが返送され、もう 1 つのコピーがポストマスターに送信されることがあります。通常は 2 件の送信になります (両方とも同じチャネル経由で届けられる場合を除く)。

通常は、Submitted と Delivered の間の接続はチャネルのタイプによって異なります。たとえば、変換チャネルでは、メッセージはほかの任意のチャネルのキューに入れられ、そのあと変換チャネルがそのメッセージを処理し、それを 3 番目のチャネルのキューに入れ、元のチャネルのキューから取り出されたものとしてメッセージをマークします。個々のメッセージのパスは以下のとおりです。

ほかの場所 -> 変換チャネル   E レコード   Received
変換チャネル -> ほかの場所   E レコード   Submitted
変換チャネル                 D レコード   Delivered

ただし、tcp_local のように「通過」しなくても 2 つの部分 (スレーブとマスター) があるチャネルの場合は、Submitted と Delivered の間の接続はありません。Submitted カウンタが tcp_local チャネルの SMTP サーバー部分を処理する必要があるのに対し、Delivered は tcp_local チャネルの SMTP クライアント部分を処理する必要があります。これらは 2 つのまったく別のプログラムであり、それぞれから送られるメッセージはまったく別のものになることがあります。

SMTP クライアント経由でほかの SMTP ホストに送信されるメッセージ

ほかの場所 -> tcp_local E レコード Received
tcp_local D レコード Delivered

チャネルのキューからの取り出し (配信) により、少なくとも 1 つの新しいメッセージがキューに入れられ (送信され) ます。複数になることもあります。たとえば、メッセージが異なるチャネル経由で 2 人の受取人に届けられる場合は、2 つのメッセージがキューに入れられる必要があります。すなわち、メッセージがバウンスされる場合は、差出人にコピーが返送され、もう 1 つのコピーがポストマスターに送信されることがあります。通常は同じチャネル経由で届けられます。

UNIX および NT での実装

パフォーマンス上の理由から、MTA はメモリ内にチャネルカウンタのキャッシュを保持します。これには、UNIX では共有メモリセクションを使用し、NT では共有ファイルマッピングオブジェクトを使用します。ノード上のプロセスがメッセージをキューに入れたりキューから取り出すときに、このプロセスがそのメモリ内キャッシュ内のカウンタを更新します。チャネルが作動しているときにメモリ内セクションが存在しない場合、メモリ内セクションは自動的に作成されます (imta start コマンドも、存在しない場合はメモリ内キャッシュを作成)。

imta counters -clear コマンドまたは imta qm コマンドの counters clear は、カウンタをゼロにリセットするために使用することもあります。

imsimta qm counters

imsimta qm counters ユーティリティは、MTA チャネルのキューメッセージカウンタを表示します。このユーティリティは、root または inetuser として実行する必要があります。出力されるフィールドは「imsimta counters」に記載されているものと同じです。使用法については、『Sun Java System Messaging Server Administration Reference』を参照してください。

Channel                 Messages    Recipients     Blocks
----------------------  ----------  ----------    ----------
tcp_intranet
   Received              13077        13859         264616
   Stored                   92           91           -362
   Delivered             12985        13768         264978
   Submitted              2594         2594           3641
...

MTA を再起動するたびに、# imsimta counters -create を実行する必要があります。

SNMP を使用した MTA のモニター

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

メールボックスの制限容量チェックのための imquotacheck

imquotacheck ユーティリティを使用して、メールボックスの制限容量の使用状況と制限をモニターすることができます。imquotacheck ユーティリティは、定義された制限容量を一覧表示し、制限容量の使用状況に関する情報を提供するレポートを生成します。

たとえば次のコマンドでは、全ユーザーの制限容量に関する情報を一覧表示します。

以下の例では、ユーザー sorook の制限容量の使用状況を示します。

前へ目次索引次へ
Sun Java System Messaging Server 6 2004Q2 管理ガイド