Sun Java ロゴ     前へ      目次      索引      次へ     

Sun ロゴ
Sun Java System Messaging Server 6 2005Q1 管理ガイド 

第 23 章
Messaging Server を監視する

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

トラブルシューティングの手順については、第 22 章「MTA のトラブルシューティング」を参照してください。

自動監視と自動再起動

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

毎日の監視作業

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

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

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

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

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

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

ログファイルを監視および管理する

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

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

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

msprobe ユーティリティは、監視関数や再起動関数を自動的に実行します。詳細は、「msprobe および watcher 関数を使用した監視」を参照してください。

システムのパフォーマンスを監視する

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

終端間メッセージ配信時間を監視する

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

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

メールの配信に、通常よりも長い時間がかかります。

終端間メッセージ配信時間を監視するには

ディスク容量を監視する

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

メッセージストアパーティションは、新しいメッセージがメールボックスに配信されるたびに大きくなります。たとえば、メッセージストアに制限容量を課さない場合、メッセージストアがパーティションに利用できるディスク容量より大きくなることがあります。ディスク容量が不足するもう 1 つの原因は、MTA メッセージキューが大きくなりすぎることです。3 番目の原因としては、ログファイル監視機能に問題が発生し、ログファイルが制御できないほど大きくなってしまう場合が考えられます。ログファイルには、LDAP、MTA、および Message Access など、多数のものがあり、それらの各ログファイルは別のディスクに保存することができることに注意してください。

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

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

メッセージストアパーティションが一杯になると、メッセージアクセスデーモンが失敗したり、メッセージストアデータが壊れたりすることがあります。imexpire や reconstruct などのメッセージストア保守ユーティリティは、破損を修復したり、ディスク使用量を削減したりすることができます。ただし、それらのユーティリティはさらにディスク容量を必要とし、ディスク全体を占有したパーティションの修復はダウン時間の発生原因になります。

ディスク容量を監視するには

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

Messaging Server は、メッセージストアディスクの使用量を監視し、パーティションがすべての利用可能なディスク容量を使い果たすのを防止する手段を提供します。

次の手順で、メッセージストアのディスク容量の使用状況を監視できます。

詳細は、次の節の「メッセージストアを監視する」と「メッセージストアのパーティションを監視する」を参照してください。

メッセージストアを監視する

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

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

configutil -o alarm.diskavail.msgalarmstatinterval -v 600

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

configutil -o alarm.diskavail.msgalarmthreshold -v 20

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

メッセージストアのパーティションを監視する

利用可能なディスク容量の指定された割合をパーティションが超過したら、メッセージをメッセージストアパーティションに配信するのを停止できます。このためには、2 つの configutil パラメータを使って、その機能を有効にし、ディスク使用量のしきい値を指定します。

この機能を使用して、メッセージストアデーモンはパーティションのディスク使用量を監視します。ディスクの使用量が増加するにつれ、ストアデーモンは動的にパーティションをチェックする頻度 (100 分に 1 回〜 1 分に 1 回) を増やします。

ディスク使用量が指定されたしきい値を超えた場合、ストアデーモンは次のようにします。

ディスクの使用量がしきい値を下回ると、パーティションのロックが解除され、メッセージはまたストアに配信されるようになります。

次のような configutil パラメータがあります。

ディスク使用量のしきい値には、ローカルメッセージストアを再パーティションしたり、さらに多くのディスク容量を割り当てたりするための時間が確保できる低いパーセンテージに設定する必要があります。

たとえば、パーティションが 1 時間に 2 パーセントの割合でディスク容量を使用していき、またローカルメッセージストアにさらにディスク容量を割り当てるのに 1 時間かかるとします。この場合は、ディスク使用量のしきい値を 98 パーセント未満の値に設定する必要があります。

MTA キューとログ領域を監視する

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

ログ領域の管理については、第 21 章「ログの管理」を参照してください。mail.log ファイルの監視方法については、「MTA メッセージおよび接続のログの管理」を参照してください。

CPU 使用状況を監視する

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

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

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

CPU 使用状況を監視するには

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

MTA を監視する

この節には、以下の項があります。

メッセージキューのサイズを監視する

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

メッセージキューの詳細については、「チャネルメッセージキュー」、「メッセージがキューから取り出されない」、および「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 接続を監視するには

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

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

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

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

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

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

