ここでは、メッセージストアの監視の標準的な手順の概要を説明します。ここで説明する手順は、メッセージストアの全般的なチェック、テスト、および標準的な保守を行う場合に役立つものです。
その他の情報については、「メッセージストアを監視する」を参照してください。
メッセージストアには、十分な追加のディスク容量とハードウェアリソースが必要です。メッセージストアがディスク容量とハードウェア容量の上限に近づくと、メッセージストアに問題が発生することがあります。
ディスクの空き容量の不足は、メールサーバーで発生する問題や故障のうち、特に頻繁におきる原因の 1 つです。メッセージストアへ書き込むとき、そのための容量が不足していると、メールサーバーにエラーが発生します。さらに、利用可能なディスク容量が一定のしきい値より少なくなると、メッセージ配信やログ記録などに関連する多数の問題が発生します。stored プロセスのクリーンアップ機能が失敗し、削除されたメッセージがメッセージストアから消去されていないと、ディスク容量が急激に不足することがあります。
ディスク容量の監視の詳細については、「ディスク容量を監視するには」および 「メッセージストアを監視する」を参照してください。
ログファイルをチェックして、メッセージストアプロセスが設定どおりに実行されていることを確認します。Messaging Server は、サポートしている主なプロトコルまたはサービス (SMTP、IMAP、POP、および HTTP) ごとに一連のログファイルを作成します。ログファイルはコンソールを使用して表示するか、msg_svr_base/log/ ディレクトリで表示できます。ログファイルは定期的に監視する必要があります。
ログ記録はサーバーパフォーマンスに影響することがあります。より詳細なログ記録を指定するほど、一定期間にログファイルが多くのディスク容量を占有することになります。効果的に定義する必要がありますが、現実的なログローテーション、有効期間、サーバーのバックアップポリシーなどを考慮する必要があります。サーバーのログポリシーの定義の詳細は、第 21 章「ログの管理」を参照してください。
Messaging Server では、テレメトリと呼ばれる機能が提供されており、ユーザーの IMAP、POP、または Web メールのセッション全体をファイルに取得できます。この機能は、クライアント問題をデバッグするのに便利です。たとえば、メッセージアクセスクライアントが期待どおりに機能しないとユーザーが訴えた場合、この機能を使用してアクセスクライアントと Messaging Server 間の対話を記録することができます。
セッションの記録をとるには、次のディレクトリを作成します。
msg_svr_base/data/telemetry/ pop_or_imap/userid
Messaging Server によって、セッションにつき 1 ファイルがそのディレクトリに作成されます。出力例を次に示します。
LOGIN redb 2003/11/26 13:03:21 >0.017>1 OK User logged in <0.047<2 XSERVERINFO MANAGEACCOUNTURL MANAGELISTSURL MANAGEFILTERSURL >0.003>* XSERVERINFO MANAGEACCOUNTURL {67} http://redb@cuisine.blue.planet.com:800/bin/user/admin/bin/enduser MANAGELISTSURL NIL MANAGEFILTERSURL NIL 2 OK Completed <0.046<3 select "INBOX" >0.236>* FLAGS (\Answered flagged draft deleted \Seen $MDNSent Junk) * OK [PERMANENTFLAGS (\Answered flag draft deleted \Seen $MDNSent Junk \*)] * 1538 EXISTS * 0 RECENT * OK [UNSEEN 23] * OK [UIDVALIDITY 1046219200] * OK [UIDNEXT 1968] 3 OK [READ-WRITE] Completed <0.045<4 UID fetch 1:* (FLAGS) >0.117>* 1 FETCH (FLAGS (\Seen) UID 330) * 2 FETCH (FLAGS (\Seen) UID 331) * 3 FETCH (FLAGS (\Seen) UID 332) * 4 FETCH (FLAGS (\Seen) UID 333) * 5 FETCH (FLAGS (\Seen) UID 334) <etc> |
stored 機能は、存続期間決定ポリシーを実行したり、ディスクに保存されているメッセージを消去して、メッセージデータベースのデッドロック操作やトランザクション操作などの、さまざまな重要なタスクを実行します。stored が実行を停止すると、最終的には Messaging Server に問題が発生します。start-msg が実行されているときに stored が起動していないと、ほかのプロセスも起動しません。
stored プロセスが実行中かどうかをチェックします。stored -t -v を実行します。
store_root/mboxlist 内に作成されたログファイルをチェックします。
デフォルトログファイルの msg_svr_base/log/default/default 内の stored メッセージをチェックします。
stored プロセスによって以下の機能のいずれかが試行された場合は、必ず次のファイル (msg_svr_base/config/ ディレクトリ内) のタイムスタンプが更新されることを確認します。
stored 操作 |
説明 |
---|---|
stored.ckp |
データベースのチェックポイントが開始されたときに押されます。約 1 分ごとにスタンプが付けられます。 |
stored.lcu |
データベースログのクリーンアップごとに押されます。約 5 分ごとにタイムスタンプが付けられます。 |
stored.per |
ユーザー単位のデータベース書き込み時に押されます。タイムスタンプは 1 時間ごとに付けられます。 |
stored プロセスの詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の 「stored ユーティリティーを使用する」の章を参照してください。
stored 機能の監視の詳細については、「メッセージストアを監視する」を参照してください。
データベースログファイルは、sleepycat トランザクションのチェックポイントログファイル(store_root/mboxlist ディレクトリ内) を指します。ログファイルが蓄積されると、データベースのチェックポイント設定は行われません。通常は、単一の期間内に、2 つまたは 3 つのデータベースログファイルがあります。ログファイルがそれ以上ある場合は、問題がある可能性があります。
ユーザーフォルダをチェックする場合は、以下のコマンドを実行します。reconstruct -r -n (recursive no fix)。これにより、ユーザーフォルダおよびレポートのエラーを確認します。reconstruct コマンドの詳細については、「メールボックスとメールボックスデータベースの修復」を参照してください。
コアファイルは、プロセスが予期せず終了したときにのみ存在します。コアファイルを確認することは、メッセージストアに問題がありそうなときは特に重要です。Solaris の場合は、coreadm を使用して core ファイルの場所を設定します。