一般的に、十分に計画され的確に設定されたサーバーは、管理者の手を煩わすことなく動作を続けます。したがって、管理者の役割は、サーバーが問題の兆候を示していないか、監視することです。この章では、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 および watcher 関数を使用した監視」を参照してください。
この章では、Messaging Server の監視機能に注目します。ただし、サーバーが動作しているシステムも、同時に監視することが必要です。適切に設定されたサーバーであっても、設定が適切ではないシステム上では、本来の性能を発揮しないことがあるからです。また、サーバーエラーの発生は、ハードウェアの処理能力がメールシステムの動作には十分ではない場合もあります。この章では、システムパフォーマンスの監視の詳細についてすべて説明しているわけではありません。これらの手順の多くはプラットフォーム固有のものであり、プラットフォーム固有のシステムのマニュアルを参照することが必要になる場合もあります。パフォーマンスを監視する手順を次に示します。
電子メールは時間どおりに配信する必要があります。これがサービス契約の要件になっていることもあります。また、メールをできるだけ速く配信することは良いポリシーでもあります。終端間の時間が遅いことは、多くの事柄を示している可能性があります。たとえば、サーバーが正しく作動していない、1 日の特定の時間にメッセージが処理不能になる、既存のハードウェアリソースの容量を超えている、などです。
メールの配信に、通常よりも長い時間がかかります。
メッセージを送信および受信する機能を使用します。サーバーのホップ間のヘッダー時間、および始点と取り出しの時間を比較します。「immonitor-access」を参照してください。
ディスクの空き容量の不足は、メールサーバーで発生する問題や故障のうち、特に頻繁におきる原因の 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 回) を増やします。
ディスク使用量が指定されたしきい値を超えた場合、ストアデーモンは次のようにします。
パーティションをロックします。着信メッセージは 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 キューのディスクおよびログ領域のディスク使用量を監視する必要があります。
ログ領域の管理については、第 21 章「ログの管理」を参照してください。mail.log ファイルの監視方法については、「MTA メッセージおよび接続のログの管理」を参照してください。
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
指定した IP アドレスからの受信用 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 ディレクトリサーバー (slapd) は、メッセージングシステムのディレクトリ情報を提供します。slapd がダウンしていると、システムは正しく作動しません。slapd 応答時間が遅すぎると、ログイン速度、および LDAP 検索を必要とするほかのトランザクションに影響を及ぼします。
クライアントの POP、IMAP、または Web メール認証が失敗するか、予定よりも時間がかかる。
MTA が正しく動作しない。
ns-slapd プロセスが実行中かどうかをチェックします。
slapd-instance/logs/ にある slapd ログファイルの access および errors をチェックします。
ユーザー検索時の ns-slapd 応答時間をチェックします。
コンソールを表示して slapd を監視します。
「immonitor-access」も参照してください。
この節には、次の項があります。
これらのプロセスによって、IMAP、POP、および Web メールサービスにアクセスします。これらのいずれかが実行されていないか応答がない場合、サービスは正しく機能しません。サービスが実行されていても過負荷の場合は、監視することでそれを検出し、より適切に設定し直すことができます。
接続が拒否されるか、システムが遅すぎて接続できません。たとえば、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.
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 が実行を停止すると、最終的には Messaging Server に問題が発生します。start-msg が実行されているときに stored が起動していないと、ほかのプロセスも起動しません。stored の詳細は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「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 関数を使用した監視」を参照してください。
メッセージはデータベースに保存されています。ディスク上のユーザーの分散、メールボックスのサイズ、ディスクの要件は、ストアのパフォーマンスに影響します。次の項目で、これらの問題について説明します。
データベースロックの状態は、さまざまなサーバープロセスで保持されます。これらのデータベースロックは、メッセージストアのパフォーマンスに影響することがあります。デッドロックの場合、メッセージが適切な速度でストアに挿入されないため、結果として ims-ms チャネルキューが大きくなります。キューをバックアップするのにはいくつかの正当な理由があります。したがって、キューの長さの履歴をとっておくと、問題を診断するのに便利です。
多数のトランザクションが蓄積され、解決されません。
counterutil -o db_lock コマンドを使用します。
データベースログファイルは、sleepycat トランザクションのチェックポイントログファイル (msg_svr_base/store/mboxlist ディレクトリ内) を指します。作成されるログファイルは、データベースのチェックポイントが発生しないという問題の兆候です。また、stored の問題による場合もあります。
通常は、2 つまたは 3 つのログファイルがあります。ログファイルがそれ以上ある場合は、潜在的に重大な問題があることを示しています。メッセージストアはメッセージと制限容量のためにいくつかのデータベースを使用します。それらに問題があるとすべてのメールサーバーに問題が発生することがあります。
msg_svr_base/store/mboxlist ディレクトリを調べて、2 つまたは 3 つのファイルしかないことを確認してください。
監視には、次のツールを利用できます。
immonitor-access は、Messaging Server のコンポーネントやプロセスのステータスを監視します。対象となるコンポーネントやプロセスには、メール配信 (SMTP サーバー)、メッセージアクセスとストア (POP サーバーおよび IMAP サーバー)、ディレクトリサービス (LDAP サーバー)、および HTTP サーバーがあります。このユーティリティーでは、さまざまなサービスの応答時間と、メッセージの送受信にかかるラウンドトリップの総時間を測定します。ディレクトリサービスは、指定のユーザーをディレクトリ内で検索し、応答時間を測定することで監視します。メール配信はメッセージを送信することで (SMTP) 監視し、メッセージアクセスおよびストアはそのメッセージを受信することで監視します。HTTP サーバーの監視は、起動して実行中であるかどうかを調べることだけに制限されます。
詳細な手順は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「immonitor-access」を参照してください。
stored ユーティリティーはサーバー上で保守タスクを実行し、監視も実行できます。ただし、監視タスクは msprobe で行うことをお勧めします。「msprobe および watcher 関数を使用した監視」を参照してください。
このユーティリティーは、さまざまなシステムカウンタから取得した統計情報を提供します。以下は、現在利用できるカウンタオブジェクトのリストです。
それぞれのエントリはカウンタオブジェクトを表し、このオブジェクトに使用できるさまざまなカウントを提供します。この節では、alarm、diskusage、serverresponse、db_lock、popstat、imapstat、および httpstat カウンタオブジェクトについてのみ説明します。counterutil コマンドの使用法については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「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 ... |
これらの警告統計は、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)) です。 |
現在の 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 -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 章「ログの管理」を参照してください。
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 つのコピーがポストマスターに送信されることがあります。通常は同じチャネル経由で届けられます。
パフォーマンス上の理由から、MTA はメモリ内にチャネルカウンタのキャッシュを保持します。これには、UNIX では共有メモリセクションを使用し、NT では共有ファイルマッピングオブジェクトを使用します。ノード上のプロセスがメッセージをキューに入れたりキューから取り出すときに、このプロセスがそのメモリ内キャッシュ内のカウンタを更新します。チャネルが作動しているときにメモリ内セクションが存在しない場合、メモリ内セクションは自動的に作成されます (imta start コマンドも、存在しない場合はメモリ内キャッシュを作成)。
imta counters -clear コマンドまたは imta qm コマンドの counters clear は、カウンタをゼロにリセットするために使用することもあります。
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 を実行する必要があります。
Messaging Server では、SNMP (Simple Network Management Protocol) を利用したシステム監視機能がサポートされています。Sun Net Manager や (本製品には付属していない) HP OpenView などの SNMP クライアント (「ネットワークマネージャー」とも呼ばれる) を使って、Messaging Server の特定の部分を監視することができます。詳細は、付録 A 「SNMP サポート」を参照してください。
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 |
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 オプションによって制御されます。詳細は、「障害が発生したサービスや応答がないサービスの自動再起動」を参照してください。
表 23–5 msprobe および watcher の configutil オプション
オプション |
説明 |
---|---|
サーバーの自動再起動を有効にします。障害の発生したサービスまたはハングアップしたサービスを自動的に再起動します。デフォルト: いいえ |
|
再試行失敗のタイムアウトです。ここに指定した時間内でサーバーに 3 回以上障害が発生すると、システムはサーバーの再起動を試行しなくなります。値 (秒単位で指定) は、msprobe の間隔 (local.schedule.msprobe) よりも長い時間に設定する必要があります。デフォルト: 600 秒 |
|
特定のサーバーが再起動されるまでのタイムアウトです。service は、imap、pop、http、cert、job_controller、smtp、lmtp、mmp、または ens のいずれかになります。 デフォルト: service.readtimeout の値を使用する |
|
警告メッセージが default ログファイルに記録されるまでの特定のサーバーの無応答時間 (秒) です。service は、imap、pop、http、cert、job_controller、smtp、lmtp、mmp、または ens のいずれかになります。 デフォルト: local.probe.warningthreshold |
|
警告メッセージが default ログファイルに記録されるまでのサーバーの無応答時間 (秒) です。 デフォルト: 5 秒 |
|
キューサイズが alarm.diskavail.msgalarmthreshold によって定義されたしきい値を超えているかどうかを確認するための MTA キューディレクトリです。 デフォルト: なし |
|
サーバーを再起動するまでのサーバーの無応答時間です。local.schedule.msprobe を参照してください。 デフォルト: 10 秒 |
|
msprobe の実行スケジュールです。この値は、crontab 形式でスケジュールを示す文字列です (表 18–10 を参照)。 |
|
サービスの障害を監視する watcher を有効にします。対象となるサービスは、IMAP、POP、HTTP、ジョブコントローラ、ディスパッチャー、メッセージストア (stored)、imsched、および MMP です。(LMTP/SMTP サーバーはディスパッチャーによって監視され、LMTP/SMTP クライアントは job_controller によって監視される。)それぞれの障害について、エラーメッセージをデフォルトのログファイルに記録します。デフォルト: on |
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」を参照してください。
表 23–6 有用な警告メッセージの configutil パラメータ
パラメータ |
説明 (括弧内はデフォルト) |
---|---|
(localhost) 警告メッセージの送信先のマシンです。 |
|
(25) 警告メッセージの送信時に接続する SMTP ポートです。 |
|
(Postmaster@localhost) 警告通知の送信先です。 |
|
(Postmaster@localhost) 警告の差出人のアドレスです。 |
|
(利用可能なメールパーティションのディスク容量のパーセンテージ) ディスク利用度の警告についての説明フィールドのテキストです。 |
|
(3600) ディスク利用度のチェック間隔 (秒) です。ディスク使用状況をチェックしない場合は、0 に設定します。 |
|
(10) 利用可能なディスク容量の割合です。この値を下回ると警告が送信されます。 |
|
(-1) 利用可能なディスク容量がしきい値 (-1) より低いか、しきい値 (1) より高いときに警告を発行するかどうかを指定します。 |
|
(24) ディスク利用度の警告が繰り返される間隔 (時) です。 |
|
(サーバーの応答時間を表す秒数)。サーバーの応答警告についての説明フィールドのテキストです。 |
|
(600) サーバー応答のチェックの間隔 (秒) です。サーバーの応答を確認しない場合は、0 に設定します。 |
|
(10) サーバー応答時間 (秒) がこの値を超えると、警告が発行されます。 |
|
(1) サーバー応答時間がしきい値より大きい (1) か、しきい値より小さい (-1) ときに、警告を発行するかどうかを指定します。 |
|
(24) サーバー応答警告が繰り返される間隔 (時) です。 |