dispatcher および job_controller というプロセスが存在しているかどうかチェックします。「ジョブコントローラとディスパッチャが実行中であることをチェックする」を参照してください。

LDAP Directory Server を監視する

この節には、以下の項目があります。

slapd を監視する

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

slapd に関する問題の兆候

slapd を監視するには

メッセージアクセスを監視する

この節には、以下の項があります。

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 を監視するには

stored を監視する

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

stored に関する問題の兆候

表面的な問題の兆候はありません。

stored を監視するには

メッセージストアを監視する

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

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

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

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

多数のトランザクションが蓄積され、解決されません。

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

counterutil -o db_lock
 コマンドを使用します。

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 ユーティリティはサーバー上で保守タスクを実行し、監視も実行できます。ただし、監視タスクは msprobe で行うことをお勧めします。「msprobe および watcher 関数を使用した監視」を参照してください。

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 の使用例を以下に示します。

# 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
global.numConnections [4 bytes]: 12480
global.numCurrentConnections [4 bytes]: 48
global.numFailedConnections [4 bytes]: 0
global.numFailedLogins [4 bytes]: 15
global.numGoodLogins [4 bytes]: 10446
  ...

counterutil を使用した警告統計

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

表 23-1 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 サフィックスの意味を表 23-2 に示します。popstat および httpstat オブジェクトは、同じ情報を同じ形式と構造で提供します。

表 23-2 counterutil imapstat 統計

サフィックス

説明

currentStartTime

現在の IMAP サーバープロセスの開始時間。

lastConnectionTime

最後に新しいクライアントが受け入れられた時間。

maxConnections

IMAP サーバーが処理した同時接続の最大数。

numConnections

現在の IMAP サーバーが処理した接続の総数。

numCurrentConnections

アクティブな接続の現在の数。

numFailedConnections

現在の IMAP サーバーが処理した失敗した接続の数。

numFailedLogins

現在の IMAP サーバーが処理した失敗したログインの数。

numGoodLogins

現在の IMAP サーバーが処理した成功したログインの数。

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

コマンド counterutil -o diskusage は以下の情報を生成します。

表 23-3 counterutil diskstat 統計

サフィックス

説明

diskusage.availSpace

ディスクパーティションで利用できる合計容量。

diskusage.lastStatTime

最後に統計がとられた時間。

diskusage.mailPartitionPath

メールパーティションのパス。

diskusage.percentAvail

利用できるディスクパーティション容量の割合。

diskusage.totalSpace

ディスクパーティションの合計容量。

サーバー応答の統計

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

表 23-4 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 ログファイルの作成と管理用のポリシーはカスタマイズ可能です。

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

imsimta counters

MTA は、アクティブなチャネルのそれぞれに対して、Mail Monitoring MIB (RFC 1566) に基づいてメッセージトラフィックのカウンタを累積します。チャネルカウンタは、使用している電子メールシステムの傾向や調子を示すためのものです。チャネルカウンタは、メッセージトラフィックを正確に計算するためのものではありません。正確な計算については、第 21 章「ログの管理」に記載されている 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 サーバー に送信されるメッセージ

tcp_local -> ほかの場所  E レコード    Submitted

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』を参照してください。

次に例を示します。

# imsimta counters -create
# imsimta qm counters show

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 ユーティリティは、定義された制限容量を一覧表示し、制限容量の使用状況に関する情報を提供するレポートを生成します。

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

% imquotacheck
-------------------------------------------------------------------------
Domain red.siroe.com (diskquota = not set msgquota = not set) quota usage
-------------------------------------------------------------------------
diskquota        size(K)    %use    msgquota      msgs    %use    user
# of domains = 1
# of users = 705

no quota         50418              no quota      4392            ajonkish
no quota         5                  no quota      2               andrewt
no quota         355518             no quota      2500            aniksri
...

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

% imquotacheck -u sorook
-------------------------------------------------------------------------
quota usage for user sorook
-------------------------------------------------------------------------
diskquota      size(K)    %use    msgquota      msgs    %use    user

no quota       1487              no quota      305              sorook

msprobe および watcher 関数を使用した監視

Messaging Server には、各種のシステムサービスを監視するために、watcher と msprobe という 2 つのプロセスが用意されています。watcher は、サーバーのクラッシュを監視し、必要に応じて再起動を行います。msprobe は、サーバーのハングアップ (応答なし) を監視します。特に、msprobe は次の状態を監視します。

