第 23 章 Messaging Server を監視する

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

• 「毎日の監視作業」

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

• 「MTA を監視する」

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

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

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

• 「ディスク容量を監視する」

• 「CPU 使用状況を監視する」

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

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

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

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

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

• メッセージを送信および受信する機能を使用します。サーバーのホップ間のヘッダー時間、および始点と取り出しの時間を比較します。「immonitor-access」を参照してください。

ディスク容量を監視する

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

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

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

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

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

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

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

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

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

• メッセージストアのディスク使用量を監視するためのパラメータを設定します。

• ディスク使用量のしきい値に達したら、メッセージストアパーティションをロックします。

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

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

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

• alarm.diskavail.msgalarmstatinterval

• alarm.diskavail.msgalarmthreshold

• alarm.diskavail.msgalarmwarninginterval

• alarm.diskavail.msgalarmdescription

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

configutil -o alarm.diskavail.msgalarmstatinterval -v 600

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

configutil -o alarm.diskavail.msgalarmthreshold -v 20

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

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

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

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

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

• パーティションをロックします。着信メッセージは MTA メッセージキューに保持されますが、メッセージストアパーティション内のメールボックスには配信されません。

• メッセージをデフォルトのログファイルに記録します。

• ポストマスターに電子メール通知を送信します。configutil パラメータの alarm.msgalarmnoticercpt を設定して、電子メールの受信者を変更できます。

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

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

• local.store.checkdiskusage は、パーティション監視機能を有効にします。

  許容可能な値: yes、no

  デフォルト値: yes

• local.store.diskusagethreshold は、ディスク使用量のしきい値を指定します。local.store.diskusagethreshold の値は、1 〜 99 のパーセンテージです。

  デフォルト値: 99

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

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

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

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

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

CPU 使用状況を監視する

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

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

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

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

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

MTA を監視する

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

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

• 「配信エラーの頻度を監視する」

• 「受信 SMTP 接続を監視する」

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

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

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

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

• 外部ユーザーによるメールのリレー: ログエントリレコード J (拒否されたリレー) を含むレコードの msg_svr_base/log/mail.log_current を確認します。リモート IP アドレスのログを有効にするには、option.dat ファイルに次の行を追加します。

  log_connection=1

  この機能を有効にすると、わずかながらパフォーマンスが低下します。

• サービス拒否攻撃: SMTP サーバーに接続しているユーザーとその人数を調べるには、netstat コマンドを実行し、SMTP ポートの接続数 (デフォルトは 25) を確認します。次に例を示します。

Local address       Remote address                                 State
192.18.79.44.25     192.18.78.44.56035    32768   0  32768   0   CLOSE_WAIT
192.18.79.44.25     192.18.136.54.57390    8760   0  24820   0   ESTABLISHED
192.18.79.44.25     192.18.26.165.48508   33580   0  24820   0   TIME_WAIT

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

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

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

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

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

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

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

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

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

LDAP Directory Server を監視する

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

• 「slapd を監視する」

slapd を監視する

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

slapd に関する問題の兆候

• クライアントの POP、IMAP、または Web メール認証が失敗するか、予定よりも時間がかかる。

• MTA が正しく動作しない。

slapd を監視するには

• ns-slapd プロセスが実行中かどうかをチェックします。

• slapd-instance/logs/ にある slapd ログファイルの access および errors をチェックします。

• ユーザー検索時の ns-slapd 応答時間をチェックします。

• コンソールを表示して slapd を監視します。

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

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

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

• 「imapd、popd、および httpd を監視する」

• 「stored を監視する」

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 と msprobe によって監視することができます。「障害が発生したサービスや応答がないサービスの自動再起動」および 「msprobe および 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) 順に並べられ、シーケンス番号の一番大きいファイルが次に新しいファイルです (第 21 章「ログの管理」を参照)

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

  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 6 2005Q4 Administration Reference』の「counterutil」を参照してください。

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

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

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

stored を監視する

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

stored に関する問題の兆候

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

stored を監視するには

• stored プロセスが実行中かどうかをチェックします。stored は、pidfile.store という msg_svr_base/config 内の pid ファイルを作成し、更新します。この pid ファイルは、復元中の init 状態と準備中の ready 状態を示します。例:

  231: cat pidfile.store 28250 ready

  1 行目の数字は stored のプロセス ID です。

  232: ps -eaf | grep stored inetuser 28250 1 0 Jan 05 ? 8:44 /opt/SUNWmsgsr/lib/stored -d

