ログは、システムのサービスについてのタイムスタンプおよびラベルをシステムが提供する手段です。ログは、システムの現在のスナップショットおよび履歴ビューの両方を提供します。
Messaging Server のログファイルを理解して使用すると、次のことが可能です。
メッセージのサイズ、メッセージの配信の頻度、MTA を通るメッセージの数などの、メッセージの統計情報の収集
傾向の見極め
容量計画の関連付け
問題のトラブルシューティング
たとえば、サイトでユーザー数の増加に伴いディスク容量を追加する必要がある場合は、Messaging Server のログファイルを使用してシステムの要求がどの程度増加したかを確認し、必要な新しいディスクストレージの容量の計画を立てることができます。
また、Messaging Server のログを使用して、1 日にわたるメッセージングのパターンがどのようなものであるかを理解することができます。日々の負荷のピークがいつ発生するかを理解すると、容量計画を立てるのに役立ちます。
ログは、ユーザーの問題のトラブルシューティングにも役立ちます。たとえば、ユーザーが予期していたメールメッセージを受信しない場合、Messaging Server のログ機能を使用してユーザーのメールメッセージを追跡できます。そのようにすると、メッセージが自動的にフィルタ処理され、SPAM フォルダに送信されたために受信できなかったことがわかる場合があります。
処理データ
エラー状態、イベントログとも呼ばれる
ほとんどの場合、Messaging Server のログは処理データを提供します。この処理データには、メッセージがシステムに到着した日時、メッセージの送信者および受信者、メッセージがディスクに書き込まれたとき、その後、メッセージがディスクから削除され、ユーザーのメールボックスに入れられたときなどの情報が含まれます。
ただし、Messaging Server のログはイベントログデータも一部提供します。イベントログデータを入手するには、いくつかのログファイルから複数の項目を収集する必要があります。次に、メッセージ ID などの一意の定数を使用して、システムの 1 地点から次の地点へ通過するメッセージのライフサイクルを検索して関連付けを行うことができます。
Messaging Server のログには、次の 3 種類のログファイルがあります。
MTA ログ: これらのログは Message Transfer Agent で説明した処理データを提供します。
エラーログ: これらのログは MTA デバッグログおよび MTA サブコンポーネントログ (ジョブコントローラやディスパッチャーなど) です。
メッセージストアおよびサービスのログ: これらのログは、http サーバー、mshttpd、imap、および pop サービス、また管理サービスからのメッセージを提供します。これらの種類のログの形式は、最初の 2 種類のログとは異なります。
次の表は、異なる種類のログファイルを示しています。デフォルトでは、ログファイルは msg_svr_base/data/log ディレクトリにあります。各種類のログファイルを個別にカスタマイズしたり表示したりすることができます。
表 21–1 Messaging Server のログファイル
ログファイルの種類 |
ログファイルの説明 |
デフォルト名 |
---|---|---|
Message Transfer Agent |
日時情報、キューの出入り情報などの、MTA を通るメッセージトラフィックについての情報を表示します。 |
mail.log、mail.log_current、mail.log_yesterday |
接続 |
電子メールを送信するためにこのシステムに接続するリモートマシン (MTA) が含まれます。 |
connection.log |
カウンタ |
チャネルごとに送受信されたメッセージの傾向の情報が含まれます。 |
counters |
ジョブコントローラ |
マスター、ジョブコントローラ、送信者、およびキューからの取り出しチャネルプログラムのデータが含まれます。 |
job_controller.log |
ディスパッチャー |
ディスパッチャーに関連するエラーが含まれます。ディスパッチャーのデバッグをオンにすると、情報が増えます。 |
dispatcher.log |
チャネル |
チャネルに関連するエラーが記録されます。キーワードの master_debug と slave_debug は、チャネルのデバッグをオンにし、そのようにすると、チャネルのログファイルの情報がさらに詳細になります。情報のレベルおよび種類は、option.dat の各種 *_DEBUG MTA オプションで制御されます。 |
channelname_master.log* (例: tcp_local_master.log*) channelname_slave.log* (例: tcp_local_slave.log*) |
管理 |
管理サーバーを介したコンソールと Messaging Server 間の通信 (大半は複数の CGI プロセスを経る) に関連するログイベントが記録されます |
admin、admin.sequenceNum.timeStamp |
IMAP |
サーバーの IMAP4 アクティビティーに関連するログイベントが記録されます |
imap、imap.sequenceNum.timeStamp |
POP |
サーバーの POP3 アクティビティーに関連するログイベントが記録されます |
pop、pop.sequenceNum.timeStamp |
HTTP |
サーバーの HTTP アクティビティーに関連するログイベントが記録されます |
http、http.sequenceNum.timeStamp |
デフォルト |
サーバーのその他のアクティビティー (コマンド行ユーティリティーやその他のプロセスなど) に関連するログイベントが記録されます |
default、default.sequenceNum.timeStamp |
msgtrace |
メッセージストアについての追跡情報が含まれます。ファイルが短時間に非常に大きくなることがあります。それに合わせて監視します。 |
msgtrace |
watcher |
プロセスの失敗や応答しないサービスを監視し (表 4–4 を参照)、特定の障害を示すエラーメッセージを記録します。 |
watcher |
各項目の説明
sequenceNum - ログファイルディレクトリ内に作成されたログファイルの順番を表す整数を指定します。新しいログファイルほど、値が大きくなります。シーケンス番号はロールオーバーすることはなく、サーバーのインストール時に始まり、そのサーバーを使用している限り常に増え続けます。
timeStamp - ファイルが作成された日付と時刻を示す整数を指定します。この値は UNIX 標準の時刻形式で表されます。つまり、1970 年 1 月 1 日午前 0 時から経過した秒数です。
たとえば、imap.63.915107696 という名前のログファイルは、IMAP ログファイルのディレクトリで 63 番目に作成されたログファイルであり、1998 年 12 月 31 日午後 12 時 34 分 56 秒に作成されたログファイルです。
無制限のシーケンス番号をタイムスタンプと組み合わせることによって、解析するファイルのローテーション、有効期間、および選択がより柔軟になります。詳細は、「サービスログオプションを定義、設定する」を参照してください。
次の節では、システム内でのメッセージの流れについて、またどの時点で情報が各種ログファイルに書き込まれるかについて説明します。この説明は、問題のトラブルシューティングおよび解決のために Message Server のログファイルを使用する方法を理解するのに役立ちます。参考のために 図 8–2 を参照してください。
リモートホストはメッセージングホストの TCP ソケットに接続し、SMTP サービスを要求します。
MTA ディスパッチャーは要求に応答し、接続をメッセージジングホストの SMTP サービスに渡します。
MTA はモジュール方式になっているため、ジョブコントローラや SMTP サービスディスパッチャーを含む、1 組のプロセスから構成されています。ディスパッチャーは、着信 TCP 接続を受けて、SMTP サービスへ送信します。SMTP サービスは、メッセージをディスクのチャネル領域に書き込みます。SMTP サービスは、送信者や受信者などの、メッセージのエンベロープパラメータを認識します。システムの設定エントリは、メッセージがどのチャネル宛てかを示します。
ディスパッチャーは、スレッドをフォークし、そのスレッドを特定の IP アドレスからの着信接続に利用可能にしたことを dispatcher.log ファイルに書き込みます。
SMTP サーバーは、リモートホストが接続し、メッセージを送信した場合に行われた対話を記録し、tcp_smtp_server.log ファイルに書き込みます。このログファイルは、ディスパッチャーがホストの IP 上にある SMTP サーバーに接続を渡すときに作成されます。
SMTP サーバーは、tcp_intranet などのチャネルプログラム用のディスク上のキュー領域にメッセージを書き込み、ジョブコントローラに通知します。
ジョブコントローラは、チャネルプログラムにアクセスします。
チャネルプログラムはメッセージを配信します。
各チャネルには、それぞれのログファイルがあります。ただし、それらのログは通常チャネルの開始および停止を示します。さらに情報を得るには、そのチャネルのデバッグレベルを有効にする必要があります。ただし、そのようにするとシステムの処理速度が低下し、問題がさらに不明瞭になるので、実際に問題が発生している場合にのみデバッグレベルを有効にします。
効率性を向上させるため、すでに存在するプロセス用にチャネルが実行中である場合は、新しいメッセージが着信しても、システムは新しいチャネルプロセスを生成しません。現在実行されているプロセスが新しいメッセージを引き受けます。
メッセージは、別のホスト、別の TCP 接続などの、次のホップへ配信されます。この情報は connection.log ファイルに書き込まれます。
SMTP サーバーがディスク上のキュー領域にメッセージを書き込むと同時に、メッセージを管理するチャネルもレコードを mail.log_current、または mail.log ファイルに書き込みます。レコードは、メッセージがキューに入れられた日時、送信者、受信者などの情報を示します。詳細は、「MTA メッセージログの例」を参照してください。メッセージの追跡にもっとも役立つファイルは、mail.log_current ファイルです。