watcher と msprobe は、表 23-5 に示す configutil オプションによって制御されます。詳細については、「障害が発生したサービスや応答がないサービスの自動再起動」を参照してください。

表 23-5 msprobe および watcher の configutil オプション

オプション

説明

local.watcher.enable

サービスの障害を監視する watcher を有効にします。対象となるサービスは、IMAP、POP、HTTP、ジョブコントローラ、ディスパッチャ、メッセージストア (stored)、imsched、および MMP です。LMTP/SMTP サーバーはディスパッチャによって監視され、LMTP/SMTP クライアントは job_controller によって監視されます。それぞれの障害について、エラーメッセージをデフォルトのログファイルに記録します。デフォルト: on

local.autorestart

サーバーの自動再起動を有効にします。障害の発生したサービスまたはハングアップしたサービスを自動的に再起動します。デフォルト: no

local.autorestart.timeout

再試行失敗のタイムアウト。ここに指定した時間内でサーバーに 3 回以上障害が発生すると、システムはサーバーの再起動を試行しなくなります。値 (秒単位で指定) は、msprobe の間隔 (local.schedule.msprobe) よりも長い時間に設定する必要があります。デフォルト: 600 秒

local.schedule.msprobe

msprobe の実行スケジュール。crontab 形式でスケジュールを示す文字列 (表 18-10 を参照)。デフォルトは 600 秒です。

service.readtimeout

サーバーが再起動されるまでのデフォルトのタイムアウト。

デフォルト: smtp/lmtp の場合は 120 秒、その他のプロトコルの場合は 30 秒

local.probe.service.timeout

特定のサーバーが再起動されるまでのタイムアウト。service は、imap、pop、http、cert、job_controller、smtp、lmtp、mmp または ens のいずれかになります。

デフォルト: service.readtimeout の値を使用する

local.probe.warningthreshold

警告メッセージが default ログファイルに記録されるまでのサーバーの無応答時間 (秒)。

デフォルト: 5 秒

local.probe.service.warningthreshold

警告メッセージが default ログファイルに記録されるまでの特定のサーバーの無応答時間 (秒)。service は、imap、pop、http、cert、job_controller、smtp、lmtp、mmp または ens のいずれかになります。

デフォルト: local.probe.warningthreshold の値を使用する

local.queuedir

キューサイズが alarm.diskavail.msgalarmthreshold によって定義されたしきい値を超えているかどうかを確認するための MTA キューディレクトリ。

デフォルト: なし

local.schedule.msprobe

msprobe の実行スケジュール。この値は crontab 形式でスケジュールを示す文字列です。

デフォルト: 600 秒

service.readtimeout

サーバーを再起動するまでのサーバーの無応答時間。local.schedule.msprobe を参照してください。

デフォルト: 10 秒

警告メッセージ

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

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
Lowest recorded value: 0
Highest recorded value: 10
Monitoring interval:600 seconds
Alarm condition is when over threshold of 10
Number of times over threshold: 1

msprobe でディスクおよびサーバーのパフォーマンスを監視する頻度と、どのような状況下で警告を送るかを指定することができます。このためには、configutil コマンドを使用して警告パラメータを設定します。表 23-6 に、有用な警告パラメータとそのデフォルト設定を示します。完全なリストについては、『Sun Java System Messaging Server Administration Reference』を参照してください。

表 23-6 有用な警告メッセージの configutil パラメータ 

パラメータ

説明 (括弧内はデフォルト)

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). (24) ディスク利用度の警告が繰り返される間隔 (時)。

alarm.serverresponse.msgalarmdescription

(サーバーの応答時間を表す秒数)。サーバーの応答警告についての説明フィールドのテキスト。

alarm.serverresponse.msgalarmstatinterval

(600) サーバー応答のチェックの間隔 (秒)。サーバーの応答を確認しない場合は、0 に設定します。

alarm.serverresponse.msgalarmthreshold

(10) サーバー応答時間 (秒) がこの値を超えると、警告が発行されます。

alarm.serverresponse.msgalarmthresholddirection

(1) サーバー応答時間がしきい値より大きい (1) か、しきい値より小さい (-1) ときに、警告を発行するかどうかを指定します。

alarm.serverresponse.msgalarmwarninginterval

(24) サーバー応答警告が繰り返される間隔 (時)。



前へ      目次      索引      次へ     

Copyright 2005 Sun Microsystems, Inc. All rights reserved.