• msg_svr_base/store/mboxlist に作成されたログファイルをチェックします。すべてのログファイルが直接 stored の問題によって作成されるわけではありません。ログファイルは、imapd が壊れている場合やデータベースに問題がある場合にも作成されることがあります。

• msg_svr_base/config 内の次のファイルのタイムスタンプをチェックします。

  stored.ckp - チェックポイントで試行が行われたときに押されます。1 分ごとにタイムスタンプが付けられます。stored.lcu - データベースログのクリーンアップごとに押されます。5 分ごとにタイムスタンプが付けられます。stored.per - ユーザー単位のデータベース書き込み時に押されます。60 分ごとにタイムスタンプが付けられます。

• デフォルトログファイルの msg_svr_base/log/default/default 内の stored メッセージをチェックします。

• watcher と msprobe によって監視することができます。「障害が発生したサービスや応答がないサービスの自動再起動」および 「msprobe および watcher 関数を使用した監視」を参照してください。

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

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

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

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

• 「mboxlist ディレクトリ内のデータベースログファイルの数を監視する」

• 「制限容量を監視するには」

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

データベースロックの状態は、さまざまなサーバープロセスで保持されます。これらのデータベースロックは、メッセージストアのパフォーマンスに影響することがあります。デッドロックの場合、メッセージが適切な速度でストアに挿入されないため、結果として 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」

• 「stored」

• 「counterutil」

• 「ログファイル」

• 「imsimta counters」

• 「imsimta qm counters」

• 「SNMP を使用した MTA の監視」

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

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

immonitor-access

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

詳細な手順は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「immonitor-access」を参照してください。

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 6 2005Q4 Administration Reference』の「counterutil」を参照してください。

counterutil の出力

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

counterutil -o CounterObject -i 5 -n 10

ここで、

-o CounterObject は、カウンタオブジェクト alarm、diskusage、serverresponse、db_lock、popstat、imapstat、および httpstat を表します。

-i 5 は、5 秒の間隔を指定します。

-n 10 は、反復回数 (デフォルト: 無限) を表します。

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 が送信する警告を指します。警告カウンタは次の統計を提供します。

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

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

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

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

サーバー応答の統計

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

ログファイル

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 という名前のチャネルのキューに入れられたメッセージの数です。つまり、ほかのチャネルによって tcp_local チャネルのキューに入れられたメッセージ (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 6 2005Q4 Administration Reference』の「imsimta counters」も参照してください。

次に例を示します。

# 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 の特定の部分を監視することができます。詳細は、付録 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             ajonk
no quota              5             no quota      2                andrt
no quota         355518             no quota      2500             ansri
 ...

次の例では、ユーザー 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 は次の状態を監視します。

• サーバー応答時間: msprobe は有効になっているサーバーにそのプロトコルコマンドを使って接続し、応答時間を測定します。応答時間が警告のしきい値を超えると、警告メッセージがサーバーに送信されます (「警告メッセージ」を参照)。また、サーバーの応答時間が指定のタイムアウト期間を超えると、サーバーは再起動されます。サーバーの応答時間はカウンタデータベースに記録され、デフォルトのログファイルに記録されます。サーバーの応答時間の統計を表示するには、counterutil を使用します (「counterutil」を参照)。

  msprobe によって監視されるサーバーは、imap、pop、http、cert、job_controller、smtp、lmtp、mmp、および ens です。smtp または lmtp が応答しないときは、ディスパッチャーが再起動されます。ens は自動的に再起動できません。

• ディスク使用量: msprobe はメッセージストアパーティションごとのディスクの利用度と使用量をチェックします。特に、メッセージストアの mboxlist データベースディレクトリと MTA キューディレクトリをチェックします。ディスク使用量が設定したしきい値を超えると、警告メッセージが送信されます。ディスクのサイズと使用量はカウンタデータベースに記録され、デフォルトのログファイルに記録されます。管理者は、counterutil ユーティリティー (「counterutil」を参照) を使用してディスク使用量の統計を表示できます。

• メッセージストアの mboxlist データベースログファイルの累積: ログファイルの累積は、mboxlist データベースのエラーを示しています。msprobe はアクティブなログファイルの数をカウントし、その数がしきい値よりも大きい場合は、重大エラーメッセージを default ログファイルに記録して、管理者にサーバーを再起動することを通知します。autorestart が有効になっている (local.autorestart が yes に設定されている) 場合は、ストアデーモンが再起動されます。

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

警告メッセージ

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

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 6 2005Q4 Administration Reference』の「configutil Parameters」を参照してください。