test

Sun Java System Messaging Server 6 2005Q4 管理ガイド

第 21 章 ログの管理

この章では、Messaging Server MTA、メッセージストア、およびサービスに対するログ機能の概要を示します。この章では、ログ機能の管理方法の手順も示します。

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

ログの概要

ログは、システムのサービスについてのタイムスタンプおよびラベルをシステムが提供する手段です。ログは、システムの現在のスナップショットおよび履歴ビューの両方を提供します。

Messaging Server のログファイルを理解して使用すると、次のことが可能です。

たとえば、サイトでユーザー数の増加に伴いディスク容量を追加する必要がある場合は、Messaging Server のログファイルを使用してシステムの要求がどの程度増加したかを確認し、必要な新しいディスクストレージの容量の計画を立てることができます。

また、Messaging Server のログを使用して、1 日にわたるメッセージングのパターンがどのようなものであるかを理解することができます。日々の負荷のピークがいつ発生するかを理解すると、容量計画を立てるのに役立ちます。

ログは、ユーザーの問題のトラブルシューティングにも役立ちます。たとえば、ユーザーが予期していたメールメッセージを受信しない場合、Messaging Server のログ機能を使用してユーザーのメールメッセージを追跡できます。そのようにすると、メッセージが自動的にフィルタ処理され、SPAM フォルダに送信されたために受信できなかったことがわかる場合があります。

ログデータのタイプ

一般に、ログは次の 2 つの情報を提供します。

ほとんどの場合、Messaging Server のログは処理データを提供します。この処理データには、メッセージがシステムに到着した日時、メッセージの送信者および受信者、メッセージがディスクに書き込まれたとき、その後、メッセージがディスクから削除され、ユーザーのメールボックスに入れられたときなどの情報が含まれます。

ただし、Messaging Server のログはイベントログデータも一部提供します。イベントログデータを入手するには、いくつかのログファイルから複数の項目を収集する必要があります。次に、メッセージ ID などの一意の定数を使用して、システムの 1 地点から次の地点へ通過するメッセージのライフサイクルを検索して関連付けを行うことができます。

Messaging Server のログファイルのタイプ

Messaging Server のログには、次の 3 種類のログファイルがあります。

  1. MTA ログ: これらのログは Message Transfer Agent で説明した処理データを提供します。

  2. エラーログ: これらのログは MTA デバッグログおよび MTA サブコンポーネントログ (ジョブコントローラやディスパッチャーなど) です。

  3. メッセージストアおよびサービスのログ: これらのログは、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 を参照してください。

  1. リモートホストはメッセージングホストの TCP ソケットに接続し、SMTP サービスを要求します。

  2. MTA ディスパッチャーは要求に応答し、接続をメッセージジングホストの SMTP サービスに渡します。

    MTA はモジュール方式になっているため、ジョブコントローラや SMTP サービスディスパッチャーを含む、1 組のプロセスから構成されています。ディスパッチャーは、着信 TCP 接続を受けて、SMTP サービスへ送信します。SMTP サービスは、メッセージをディスクのチャネル領域に書き込みます。SMTP サービスは、送信者や受信者などの、メッセージのエンベロープパラメータを認識します。システムの設定エントリは、メッセージがどのチャネル宛てかを示します。

  3. ディスパッチャーは、スレッドをフォークし、そのスレッドを特定の IP アドレスからの着信接続に利用可能にしたことを dispatcher.log ファイルに書き込みます。

  4. SMTP サーバーは、リモートホストが接続し、メッセージを送信した場合に行われた対話を記録し、tcp_smtp_server.log ファイルに書き込みます。このログファイルは、ディスパッチャーがホストの IP 上にある SMTP サーバーに接続を渡すときに作成されます。

  5. SMTP サーバーは、tcp_intranet などのチャネルプログラム用のディスク上のキュー領域にメッセージを書き込み、ジョブコントローラに通知します。

  6. ジョブコントローラは、チャネルプログラムにアクセスします。

  7. チャネルプログラムはメッセージを配信します。

    各チャネルには、それぞれのログファイルがあります。ただし、それらのログは通常チャネルの開始および停止を示します。さらに情報を得るには、そのチャネルのデバッグレベルを有効にする必要があります。ただし、そのようにするとシステムの処理速度が低下し、問題がさらに不明瞭になるので、実際に問題が発生している場合にのみデバッグレベルを有効にします。

    注 –

    効率性を向上させるため、すでに存在するプロセス用にチャネルが実行中である場合は、新しいメッセージが着信しても、システムは新しいチャネルプロセスを生成しません。現在実行されているプロセスが新しいメッセージを引き受けます。

  8. メッセージは、別のホスト、別の TCP 接続などの、次のホップへ配信されます。この情報は connection.log ファイルに書き込まれます。

    SMTP サーバーがディスク上のキュー領域にメッセージを書き込むと同時に、メッセージを管理するチャネルもレコードを mail.log_current、または mail.log ファイルに書き込みます。レコードは、メッセージがキューに入れられた日時、送信者、受信者などの情報を示します。詳細は、「MTA メッセージログの例」を参照してください。メッセージの追跡にもっとも役立つファイルは、mail.log_current ファイルです。

ログの管理用のツール

コンソールおよび configutil コマンドを使用して Messaging Server ログファイルの作成および管理のためのポリシーをカスタマイズできます。

メッセージストアログの場合、コンソールを使用してログの設定と表示を行うことができます。設定内容は、どのイベントを何件まで記録するかに影響します。これらの設定とその他の特徴を使用して、ログファイル解析時のログイベントの検索条件を微調整することができます。

MTA は別のログ機能を使用しているため、コンソールを使って MTA ログサービスを設定したり、ログを表示したりすることはできません。その代わり、設定ファイルに情報を指定することで、MTA のログ機能を設定します。

Messaging Server ではサポートされていないログ解析やレポート生成を行うには、別のツールを使用する必要があります。ログファイルは、テキストエディタや標準のシステムツールで操作できます。

正規表現による構文解析をサポートするスクリプト可能なテキストエディタを使用すると、この章で説明しているような特定の条件に基づくログエントリの検索や抽出を行い、その結果を並べ替えたり、集計や統計を行うこともできます。

UNIX 環境では、UNIX の syslog ファイルを操作するために開発された既存のレポート生成ツールを変更して使用することもできます。パブリックドメインの syslog 操作ツールを使用する場合は、そのツールにおいて、日付/時刻形式と、Messaging Server のログエントリにはあって syslog エントリにはない 2 つの特殊コンポーネント (facility と logLevel) の変更が必要になる場合があります。

MTA メッセージおよび接続のログの管理

MTA は、メッセージがキューに出し入れされるたびにログを作成することができます。また、ディスパッチャーエラーとデバッグ出力も生成できます。

チャネルごとにログを制御したり、すべてのチャネル上のメッセージアクティビティーのログを記録するよう指定することができます。初期設定では、すべてのチャネルでのログ記録が無効になっています。

詳細は、「MTA ログを有効にする」を参照してください。

ログを有効にすると、メッセージが MTA チャネルを通過するたびに msg_svr_base/data/log/mail* ファイルにエントリが書き込まれます。そのようなログエントリは、MTA (または特定のチャネル) を通過するメッセージの数についての統計情報を収集するのに役立ちます。それらのログエントリを使用して、メッセージが送信または配信されたかどうか、またいつ送信または配信されたかなどのその他の問題も調査できます。

毎晩午前 0 時頃に実行されるメッセージ返送ジョブは、累積されたログファイル mail.log に既存の mail.log_yesterday を追加し、現在の mail.log_current ファイルの名前を mail.log_yesterday に変更してから、新しい mail.log_current ファイルを開始します。また、connection.log* ファイルに対しても同様の処理が行われます。

MTA は自動的にロールオーバーを実行して現在のファイルを維持しますが、エントリが累積される mail.log ファイルは、ファイルのバックアップ、切り捨て、削除などのタスクのポリシーを決めて管理する必要があります。

ログファイルの管理方法を検討するときは、MTA の定期的な返送ジョブが、サイトが提供する msg_svr_base/bin/daily_cleanup プロシージャー (存在する場合) を実行することに注意してください。このため、サイトによっては独自のクリーンアップ方法を提供していることもあります。たとえば、古い mail.log ファイルの名前を週に 1 回 (または月に 1 回) 変更するなどです。

注 –

ログが有効になっていると、mail.log ファイルが大きくなり続けるため、そのままにしておくと利用可能なディスク容量がなくなってしまいます。このファイルのサイズを監視し、定期的に不要なコンテンツを削除してください。ファイル全体を削除することもできます。この場合、必要に応じて新しいファイルが作成されます。

MTA ログエントリの形式について

MTA ログファイルは、ASCII テキストとして記述されます。デフォルトでは、次に示すように、各ログファイルエントリには 8 個または 9 個のフィールドがあります。

19-Jan-1998 19:16:57.64 l tcp_local E 1 adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com

ログエントリには以下の情報が含まれています。

  1. エントリが記録された日付と時刻 (上の例では 19-Jan-1998 19:16:57.64)。

  2. ソースチャネルのチャネル名 (上の例では l)。

  3. 宛先チャネルのチャネル名 (上の例では tcp_local)。SMTP チャネルの場合、LOG_CONNECTION が有効になっているときは、プラス記号「+」が SMTP サーバーの受信を示し、マイナス記号「-」が SMTP クライアント経由の送信を示します。

  4. エントリのタイプ (上の例では E)。表 21–2 を参照。

  5. メッセージのサイズ (上の例では 1)。デフォルトでは K バイト単位で表されますが、MTA オプションファイルで BLOCK_SIZE キーワードを使用して単位を変更することもできます。

  6. エンベロープ From: アドレス (上の例では adam@sesta.com)。通知メッセージのようにエンベロープ From: アドレスが空のメッセージの場合、このフィールドは空白です。

  7. エンベロープ To: アドレスの元の形式 (上の例では marlowe@siroe.com)。

  8. エンベロープ To: アドレスの元の形式 (上の例では marlowe@siroe.com)。

  9. 配信ステータス (SMTP チャネルのみ)。

次の表に、ログエントリコードの説明を示します。

表 21–2 ログエントリのコード

エントリ 

説明 

B 

不良コマンドが SMTP サーバーに送信されました。受取人アドレスフィールドには拒否されたコマンドが、診断フィールドには SMTP サーバーからの応答が含まれます。MTA チャネルオプションの MAX_B_ENTRIES は、特定のセッションでログされる不良コマンドの数を制御します。デフォルトは 10 です。 

BA 

トランザクションの前の方で認証が成功したあとの不良コマンドです。 

BS 

TLS の起動に成功したあとの不良コマンドです。 

BSA 

TLS や AUTH での不良コマンドです。 

D 

キューからの取り出しに成功しました 

DA 

SASL (認証) でのキューからの取り出しに成功しました 

DS 

TLS (セキュリティー) でのキューからの取り出しに成功しました 

DSA 

TLS および SASL (セキュリティーと認証) でのキューからの取り出しに成功しました 

E 

キューに入れます 

EA 

SASL (認証) でキューに入れることに成功しました 

ES 

TLS (セキュリティー) でキューに入れることに成功しました 

ESA 

TLS および SASL (セキュリティーと認証) でキューに入れることに成功しました 

J 

キューに入れる試行が拒否されました (スレーブチャネルプログラムによる拒否) 

K 

受取メッセージが拒否されました。差出人が NOTIFY=NEVER DSN フラグの設定を要求した場合、メッセージがタイムアウトになった場合、またはメッセージが手動で返された場合です。たとえば、imsimta qm “delete” コマ ンドは常に各受取人の「K」レコードを生成しますが、qm “return” コマ ンドが「R」レコードではなく「K」レコードを生成する場合です。これは、差出人自身の要求によって、通知が差出人に送信されなかったことを示します。

これは、同じ種類の拒否またはタイムアウトである「R」レコードと比較できますが、「R」レコードでは、この失敗したメッセージに関して、元の差出人に戻される新しい通知メッセージも生成されます。 

Q 

キューからの取り出しで一時的に失敗しました 

R 

キューからの取り出し試行で受取人アドレスが拒否され (マスターチャネルプログラムによる拒否)、失敗またはバウンスメッセージが生成されました 

V 

トランザクションが異常終了したときに表示される警告メッセージです。キューに入れられた受取人アドレスごとに、V レコードは 1 つになります。 

W 

メッセージはまだ配信されていませんが、キューに残っていて再配信が試行されていることを元の差出人に通知するために送信された警告メッセージです。 

Z 

数人の受取人に対しては成功しましたが、この受取人に対しては一時的に失敗しました。すべての受取人の元のメッセージファイルはキューから取り出され、それに代わって新しいメッセージファイルが入れられ、その他の失敗した受取人がすぐにキューに入れられます 

SMTP チャネルの LOG_CONNECTION + または ? エントリ 

C 

接続が終了しました。診断フィールドがあとに続きます。connection.log_current (ログファイルが 1 つしか使用されない場合は mail.log_current) に書き込まれます。接続が終了した理由を記録するために使用されます。特に、なんらかのセッション切断制限に達したために接続が終了した場合は、その情報が診断フィールドに表示されます。 

O 

接続が開始しました 

U 

ログの SMTP 認証が成功および失敗しました。形式はほかの O エントリや C エントリと同じです。特に、同じアプリケーションや転送情報のフィールドが同じ順序で表示されます。ユーザー名が明らかな場合は、ユーザー名フィールドに記録されます。このエントリは、LOG_CONNECTION MTA オプションのビット 7 (値は 128) によって制御されます。 

X 

接続が拒否されました 

Y 

接続が確立される前に試行に失敗しました 

I 

ETRN コマンドを受信しました 

LOG_CONNECTION、LOG_FILENAME、LOG_MESSAGE_ID、LOG_NOTARY、LOG_PROCESS、および LOG_USERNAME がすべて MTA オプションファイルで有効になっている場合、形式は次に示されているようになります。この例のログエントリ行は改行されて表示されていますが、実際のログエントリは 1 行で記述されます。


19-Jan-1998 13:13:27.10 HOSTA   2e2d.2.1 tcp_local   l
 E 1 service@siroe.com rfc822;adam@sesta.com
 adam 276 /imta/queue/l/ZZ01IWFY9ELGWM00094D.00
 <01IWFVYLGTS499EC9Y@siroe.com> inetmail
 siroe.com (siroe.com [192.160.253.66])

前述の説明に含まれていない追加のフィールドは、以下のとおりです。

  1. チャネルプロセスを実行しているノードの名前 (例では HOSTA)。

  2. プロセス ID (16 進数) と、その後ろに続くピリオド (ドット) 文字と数。これがマルチスレッドチャネルエントリ (つまり、tcp_* チャネルエントリ) であった場合、プロセス ID と数の間にスレッド ID も存在します。この例では、プロセス ID は 2e2d.2.1 です。

  3. メッセージの NOTARY (配達証明書要求) フラグ。整数値で表記 (例では 276) します。

  4. MTA キュー領域内のファイル名 (例では /imta/queue/l/ZZ01IWFY9ELGWM00094D.00)。

  5. メッセージ ID (例では <01IWFVYLGTS499EC9Y@siroe.com>)。

  6. 実行プロセスの名前 (例では inetmail)。UNIX での SMTP サーバーなどのディスパッチャープロセスの場合、通常は inetmail (SASL を使用しなかった場合) になります。

  7. 接続情報 (例では siroe.com (siroe.com [192.160.253.66]))。接続情報は、送信システムが HELO/EHLO 行に示す名前 (着信 SMTP メッセージの場合) や、チャネルの正規のホスト名 (ほかの種類のチャネルの場合) など、送信システムまたはチャネル名で構成されています。TCP/IP チャネルの場合、送信システムの「実際の」名前、つまり、DNS リバース検索によってレポートされるシンボリック名や IP アドレスは、ident* チャネルキーワードを使用して括弧内にレポートすることもできます。「IDENT 検索」を参照してください。この例は、DNS によって見つかった名前と IP アドレスの両方を表示するように指定するキーワードの 1 つ ( たとえば、デフォルトの identnone キーワード) が使用されていると仮定しています。

MTA ログを有効にする

少数の特定の MTA チャネルの統計情報を収集するには、対象となる MTA チャネルのみのログチャネルキーワードを有効にします。ほとんどのサイトでは、すべての MTA チャネルでのログを有効にしています。特に、問題を突き止める場合、問題を診断する最初のステップは、メッセージが意図していたチャネルに送られているかどうかに注目することです。すべてのチャネルに対してログを有効にしておくと、このような問題を調べる際に役立ちます。

Procedure特定のチャネルの MTA のログを有効にする

手順

  1. imta.cnf ファイルを編集します。

    このファイルは /opt/SUNWmsgsr/config ディレクトリにあります。

  2. 特定のチャネルに対してログの作成を有効にするには、チャネル定義で logging キーワードを追加します。例: 


    channel-name keyword1 keyword2 logging

    また、ログファイルやログレベルなどのディレクトリパスのような設定パラメータの数も、設定することができます。「メッセージストア、管理、およびデフォルトのサービスログの管理」を参照してください。

Procedureすべてのチャネルの MTA ログを有効にする

手順

  1. imta.cnf ファイルを編集します。

    このファイルは /opt/SUNWmsgsr/config ディレクトリにあります。

  2. defaults チャネルにログキーワードを追加します (「チャネルのデフォルトを設定する」を参照)。例: 


    defaults logging notices 1 2 4 7 copywarnpost copysendpost postheadonly 
noswitchchannel immnonurgent maxjobs 7 defaulthost siroe.com

l defragment charset7 us-ascii charset8 iso-8859-01
siroe.com

その他の MTA ログオプションの指定

ログが有効になっているときに与えられる基本的な情報のほかにも、MTA オプションファイルにさまざまな LOG_*MTAオプションを設定することにより、オプションの情報フィールドを含めることができます。IMTA テイラーファイル (msg_svr_base/config/imta_tailor) の IMTA_OPTION_FILE オプションで指定されたファイルで、MTA オプションファイルを指定します。デフォルトでは、これは msg_svr_base/config/option.dat ファイルです。

MTA オプションファイルの詳細は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「Option File」を参照してください。

ProcedureMTA ログを syslog へ送信する

手順

  1. MTA オプションファイルを編集します。

  2. LOG_MESSAGES_SYSLOG オプションを 1 に設定します。

    0 の値はデフォルトであり、syslog (イベントログ) のログが実行されなかったことを示します。

Procedureログメッセージエントリを関連付ける

手順

  1. MTA オプションファイルを編集します。

  2. LOG_MESSAGE_ID オプションを 1 に設定します。

    0 の値はデフォルトであり、メッセージ ID が mail.log ファイルに保存されなかったことを示します。

Procedureメッセージの配信再試行を確認する

手順

  1. MTA オプションファイルを編集します。

  2. LOG_FILENAME オプションを 1 に設定します。

    このオプションを使用すると、特定のメッセージファイルの配信が何回再試行されたかを即座に簡単に確認できます。このオプションは、MTA が複数の受信者へのメッセージをディスク上で別々のメッセージファイルコピーに分割する場合としない場合を把握するのにも役立ちます。

ProcedureTCP/IP 接続のログを記録する

手順

  1. MTA オプションファイルを編集します。

  2. LOG_CONNECTION オプションを設定します。

    このオプションを使用すると、MTA は TCP/IP 接続とメッセージトラフィックのログを記録します。接続ログエントリは、デフォルトで mail.log* ファイルに書き込まれます。さらに、接続ログエントリを connection.log* ファイルに書き込むことも可能です。詳細は、SEPARATE_CONNECTION_LOG オプションを参照してください。

Procedureconnection.log ファイルにエントリを書き込む

手順

  1. MTA オプションファイルを編集します。

  2. SEPARATE_CONNECTION_LOG オプションを 1 に設定します。

    このオプションを使用して、ログエントリを connection.log ファイルに代わりに書き込むことを指定できます。デフォルト値の 0 は、接続ログを MTA ログファイルに格納します。

Procedureプロセス ID でログメッセージを関連付ける

手順

  1. MTA オプションファイルを編集します。

  2. LOG_PROCESS オプションを設定します。

    LOG_CONNECTION とともに使用すると、このオプションは接続エントリとそれに対応するメッセージエントリの相関関係をプロセス ID によって示すことができます。

Procedureメールを mail.log ファイルのキューに入れるプロセスに関連付けられたユーザー名を保存する

手順

  1. MTA オプションファイルを編集します。

  2. LOG_USERNAME オプションを設定します。

    このオプションは、メールをキューに入れるプロセスに関連付けられたユーザー名を mail.log ファイルに保存するかどうかを制御します。SASL (SMTP AUTH) を使用している SMTP 送信の場合は、ユーザー名フィールドが認証ユーザー名 (プレフィックスとしてアスタリスクが付いたもの) になります。

MTA メッセージログの例

MTA メッセージファイルに記録されるフィールドの形式とフィールドのリストは、設定したログオプションによって異なります。ここでは、いくつかの典型的なログエントリの解釈の例を示します。その他のオプションのフィールドについては、「その他の MTA ログオプションの指定」を参照してください。

注 –

ここではログファイルエントリが複数行にわたって表示されていますが、実際のログファイルエントリは 1 行で記述されます。

ログファイルを確認するときは、通常のシステムでは一度に多くのメッセージが処理されていることに留意してください。通常、特定のメッセージに関連するエントリは、同時に処理されているその他のメッセージに関連するエントリの間に散らばっています。基本的なログ情報は、MTA を通過するメッセージの数が全部でいくつあるかを把握するのに役立ちます。

同じ受取人への同じメッセージに関連する特定のエントリを関連付ける場合は、LOG_MESSAGE_ID を有効にします。特定のメッセージを MTA キュー領域にある特定のファイルと関連付けたり、エントリを見てキューからの取り出しに成功していない特定のメッセージの配信を何回試行したかを確認する場合は、LOG_FILENAME を有効にします。SMTP メッセージ (TCP/IP チャネル経由で処理されるメッセージ) の場合、リモートシステムとの TCP 接続を送信メッセージと関連付けるには、LOG_PROCESS と何らかのレベルの LOG_CONNECTION を有効にします。

MTA ログの例: ユーザーがメッセージを送信する場合

ローカルユーザーが送信 TCP/IP チャネルからインターネットなどにメッセージを送信する場合に見られる、基本的なログエントリの例を次に示します。この例では、LOG_CONNECTION が有効になっています。(1) と (2) の行は 1 つのエントリで、実際のログファイルでは 1 行で記述されます。同様に、(3) 〜 (7) の行も 1 つのエントリで、実際のログファイルでは 1 行で記述されます。

例 21–1 MTA ログ: ローカルユーザーが送信メッセージを送った場合


19-Jan-1998 19:16:57.64 l            tcp_local    E 1         (1)
 adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com     (2)
 
 19-Jan-1998 19:17:01.16 tcp_local                  D 1        (3)
 adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com     (4)
 dns;thor.siroe.com
 (TCP|206.184.139.12|2788|192.160.253.66|25)                   (5)
 (THOR.SIROE.COM -- Server ESMTP [iMS V5.0 #8694])             (6)
 smtp;250 2.1.5 marlowe@siroe.com and options OK.              (7)

  1. この行は、1 ブロック (1) メッセージをチャネル l からチャネル tcp_local のキューに入れた (E) ときの日付と時刻を示します。

  2. この部分は、実際にはログファイルでは (1) と同じ行に表示されます。エンベロープ From: アドレス ( この例では adam@sesta.com) と、エンベロープ To: アドレスの元のバージョンと現在のバージョン (この例では marlowe@siroe.com) を示しています。

  3. 1 ブロック (1) メッセージを tcp_local チャネルのキューから取り出した (D) ときの日付と時刻を示しています。つまり、tcp_local チャネルがリモートの SMTP サーバーへの送信に成功したことを示しています。

  4. エンベロープ From: アドレス、元のエンベロープ To: アドレス、および現在の形式のエンベロープ To: アドレスを示しています。

  5. 接続先の実際のシステムの名前が DNS で thor.siroe.com であること、ローカルの送信システムの IP アドレスが 206.184.139.12 で、ポート 2788 から送信されていること、リモートの宛先システムの IP アドレスが 192.160.253.66 で、接続ポートが 25 であることを示しています。

  6. リモートの SMTP サーバーの SMTP 見出し行を示しています。

  7. このアドレスに返された SMTP ステータスコードを示しています。250 は基本的な SMTP 成功コードであり、このリモート SMTP サーバーは拡張 SMTP ステータスコードと追加テキストで応答しています。

MTA ログの例: オプションのログフィールドを含む場合

これは、例 21–3 に示されているログエントリと似ていますが、LOG_MESSAGE_ID=1 を設定することによりファイル名とメッセージ ID も記録されています。(1) と (2) を参照してください。特に、メッセージ ID は、エントリとそれに関連するメッセージの相関関係を示すために使われます。

例 21–2 MTA ログ: オプションのログフィールドを含む場合


19-Jan-1998 19:16:57.64 l            tcp_local    E 1
  adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com
  /imta/queue/tcp_local/ZZ01ISKLSKLZLI90N15M.00
   <01ISKLSKC2QC90N15M@sesta.com>    (1)
                  
 19-Jan-1998 19:17:01.16 tcp_local                  D 1
  adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com
  /imta/queue/tcp_local/Z01ISKLSKLZLI90N15M.00
    <01ISKLSKC2QC90N15M@sesta.com>   (2)
  dns;thor.siroe.com (TCP|206.184.139.12|2788|192.160.253.66|25)
  (THOR.SIROE.COM -- Server ESMTP [iMS V5.0 #8694])
  smtp;250 2.1.5 marlowe@siroe.com and options OK.

MTA ログの例: リストに送信する場合

この例は、LOG_FILENAME=1、LOG_MESSAGE_ID=1、および LOG_CONNECTION=1 を有効にして、複数の受取人に送信する例を示しています。ここでは、ユーザー adam@sesta.com が MTA メーリングリスト test-list@sesta.com に送信し、それが bob@sesta.com、carol@varrius.com、および david@varrius.com に展開されています。それぞれの受取人の元のエンベロープ To: アドレスは test-list@sesta.com ですが、現在のエンベロープ To: アドレスは受取人ごとに異なるアドレスであることに注意してください。2 つのファイル (チャネル l と送信チャネル tcp_local 用) がありますが、メッセージ ID は同じです。

例 21–3 MTA ログ: リストに送信する場合


19-Jan-1998 20:01:44.10 l    l                    E 1
  adam@sesta.com rfc822;test-list@sesta.com bob
  imta/queue/l/ZZ01ISKND3DE1K90N15M.00
  <01ISKND2H8MS90N15M@sesta.com>
 
 19-Jan-1998 20:01:44.81 l            tcp_local    E 1
  adam@sesta.com rfc822;test-list@sesta.com carol@varrius.com
  imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00 
  <01ISKND2H8MS90N15M@sesta.com>
 
 19-Jan-1998 20:01:44.81 l            tcp_local    E 1
  adam@sesta.com rfc822;test-list@sesta.com david@varrius.com
  imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00
 <01ISKND2H8MS90N15M@sesta.com>
 
 19-Jan-1998 20:01:50.69 l                         D 1
  adam@sesta.com rfc822;test-list@sesta.com bob
  imta/queue/l/ZZ01ISKND3DE1K90N15M.00
  <01ISKND2H8MS90N15M@sesta.com>
 
 19-Jan-1998 20:01:57.36 tcp_local                  D 1
  adam@sesta.com rfc822;test-list@sesta.com carol@varrius.com
  imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00
  <01ISKND2H8MS90N15M@sesta.com>
  dns;gw.varrius.com (TCP|206.184.139.12|2788|192.160.253.66|25)
  (gw.varrius.com -- SMTP Sendmail)
  smtp;250 OK.
 
 19-Jan-1998 20:02:06.14 tcp_local                  D 1
  adam@sesta.com rfc822;test-list@sesta.com david@varrius.com
  imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00
  <01ISKND2H8MS90N15M@sesta.com>
  dns;gw.varrius.com (TCP|206.184.139.12|2788|192.160.253.66|25)
  (gw.varrius.com -- SMTP Sendmail)
  smtp;250 OK.

MTA ログ: 存在しないドメインに送信する場合

この例では、存在しないドメイン (ここでは very.bogus.com) への送信の試行を示しています。つまり、存在しないことが MTA の書き換えルールによって通知されないドメイン名であり、また、送信 TCP/IP チャネルに一致するドメイン名に送信しようとしました。この例では、LOG_FILENAME=1 と LOG_MESSAGE_ID=1 という MTA オプションが設定されていると仮定しています。

TCP/IP チャネルが作動していて、DNS のドメイン名をチェックしているとき、DNS はそのような名前は存在しないというエラーを返します。(5) の「拒否」エントリ (R) のように DNS はエラーを返し、(6) のようにドメイン名が不正であることを示します。

メッセージが発行されたあとでアドレスが拒否されたため、MTA は元の差出人へのバウンスメッセージを生成します。MTA は新しい拒否メッセージを元の差出人のキューに入れ (1)、元の送信メッセージを削除する ((5) の R エントリ) 前にポストマスターにコピーを送信します (4)。

(2) と (8) に示すように、バウンスメッセージなどの通知メッセージには空のエンベロープ From: アドレスがあります。エンベロープ From: フィールドは空白で示されています。MTA が生成したバウンスメッセージが最初にキューに入れられることにより、新しい通知メッセージのメッセージ ID の後ろに元のメッセージのメッセージ ID が表示されます (3)(この情報は MTA で常に利用できるわけではないが、利用できる場合は、失敗した送信メッセージに対応するログエントリを、通知メッセージに対応するログエントリに関連付けることができる)。この通知メッセージは、プロセスチャネルのキューに入れられたあと、該当する宛先チャネルのキューに入れられます (7)。

例 21–4 MTA ログ: 存在しないドメインに送信する場合


19-JAN-1998 20:49:04 l            tcp_local    E 1
  adam@sesta.com rfc822;user@very.bogus.com user@very.bogus.com
  imta/queue/tcp_local/ZZ01ISKP0S0LVQ94DU0K.00
 <01ISKP0RYMAS94DU0K@SESTA.COM>
 
19-JAN-1998 20:49:33 tcp_local    process      E 1                (1)
 rfc822;adam@sesta.com adam@sesta.com                             (2)
 imta/queue/process/ZZ01ISKP0S0LVQ94DTZB.00
 <01ISKP22MW8894DTAS@SESTA.COM>,<01ISKP0RYMAS94DU0K@SESTA.COM>    (3)

19-JAN-1998 20:49:33 tcp_local    process      E 1                (4)
 rfc822;postmaster@sesta.com postmaster@sesta.com
 imta/queue/process/ZZ01ISKP0S0LVQ94DTZB.00
 <01ISKP22MW8894DTAS@SESTA.COM>,<01ISKP0RYMAS94DU0K@SESTA.COM>
 
19-JAN-1998 20:50:07 tcp_local                  R 1               (5)
 adam@sesta.com rfc822;user@very.bogus.com user@very.bogus.com
 imta/queue/tcp_local/ZZ01ISKP0S0LVQ94DU0K.00
 <01ISKP0RYMAS94DU0K@SESTA.COM>
 Illegal host/domain name found                                   (6)

19-JAN-1998 20:50:08 process      l            E 3                (7)
 rfc822;adam@sesta.com adam                                       (8)
 imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
 <01ISKP22MW8894DTAS@SESTA.COM>
 
19-JAN-1998 20:50:08 process      l            E 3
  rfc822;postmaster@sesta.com postmaster
  imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
 <01ISKP22MW8894DTAS@SESTA.COM>
 
19-JAN-1998 20:50:12 l                         D 3
  rfc822;adam@sesta.com adam
  imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
  <01ISKP22MW8894DTAS@SESTA.COM>
 
19-JAN-1998 20:50:12 l                         D 3
  rfc822;postmaster@sesta.com postmaster
  imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
  <01ISKP22MW8894DTAS@SIROE.COM>

MTA ログの例: 存在しないリモートユーザーに送信する場合

ここでは、リモートシステムの不正アドレスに送信しようとした場合の例を示します。この例では、LOG_FILENAME=1 および LOG_MESSAGE_ID=1 という MTA オプションと、LOG_BANNER=1 および LOG_TRANSPORTINFO=1 というチャネルオプションが設定されていると仮定しています。(1) の拒否エントリ (R) に注意してください。例 21–4 の拒否エントリとは異なり、この例の拒否エントリではリモートシステムに接続されたことが示されており、また、(2)、(3) にリモート SMTP サーバーが発行した SMTP エラーコードが示されています。(2) に示されている情報は、LOG_BANNER=1 および LOG_TRANSPORTINFO=1 というチャネルオプションが設定されていることを前提としています。

例 21–5 MTA ログ: 存在しないリモートユーザーに送信する場合


20-JAN-1998 13:11:05 l            tcp_local    E 1
  adam@sesta.com rfc822;nonesuch@siroe.com nonesuch@siroe.com
  imta/queue/tcp_local/ZZ01ISLNBB1JOE94DUWH.00
  <01ISLNBAWV3094DUWH@sesta.com>
 
20-JAN-1998 13:11:08 tcp_local    process      E 1
  rfc822;adam@sesta.com adam@sesta.com
  imta/queue/process/ZZ01ISLNBB1JOE94DSGB.00
  <01ISLNBFKIDS94DUJ8@sesta.com>,<01ISLNBAWV3094DUWH@sesta.com>
 
 20-JAN-1998 13:11:08 tcp_local    process      E 1
  rfc822;postmaster@sesta.com postmaster@sesta.com
  imta/queue/process/ZZ01ISLNBB1JOE94DSGB.00
  <01ISLNBFKIDS94DUJ8@sesta.com>,<01ISLNBAWV3094DUWH@sesta.com>
 
20-JAN-1998 13:11:11 tcp_local                  R 1       (1)
  adam@sesta.com rfc822;nonesuch@siroe.com nonesuch@siroe.com
  imta/queue/tcp_local/ZZ01ISLNBB1JOE94DUWH.00 
  <01ISLNBAWV3094DUWH@sesta.com>
  dns;thor.siroe.com
  (TCP|206.184.139.12|2788|192.160.253.66|25)             (2)
  (THOR.SIROE.COM -- Server ESMTP [iMS V5.0 #8694])
  smtp; 553 unknown or illegal user: nonesuch@siroe.com   (3)
 
20-JAN-1998 13:11:12 process      l            E 3
  rfc822;adam@sesta.com adam
  imta/queue/l/ZZ01ISLNBGND1094DQDP.00
  <01ISLNBFKIDS94DUJ8@sesta.com>
 
20-JAN-1998 13:11:12 process      l            E 3
  rfc822;postmaster@sesta.com postmaster
  imta/queue/l/ZZ01ISLNBGND1094DQDP.00
  <01ISLNBFKIDS94DUJ8@sesta.com>
 
20-JAN-1998 13:11:13 l                         D 3
  rfc822;adam@sesta.com adam@sesta.com
  imta/queue/l/ZZ01ISLNBGND1094DQDP.00
  <01ISLNBFKIDS94DUJ8@sesta.com>
 
20-JAN-1998 13:11:13 l                         D 3
  rfc822;postmaster@sesta.com postmaster@sesta.com
  imta/queue/l/ZZ01ISLNBGND1094DQDP.00
  <01ISLNBFKIDS94DUJ8@sesta.com>

MTA ログの例: リモート側のメッセージ送信試行が拒否される場合

この例では、MTA がリモート側のメッセージ送信の試行を拒否した場合のログエントリを示します。この例では、有効になっている LOG_* オプションがないと仮定されているため、基本的なフィールドだけがエントリにログ記録されています。LOG_CONNECTION オプションを有効にすると、J エントリなどにその他の情報フィールドが追加されます。これは、ORIG_SEND_ACCESS マッピングを使って SMTP リレーブロッキング (「SMTP リレーブロッキングを設定する」を参照) が設定されている MTA の場合の例です。

ORIG_SEND_ACCESS

! ...多数のエントリを省略...
!
   tcp_local|*|tcp_local|*   $NRelaying$ not$ permitted

alan@very.bogus.com は内部アドレスではありません。したがって、リモートユーザー harold@varrius.com が MTA システムを介してリモートユーザー alan@very.bogus.com にリレーしようとしても、拒否されます。

例 21–6 MTA ログ: リモート側のメッセージ送信試行が拒否される場合


28-May-1998 12:02:23 tcp_local            J 0               (1)
 harold@varrius.com rfc822; alan@very.bogus.com             (2)
 550 5.7.1 Relaying not permitted: alan@very.bogus.com      (3)

  1. このログは、MTA がリモート側のメッセージ送信の試行を拒否した日付と時刻を示しています。拒否は J レコードで示されています。MTA チャネルが拒否されるメッセージを送信しようとすると、例 21–4 と 例 21–5 で示されているように R レコードで示されます。

    注 –

    ログに書き込まれた最後の J レコードは、特定のセッションの最後のレコードであることを示します。また、Messaging Server の現在のバージョンは J レコードの数を制限しません。

  2. 試行されたエンベロープ From: および To: アドレスが示されています。この場合、利用できる元のエンベロープ To: 情報がなかったため、フィールドは空です。

  3. このエントリには、MTA がリモート (試行した差出人) 側に発行した SMTP エラーメッセージが含まれています。

MTA ログの例: 配信試行が複数回行われた場合

ここでは、メッセージを最初の試行で配信できなかったために、MTA が何度もメッセージを送信しようとする場合のログエントリの例を示します。この例では、LOG_FILENAME=1 と LOG_MESSAGE_ID=1 というオプションが設定されていると仮定しています。

例 21–7 MTA ログ: 配信試行が複数回行われた場合


15-Jan-1998 10:31:05.18 tcp_internal   tcp_local   E 3          (1)
 adam@hosta.sesta.com rfc822;user@some.org user@some.org
 imta/queue/tcp_local/ZZ01IS3D2ZP7FQ9UN54R.00 
 <01IRUD7SVA3Q9UN2D4@sesta.com>
 
15-Jan-1998 10:31:10.37 tcp_local                  Q 3          (2)
 adam@hosta.sesta.com rfc822;user@some.org user@some.org
 imta/queue/tcp_local/ZZ01IS3D2ZP7FQ9UN54R.00                   (3)
 <01IRUD7SVA3Q9UN2D4@sesta.com>
 TCP active open: Failed connect()    Error: no route to host   (4)
 
     ...several hours worth of entries...

15-Jan-1998 12:45:39.48 tcp_local                  Q 3          (5)
  adam@hosta.sesta.com rfc822;user@some.org user@some.org
  imta/queue/tcp_local/ZY01IS3D2ZP7FQ9UN54R.00                  (6)
  <01IRUD7SVA3Q9UN2D4@sesta.com>
  TCP active open: Failed connect()    Error: no route to host
 
  ...several hours worth of entries...

 15-Jan-1998 16:45:24.72 tcp_local                  Q 3
  adam@hosta.sesta.com rfc822;user@some.org user@some.org
  imta/queue/tcp_local/ZX01IS67NY4RRK9UN7GP.00                  (7)
                   <01IRUD7SVA3Q9UN2D4@sesta.com>
  TCP active open: Failed connect() Error: connection refused   (8)

  ...several hours worth of entries...

 15-Jan-1998 20:45:51.55 tcp_local                  D 3         (9)
  adam@hosta.sesta.com rfc822;user@some.org user@some.org
  imta/queue/tcp_local/ZX01IS67NY4RRK9UN7GP.00
  <01IRUD7SVA3Q9UN2D4@sesta.com>
  dns;host.some.org (TCP|206.184.139.12|2788|192.1.1.1|25)
  (All set, fire away)
  smtp; 250 Ok

  1. メッセージは tcp_internal チャネルに入ります。これは、おそらく POP または IMAP クライアント、または SMTP リレーとして MTA を使用している組織内の別のホストから来たものです。MTA はこれを送信 tcp_local チャネルのキューに入れます。

  2. 最初の配信試行に失敗しています。これは Q エントリで示されています。

  3. これが最初の配信試行であることは、ZZ* ファイル名からわかります。

  4. この配信試行は、TCP/IP パッケージがリモート側への経路を見つけられなかったために失敗しました。例 21–4 とは異なり、DNS は宛先ドメイン名 some.org を否定していません。「no route to host」」というエラーは、送信側と受信側の間にネットワーク上の問題があることを示しています。

  5. MTA の定期的なジョブの次の実行時に、配信が再試行され、再び失敗しています。

  6. ここでファイル名が ZY* になり、2 回目の試行であることを示しています。

  7. ファイル名が ZX* になり、3 回目の失敗した試行であることを示しています。

  8. 定期的なジョブが配信を再試行し、再び失敗しています。ただし、ここでは TCP/IP パッケージがリモートの SMTP サーバーに接続できなかったことが示されているのではなく、リモートの SMTP サーバーが接続を受け入れないことを示しています。リモート側のネットワーク上の問題は解決されても、SMTP サーバーをまだ起動していない、またはその SMTP サーバーのメッセージ処理が追いつかないなどの理由で、MTA が接続しようとした時点で接続が受け入れられなかったことが考えられます。

  9. メッセージがキューから取り出されています。

MTA ログ: 変換チャネルを通過する着信 SMTP メッセージ

ここでは、メッセージが変換チャネルを通過する場合の例を示します。このサイトには、以下のような CONVERSIONS マッピングテーブルがあると仮定しています。

CONVERSIONS
  IN-CHAN=tcp_local;OUT-CHAN=l;CONVERT   Yes

この例では、LOG_FILENAME=1 と LOG_MESSAGE_ID=1 というオプションが設定されていると仮定しています。

例 21–8 MTA ログ: 変換チャネルを通過する着信 SMTP メッセージ


04-Feb-1998 00:06:26.72 tcp_local    conversion   E 9      (1)
  amy@siroe.edu rfc822;bert@sesta.com bert@sesta.com
  imta/queue/conversion/ZZ01IT5UAMZ4QW98518O.00
  <01IT5UALL14498518O@siroe.edu>
 
 04-Feb-1998 00:06:29.06 conversion   l            E 9     (2)
                   amy@siroe.edu rfc822;bert@sesta.com bert
  imta/queue/l/ZZ01IT5UAOXLDW98509E.00  <01IT5STUMUFO984Z8L@siroe.edu>
 
04-Feb-1998 00:06:29.31 conversion                D 9      (3)
 amy@siroe.edu rfc822;bert@sesta.com bert
 imta/queue/conversion/ZZ01IT5UAMZ4QW98518O.00
 <01IT5UALL14498518O@siroe.edu>
 
 04-Feb-1998 00:06:32.62 l                         D 9     (4)
  amy@siroe.edu rfc822;bert@siroe.com bert
  imta/queue/l/ZZ01IT5UAOXLDW98509E.00
  <01IT5STUMUFO984Z8L@siroe.edu>

  1. 外部ユーザー amy@siroe.edu からのメッセージがチャネル l の受取人 bert@sesta.com に届きました。しかし、CONVERSIONS マッピングエントリにより、このメッセージは直接チャネル l には送られず、最初に変換チャネルのキューに入れられます。

  2. 変換チャネルが実行され、メッセージがチャネル l のキューに入れられます。

  3. 変換チャネルはメッセージをキューから取り出す (古いメッセージファイルを削除する) ことができます。

  4. 最後に、チャネル l のキューからメッセージが取り出され (配信され) ています。

MTA ログの例: 送信接続ログ

この例は、LOG_CONNECTION=3 によって接続ログが有効になっているときの送信メッセージのログ出力を示します。この例では、LOG_PROCESS=1、LOG_MESSAGE_ID=1、および LOG_FILENAME=1 も設定されていると仮定されています。この例は、ユーザー adam@sesta.com が 3 人の受取人 (bobby@hosta.sesta.com、carl@hosta.sesta.com、および dave@hostb.sesta.com) に同じメッセージ (各メッセージコピーのメッセージ ID は同じ) を送信している場合を示しています。この例では、メッセージが (同様のチャネルが大抵そうであるように) single_sys チャネルキーワードで示された tcp_local チャネルから送信されていると仮定しています。したがって、(1)、(2)、(3) で示されているように、それぞれの受取人に対して、別々のメッセージファイルが別々のホスト名のディスク上に作成されます。bobby@hosta.sesta.com と carl@hosta.sesta.com の受取人は同じメッセージファイルに保存されますが、dave@hostb.sesta.com の受取人は別のメッセージファイルに保存されます。

例 21–9 MTA ログ: 送信接続ログ


19-Feb-1998 10:52:05.41 1e488.0 l            tcp_local    E 1
 adam@sesta.com rfc822;bobby@hosta.sesta.com bobby@hosta.sesta.com
 imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00                    (1)
  <01ITRF7BDHS6000FCN@SESTA.COM>

19-Feb-1998 10:52:05.41 1e488.0 l            tcp_local    E 1
 adam@sesta.com rfc822;carl@hosta.sesta.com carl@hosta.sesta.com
 imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00                    (2)
   <01ITRF7BDHS6000FCN@SESTA.COM>

19-Feb-1998 10:52:05.74 1e488.1 l            tcp_local    E 1
 adam@sesta.com rfc822;dave@hostb.sesta.com dave@hostb.sesta.com
 imta/queue/tcp_local/ZZ01ITRF7C11FU000FCN.00                    (3)
   <01ITRF7BDHS6000FCN@SESTA.COM>

19-Feb-1998 10:52:10.79 1f625.2.0 tcp_local    -            O    (4)
 TCP|206.184.139.12|5900|206.184.139.66|25
 SMTP/hostb.sesta.com/mailhub.sesta.com                          (5)
 
19-Feb-1998 10:52:10.87 1f625.3.0 tcp_local    -            O    (6)
 TCP|206.184.139.12|5901|206.184.139.70|25
 SMTP/hosta.sesta.com/hosta.sesta.com                            (7)

19-Feb-1998 10:52:12.28 1f625.3.1 tcp_local                  D 1
 adam@sesta.com rfc822;bobby@hosta.sesta.com bobby@hosta.sesta.com
 imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00
  <01ITRF7BDHS6000FCN@SESTA.COM>
 hosta.sesta.com dns;hosta.sesta.com                            (8)
 (TCP|206.184.139.12|5901|206.184.139.70|25)
 (hosta.sesta.com -- Server ESMTP [iMS V5.0 #8790])
 (TCP|206.184.139.12|5901|206.184.139.70|25)
 smtp;250 2.1.5 bobby@hosta.sesta.com and options OK.

19-Feb-1998 10:52:12.28 1f625.3.1 tcp_local                  D 1
 adam@sesta.com rfc822;carl@hosta.sesta.com carl@hosta.sesta.com
 imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00
  <01ITRF7BDHS6000FCN@SESTA.COM>
 hosta.sesta.com dns;hosta.sesta.com
 (TCP|206.184.139.12|5901|206.184.139.70|25)
 (hosta.sesta.com -- Server ESMTP [iMS V5.0 #8790])
 (TCP|206.184.139.12|5901|206.184.139.70|25)
 smtp;250 2.1.5 carl@hosta.sesta.com and options OK.

19-Feb-1998 10:52:12.40 1f625.3.2 tcp_local      -            C  (9)
 TCP|206.184.139.12|5901|206.184.139.70|25
 SMTP/hosta.sesta.com/hosta.sesta.com

19-Feb-1998 10:52:13.01 1f625.2.1 tcp_local                  D 1
 adam@sesta.com rfc822;dave@hostb.sesta.com dave@hostb.sesta.com
 imta/queue/tcp_local/ZZ01ITRF7C11FU000FCN.00
  <01ITRF7BDHS6000FCN@SESTA.COM>
 mailhub.sesta.com dns;mailhub.sesta.com
 (TCP|206.184.139.12|5900|206.184.139.66|25)
 (MAILHUB.SESTA.COM -- Server ESMTP [iMS V5.0 #8694])
 (TCP|206.184.139.12|5900|206.184.139.66|25)
 smtp;250 2.1.5 dave@hostb.sesta.com and options OK.

19-Feb-1998 10:52:13.05 1f625.2.2 tcp_local      -            C  (10)
                  
 TCP|206.184.139.12|5900|206.184.139.66|25
 SMTP/hostb.sesta.com/mailhub.sesta.com

  1. 1 人目の受取人へのメッセージがキューに入れられます。

  2. 次に、2 人目の受取人へのメッセージがキューに入れられます。

  3. 最後に、3 人目の受取人へのメッセージがキューに入れられます。

  4. LOG_CONNECTION=3 が設定されているため、MTA がこのエントリを書き込みます。マイナス記号 (-) は、このエントリが送信接続であることを示しています。O は、このエントリが接続開始に対応することを意味しています。この接続開始はスレッド 2 とスレッド 3 によって実行されていますが、これらの個別の接続開始に対するマルチスレッド TCP/IP チャネルに同じプロセスが使用されているため、プロセス ID は同じ (1f625) であることに注意してください。

  5. 2 つの異なるリモートシステムに接続するため、別々のスレッドにあるマルチスレッド SMTP クライアントがそれぞれの接続を開いています。最初の接続はこのエントリで、2 番目の接続は 7 に示されています。エントリのこの部分には、送信側と受信側の IP 番号とポート番号、および最初のホスト名と DNS 検索で見つかったホスト名の両方が示されています。SMTP/initial-host/dns-host には、最初のホスト名と、DNS MX レコード検索を実行したあとで使用されるホスト名が表示されています。mailhub.sesta.com は、hostb.sesta.com の MX サーバーであることがわかります。

  6. マルチスレッド SMTP クライアントが、別のスレッドで 2 番目のシステムとの接続を開いています (プロセスは同じ)。

  7. 2 つの異なるリモートシステムに接続するため、別々のスレッドにあるマルチスレッド SMTP クライアントがそれぞれの接続を開いています。2 番目の接続はこのエントリで、最初の接続は上記の 5 に示されています。エントリのこの部分には、送信側と受信側の IP 番号とポート番号、および最初のホスト名と DNS 検索で見つかったホスト名の両方が示されています。この例では、hosta.sesta.com というシステムがメールを直接受信することがわかります。

  8. この例に示されているように、特定の接続エントリのほか、LOG_CONNECTION=3 によって接続に関連する情報が標準のメッセージエントリに組み込まれます。

  9. LOG_CONNECTION=3 が設定されているため、MTA がこのエントリを書き込みます。メッセージ (この例では bobby と carl のメッセージ) がキューから取り出されたあと、接続が終了します。このエントリでは C で示されています。

MTA ログの例: 受信接続ログ

この例では、LOG_CONNECTION=3 によって接続ログが有効になっているときの着信 SMTP メッセージのログ出力を示します。

例 21–10 MTA ログ: 受信接続ログ


19-Feb-1998 17:02:08.70 tcp_local    +            O          (1)
 TCP|206.184.139.12|25|192.160.253.66|1244 SMTP              (2)

19-Feb-1998 17:02:26.65 tcp_local    l             E 1
 service@siroe.com rfc822;adam@sesta.com adam
 THOR.SIROE.COM (THOR.SIROE.COM [192.160.253.66])            (3)

 19-Feb-1998 17:02:27.05 tcp_local    +             C        (4)
                   TCP|206.184.139.12|25|192.160.253.66|1244 SMTP
 
19-Feb-1998 17:02:31.73 l                          D 1
  service@siroe.com rfc822;adam@sesta.com adam

  1. リモートシステムが接続を開きます。O は、このエントリが接続開始に対応したものであることを示しています。+ は、このエントリが着信接続であることを示しています。

  2. 接続の IP 番号とポートが示されています。このエントリでは、受信システム (ログファイルエントリを記録しているシステム) の IP アドレスは 206.184.139.12、ポート番号は 25、送信システムの IP アドレスは 192.160.253.66、ポートは 1244 です。

  3. このエントリは、着信 TCP/IP チャネル (tcp_local) からチャネル l の受取人に送られるメッセージがキューに入っていることを示しています。LOG_CONNECTION=3 が有効になっているため、デフォルト以外の情報も含まれています。特に、送信システムがその HELO または EHLO 行に示す名前、接続 IP 番号の DNS リバース検索で見つかった送信システムの名前、および送信システムの IP アドレスが、すべてログに記録されます。この動作に影響するチャネルキーワードについては、第 12 章「チャネル定義を設定する」を参照してください。

  4. 着信接続が閉じています。C は、このエントリが接続終了に対応したものであることを示しています。+ は、このエントリが着信接続であることを示しています。

ディスパッチャーのデバッグを有効にする

ディスパッチャーエラーとデバッグ出力 (有効になっている場合) は、MTA ログディレクトリ内の dispatcher.log ファイルに書き込まれます。ディスパッチャーの設定情報は、msg_svr_base/imta/dispatcher.cnf ファイルに指定されます。インストール時に作成されたデフォルトの設定ファイルをそのまま使用することができます。ただし、セキュリティーやパフォーマンスなどの理由でデフォルトの設定ファイルを変更する場合は、dispatcher.cnf ファイルを編集することができます。

表 21–3 ディスパッチャーデバッグビット

ビット 

 

16 進数値 

10 進数値 

使用目的 

 

0 

x 00001 

1 

サービスディスパッチャーのメインモジュールの基本的なデバッグ。 

1 

x 00002 

2 

サービスディスパッチャーのメインモジュールの特別なデバッグ。 

2 

x 00004 

4 

サービスディスパッチャー設定ファイルのログ処理。 

3 

x 00008 

8 

サービスディスパッチャーに関するその他の基本的なデバッグ。 

4 

x 00010 

16 

サービスの基本的なデバッグ。 

5 

x 00020 

32 

サービスの特別なデバッグ。 

6 

x 00040 

64 

プロセスに関連するサービスのデバッグ。 

7 

x 00080 

128 

使用されていません。 

8 

x 00100 

256 

サービスディスパッチャーとプロセス通信の基本的なデバッグ。 

9 

x 00200 

512 

サービスディスパッチャーとプロセス通信の特別なデバッグ。 

10 

x 00400 

1024 

パケットレベル通信のデバッグ。 

11 

x 00800 

2048 

使用されていません。 

12 

x 01000 

4096 

ワーカープロセスの基本的なデバッグ。 

13 

x 02000 

8192 

ワーカープロセスの特別なデバッグ。 

14 

x 04000 

16384 

その他のワーカープロセスのデバッグ (特に接続ハンドオフ)。 

15 

x 08000 

32768 

使用されていません。 

16 

x 10000 

65536 

サービスディスパッチャー I/O に対するワーカープロセスの基本的なデバッグ。 

17 

x 20000 

131072 

サービスディスパッチャー I/O に対するワーカープロセスの特別なデバッグ。 

20 

x 100000 

1048576 

統計の基本的なデバッグ。 

21 

x 200000 

2097152 

統計の特別なデバッグ。 

24 

x 1000000 

16777216 

PORT_ACCESS 拒否の dispatcher.log ファイルへのログ。 

Procedureディスパッチャーのエラーデバッグ出力を有効にする

手順

  1. dispatcher.cnf ファイルを編集します。

  2. DEBUG オプションを -1 に設定します。

    論理または環境変数の IMTA_DISPATCHER_DEBUG (UNIX) を設定することもできます。この変数は、32 ビットのデバッグマスクに 16 進数の FFFFFFFF の値を定義します。上の表には、各ビットの意味の説明があります。

Procedureディスパッチャーパラメータを設定する (Solaris)

ディスパッチャー設定ファイルで提供されるディスパッチャーサービスは、さまざまなシステムパラメータの必要要件に影響を与えます。システムのヒープサイズ (datasize) は、ディスパッチャーによるスレッドスタックの使用を考慮して十分なサイズに設定する必要があります。

手順

  1. ヒープサイズ (つまり、デフォルトの datasize) を表示するには、次のいずれかを使用します。

    csh コマンド: 


    # limit

    ksh コマンド


    # ulimit -a

    Solaris ユーティリティー


    # sysdef

  2. 各ディスパッチャーサービスに対して、STACKSIZE*MAX_CONNS を計算し、それらの計算値を合計します。システムのヒープサイズは、この合計値の 2 倍以上でなければなりません。

メッセージストア、管理、およびデフォルトのサービスログの管理

この節では、メッセージストア (POP、IMAP、および HTTP)、管理、およびデフォルトの各サービスのログについて説明します (表 21–1 を参照)。

これらのサービスの場合、コンソールを使用してログの設定と表示を行うことができます。設定内容は、どのイベントを何件まで記録するかに影響します。これらの設定とその他の特徴を使用して、ログファイル解析時のログイベントの検索条件を微調整することができます。

この節では、次の項目に分けて説明しています。

サービスログの特性について

ここでは、メッセージストアと管理サービスに関するログの特徴 (ログレベル、ログイベントのカテゴリ、ログファイル名の命名ルール、ログファイルのディレクトリ) について説明します。

ログレベル

ログのレベル (優先順位) は、ログのアクティビティーの詳細度を定義します。優先順位レベルが高いほど、詳細度は低くなります。優先順位 (重要度) の高いイベントだけがログに記録されるためです。レベルを下げると、ログは詳細なものとなり、より多くのイベントがログファイルに記録されます。

ログレベルは、 logfile.service.loglevel 設定パラメータを設定することによって、POP、IMAP、HTTP、管理、およびデフォルトのサービスごとに個別に設定できます (「サービスログオプションを定義、設定する」を参照)。また、ログレベルを使用して、ログイベントを検索するときにフィルタリングすることもできます。表 21–4 に、利用可能なレベルを示します。これらのログレベルは、UNIX の syslog 機構で定義されるログレベルのサブセットです。

表 21–4 メッセージストアと管理サービスのログレベル

レベル 

説明 

Critical 

もっとも詳細度の低いログです。メールボックスや実行に必要なライブラリにサーバーがアクセスできない場合など、サーバーに重大な問題や致命的な状態が発生したときに、イベントがログに記録されます。 

Error 

クライアントまたはほかのサーバーへの接続試行に失敗した場合など、エラー状態が発生したときに、イベントがログに記録されます。 

Warning 

サーバーがクライアントから送られた通信を解釈できない場合など、警告状態が発生したときに、イベントがログに記録されます。 

Notice 

ユーザーがログインに失敗したり、セッションが終了したりした場合など、通知 (正常だが重要な状況) が発生したときに、イベントがログに記録されます。これがデフォルトのログレベルです。 

Information 

ユーザーがログオンやログオフを行なったり、メールボックスを作成したり名前を変更した場合など、重要なアクションが行われたときに、イベントがログに記録されます。 

Debug 

もっとも詳細度の高いログです。デバッグを行う場合にのみ役立ちます。各プロセスまたはタスク内の個々のステップごとにイベントがログに記録されるため、問題の箇所を正確に突き止めることができます。 

特定のログレベルを選択すると、そのレベルのイベントとそれ以上のレベル (詳細度の低い) のイベントがログに記録されます。デフォルトのログレベルは、Notice です。

注 –

より詳細なログを指定するほど、ログファイルがより多くのディスク容量を占有することになります。ガイドラインについては、「サービスログオプションを定義、設定する」を参照してください。

ログイベントのカテゴリ

サポートされているサービスまたはプロトコル内で、Messaging Server は、どの機能領域で発生したかに基づいて、ログイベントをより細かくカテゴリに分類します。各ログイベントには、それを生成した機能領域の名前が含まれています。これらのカテゴリは、イベントを検索する際のフィルタリングに使用できます。表 21–5 に、Messaging Server がログのために認識するカテゴリのリストを示します。

表 21–5 ログイベントの発生場所のカテゴリ

機能領域 

説明 

一般 

プロトコルまたはサービスに関連するアクション全般です 

LDAP 

LDAP ディレクトリデータベースにアクセスする Messaging Server に関連するアクションです 

Network 

ネットワークの接続に関連するアクションです (ソケットエラーはこのカテゴリに分類される) 

Account 

ユーザーアカウントに関連するアクションです (ユーザーログインはこのカテゴリに分類される) 

Protocol 

プロトコル固有のコマンドに関連するプロトコルレベルのアクションです (POP、IMAP、または HTTP 機能によって返されるエラーはこのカテゴリに分類される) 

Stats 

サーバーの統計収集に関連するアクションです 

Store 

メッセージストアへのアクセスに関連する低レベルのアクションです (読み取りまたは書き込みエラーはこのカテゴリに分類される) 

ログ検索でカテゴリをフィルタとして使用する場合の例については、「サービスログを検索、表示する」を参照してください。

サービスログファイルのディレクトリ

ログ記録される各サービスごとに、1 つのディレクトリが割り当てられ、ログファイルはそこに保存されます。IMAP ログファイルや POP ログファイルなどの各サービスのログファイルは、それぞれのディレクトリ内に一緒に保存されます。各ディレクトリの場所、そのディレクトリ内に保存できるログファイルの数、およびファイルのサイズを設定することができます。

すべてのログファイルを保存するのに十分な容量があることを確認してください。ログレベルが低い (詳細度が高い) ほど、ログファイルのサイズは大きくなります。

ログレベル、ログローテーション、ログの有効期間、およびサーバーのバックアップポリシーを正しく定義することが重要です。ログファイルディレクトリのすべてがバックアップされ、また、過負荷にならないようにするためです。これらを正しく定義しないと、情報を失ってしまうことがあります。「サービスログオプションを定義、設定する」を参照してください。

サービスログファイルの形式について

Messaging Server によって作成されたメッセージストアおよび管理サービスのログファイルのコンテンツの形式は、すべて同じです。ログファイルは複数行のテキストファイルであり、各行に 1 つのログイベントが記述されています。サポートされている各サービスに対するすべてのイベントは、通常は以下のような形式で記述されています。

dateTime hostName processName[pid]: category logLevel: eventMessage

表 21–6 に、ログファイルのコンポーネントを示します。このイベント記述形式は、日付/時刻形式が異なることと追加コンポーネント (category と logLevel) があることを除けば、UNIX の syslog 機構で定義されているものと同じです。

表 21–6 メッセージストアと管理サービスのログファイルのコンポーネント

コンポーネント 

定義 

dateTime

イベントがログ記録された日付と時刻。dd/mm/yyyy hh:mm:ss の形式で表記されます。時間帯フィールドは GMT を基準とした +/-hhmm で表記されます。例: 02/Jan/1999:13:08:21 -0700

hostName

サーバーが動作しているホストマシンの名前。例: showshoe

注: ホスト上に複数の Messaging Server インスタンスがある場合は、プロセス ID (pid) を使用して、ログイベントのインスタンスを区別することができます。

processName

イベントを生成したプロセスの名前。例: cgi_store

pid

イベントを生成したプロセスのプロセス ID。例: 18753

category

イベントが属するカテゴリ。例: General (例 21–5 を参照)

logLevel

イベントのログレベル。例: Notice (例 21–4 を参照)

eventMessage

イベント固有の説明メッセージで、長さは任意です。例: Log created (894305624)

以下に、コンソールを使って表示したログイベントの例を示します。

02/May/1998:17:37:32 -0700 showshoe cgi_store[18753]:
 General Notice:
   Log created (894155852)

04/May/1998:11:07:44 -0400 xyzmail cgi_service[343]: General Error:
   function=getserverhello|port=2500|error=failed to connect

03/Dec/1998:06:54:32 +0200 SiroePost imapd[232]: Account Notice:
   close [127.0.0.1] [unauthenticated] 1998/12/3 6:54:32
   0:00:00 0 115 0

IMAP および POP のイベントエントリの末尾は、3 つの数になることがあります。上記の例では、0 115 0 です。最初の数字はクライアントによって送信されたバイト数、2 番目の数字はサーバーによって送信されたバイト数、3 番目の数字は選択されたメールボックス (POP の場合は常に 1) です。

ログファイルを「ログビューア」ウィンドウに表示するときは、特定のログレベルやカテゴリ、または特定のプロセス ID などのイベント内の特定のコンポーネントを検索することによって、表示するイベントを制限することができます。詳細は、「サービスログを検索、表示する」を参照してください。

各ログエントリのイベントメッセージは、記録されるイベントのタイプに固有の形式です。つまり、各サービスのイベントメッセージに表示される内容は、各サービスによって定義されています。多くのイベントメッセージは単純で明白なものですが、複雑なものもあります。

サービスログオプションを定義、設定する

メッセージストアおよび管理サービスのログ設定は、管理者のニーズに合わせて定義することができます。ここでは、最適な設定とポリシーを決定するために役立つ情報と、それらの適用方法を説明します。

柔軟なログ構造

ログファイルのネーミングの形式 (service.sequenceNum.timeStamp) により、柔軟なログローテーションとバックアップポリシーを設計することができます。イベントはサービスごとに別のファイルに記録されるため、問題をすばやく簡単に切り分けることができます。また、ファイル名の中のシーケンス番号は常に増え続け、タイムスタンプは常に一意であるため、指定したシーケンス番号の限界に達しても、新しいログファイルが古いログファイルを単純に上書きしてしまうことはありません。古いログファイルの上書きや削除が行われるのは、ログファイルの保存期間や最大数、合計ログ容量など、より柔軟性のある制限がその限界に達したときだけです。

Messaging Server では、管理やバックアップを簡素化できるように、ログファイルの自動ローテーションがサポートされています。後続のログイベントを記録するために、手動で現在のログファイルを回収して新しいログファイルを作成する必要はありません。現在のログファイル以外、ディレクトリ内にあるものはすべて、サーバーを停止したり、新しいログファイルの作成をサーバーに手動で指定しなくても、いつでもバックアップすることができます。

ログポリシーを設定する際に、合計ログ容量、ログファイルの最大数、個々のファイルサイズ、ファイルの最長保存期間、およびログファイルローテーションの頻度といったオプションを、サービスごとに設定することができます。

適切なオプションを決定する

複数の制限を設定する必要があることと、それらの中にはログファイルのローテーションや削除を引き起こすものがあることを理解しておいてください。最初に限界に達する制限が、制御の中心となります。たとえば、ログファイルの最大サイズを 3.5M バイトに設定し、毎日新しいログを作成するように設定したとします。この場合、24 時間以内に 3.5M バイト以上のデータが記録されると、1 日に複数のログファイルが作成されることになります。このため、ログファイルの最大数が 10 個、最長保存期間が 8 日に設定されている場合でも、ログのローテーションが早いため、8 日間経過する前に 10 個のファイルが作成され、最長保存期間まで達することはありません。

次は Messaging Server の管理ログに備えられているデフォルト値であり、適切なオプションを決定する際に役立ちます。

ディレクトリ内のログファイルの最大数: 10

ログファイルの最大サイズ: 2M バイト

全ログファイルの合計最大サイズ: 20M バイト

最小空きディスク容量: 5M バイト

ログロールオーバー時間: 1 日

最長有効期間: 7 日

ログのレベル: Notice

この設定の場合、サーバー管理ログのデータは 1 日当たり約 2M バイト蓄積され、バックアップは週 1 回作成され、管理ログの保存に割り当てられている合計容量は最低 25M バイトです。ログレベルがより詳細な場合、これらの設定では不十分なことがあります。

POP、IMAP、または HTTP のログの場合も、同様の設定から始めるとよいでしょう。すべてのサービスのログ容量要件が上記のデフォルト値とほとんど同じである場合、最初は約 150M バイトの合計ログ容量を設定することをお勧めします。ここに示した設定はあくまでも一般例であり、実際の条件はこれとかなり異なる場合があります。

ログオプションについて

メッセージストアのログ設定を制御するオプションは、コンソールまたはコマンド行を使用して設定することができます。

これらのオプションの最適な設定は、ログデータの累積される頻度によって異なります。1M バイトの保存領域には、約 4,000 〜 10,000 件のログエントリを記録できます。適度にビジー状態のサーバーでは、ログレベルが低い場合 (Notice など)、週に何百 M バイトものログデータが記録されることもあります。以下の設定を参考にしてください。

サービスログを検索、表示する

コンソールには、メッセージストアおよび管理サービスに関するログデータを表示するための基本的なインタフェースがあります。個々のログファイルを選択したり、それらのファイル内で柔軟なフィルタリングによる検索を行うことができます。

ログファイルはサービスごとに分かれており、それぞれ作成順に一覧表示されます。検索するログファイルを選択したら、検索パラメータを指定して検索対象を個々のイベントに限定することができます。

検索パラメータ

以下に、表示するログデータを指定するための検索パラメータを示します。

* 任意の文字セット (例: *.com)

? 任意の 1 文字 (例: 199?)

[nnn] nnn 内の任意の文字 (例: [aeiou])

[^nnn] nnn 内にない任意の文字 (例: [^aeiou])

[n-m] n-m の範囲内の任意の文字 (例: [A-Z])

[^n-m] n-m の範囲内にない任意の文字 (例: [^0-9])

\ エスケープ文字: *、?、[、または ] の前に配置してそれらを文字として使用

注: 検索では大文字と小文字が区別されます。

次に、ログレベルと機能領域を組み合わせた、表示するログの検索例を示します。

サービスログの使用

この節では、configutil コマンドを使用して、またログの検索および表示のためのコンソールを使用して、サービスログを使用する方法について説明します。

Procedureサービスログを syslog へ送信する

手順

    次のように syslogfacility オプションを指定して configutil コマンドを実行します。

    configutil -o logfile.servicesyslogfacility -v value

    ここで、service は admin、pop、imap、imta、または http に、value は user、mail、daemon、local0 から local7、または none になります。

    値が設定されると、設定値に対応する syslog 機構のログにメッセージが記録され、その他のすべてのログファイルサービスオプションが無視されます。オプションが設定されていない場合、または値が none の場合、Messaging Server ログファイルが使用されます。

Procedureコンソールを使用してログオプションを設定する

手順

  1. ログファイルオプションを設定する Messaging Server を開きます。

  2. 「設定」タブをクリックし、左側のパネルで「ログファイル」フォルダを開き、サービス (IMAP、HTTP、Admin など) のログファイルを選択します。

  3. 「詳細レベル」ドロップダウンリストからログレベルを選択します。

  4. 「ログファイルのディレクトリパス」フィールドに、ログファイルの保存先となるディレクトリの名前を入力します。

  5. 「各ログのファイルサイズ」フィールドに、ログファイルの最大サイズを入力します。

  6. 「新規ログエントリの作成」フィールドに、ログローテーションのスケジュールの値を入力します。

  7. 「ディレクトリ当たりのログ数」および「ログが次の日付よりも古い場合」フィールドに、バックアップスケジュールを考慮に入れて、最大ログファイル数と期限を示す値を入力します。

  8. 「ログサイズの合計が次の値を超えたとき」フィールドに、合計保存領域の上限を入力します。

  9. 「残りディスク容量が次の値以下になった場合」フィールドに、確保しておく空きディスク容量の最小値を入力します。

HTTP ログを無効にする

使用しているシステムが HTTP メッセージアクセス (Web メール) をサポートしていない場合は、次の変数を設定して HTTP のログを無効にできます。システムに Web メールサポート (たとえば、Messenger Express) が必要な場合は、これらの変数を設定しないでください。

Procedureサーバーログレベルを設定する

手順

    次のように configutil コマンドを実行します。

    configutil -o logfile.service.loglevel -v level

    ここで、service は admin、pop、imap、imta、または http に、loglevel は Nolog、Critical、Error、Warning、Notice、Information、または Debug になります。

Procedureログファイルのディレクトリパスを指定する

手順

    次のように configutil コマンドを実行します。


    configutil -o logfile.service.logdir -v dirpath

Procedure各ログの最大ファイルサイズを指定する

手順

    次のように configutil コマンドを実行します。


    configutil -o logfile.service.maxlogfilesize -v size

    size にはバイト数を指定します。

Procedureサービスログローテーションのスケジュールを指定する

手順

    次のように configutil コマンドを実行します。


    configutil -o logfile.service.rollovertime -v number

    number には秒数を指定します。

Procedureディレクトリ内の最大サービスログファイル数を指定する

手順

    次のように configutil コマンドを実行します。


    configutil -o logfile.service.maxlogfiles -v number

    number にはログファイルの最大数を指定します。

Procedure保存容量の上限を指定する

手順

    次のように configutil コマンドを実行します。


    configutil -o logfile.service.maxlogsize -v number

    number にはバイト数を指定します。

Procedure確保しておく空きディスク容量の最小値を指定する

手順

    次のように configutil コマンドを実行します。


    configutil -o logfile.service.minfreediskspace -v number

    number にはバイト数を指定します。

ログの保存期間を指定する


configutil -o logfile.service.expirytime -v number

number には秒数を指定します。

Procedure検索対象を指定し、結果を表示する

指定したサービスに属する固有の特徴を持つログイベントを検索するには、以下の手順に従います。

手順

  1. コンソールで、調べるログファイルがある Messaging Server を開きます。

  2. 以下のいずれかの方法で、指定したサービスログの「ログファイルの内容」タブを表示します。

    • 「タスク」タブをクリックしてから、「サービスログの表示」をクリックします。サービス部分は、ログに記録されているサービスの名前 (”IMAP サービス” や ”管理” など) です。

    • 「設定」タブをクリックし、左側のパネルで「ログファイル」フォルダを開き、サービス (IMAP や Admin など) のログファイルを選択します。次に、右側のパネルの「目次」タブをクリックします。

  3. ログに記録されたサービスの「目次」タブが表示されます。

  4. 「ログファイル名」フィールドで、調べたいログファイルを選択します。

  5. 「選択したログの表示」ボタンをクリックして「ログビューア」ウィンドウを開きます。

  6. 「ログビューア」ウィンドウで、検索パラメータを指定します (前述の「検索パラメータ」を参照)。

  7. 「更新」をクリックして検索を実行し、「ログエントリ」フィールドに結果を表示します。

メッセージストアのログを使用したメッセージの追跡

MTA がメッセージを追跡する方法と同様に、メッセージ ID によってメッセージを追跡するためにメッセージストアのログを使用できます。この方法でメッセージを追跡すると、メッセージのライフサイクルの重要なイベントを追跡できます。

メッセージストアログのメッセージを追跡するには、通常のログ設定に加えてメッセージの追跡も設定する必要があります。デフォルトでは、メッセージの追跡は有効になっていません。

注 –

メッセージの追跡は、ディスク領域を大量に使用します。十分なディスク容量がない限り、この機能を有効にしないでください。

メッセージストアのログは、次の操作を追跡できます。

Procedureメッセージの追跡を有効にする

手順

    次のように configutil コマンドを実行します。


    configutil -o local.msgrace.active -v “yes”

    メッセージの追跡情報は、プロセスごとにデフォルトのログに書き込まれます。IMAP fetch は、imap ログファイルに書き込まれます。ims_master append は、ims_master チャネルログファイルに書き込まれます。

Procedureメッセージの追跡を単一のログファイルにリダイレクトする

手順

    メッセージの追跡ログを単一の「msgtrace」ログファイルにリダイレクトするには、configutil コマンドを使用してログファイルのパラメータを設定する必要があります。msgtrace ログファイルは、その他のログファイルとは異なり、ローカルに設定されます。例: 


    configutil -o "local.logfile.msgtrace.buffersize" -v "0"
configutil -o "local.logfile.msgtrace.expirytime" -v "604800"
configutil -o "local.logfile.msgtrace.flushinterval" -v "60"
configutil -o "local.logfile.msgtrace.logdir" -v "/opt/SUNWmsgsr/data/log"
configutil -o "local.logfile.msgtrace.loglevel" -v "Information"
configutil -o "local.logfile.msgtrace.logtype" -v "NscpLog"
configutil -o "local.logfile.msgtrace.maxlogfiles" -v "10"
configutil -o "local.logfile.msgtrace.maxlogfilesize" -v "2097152"
configutil -o "local.logfile.msgtrace.maxlogsize" -v "20971520"
configutil -o "local.logfile.msgtrace.minfreediskspace" -v "5242880"
configutil -o "local.logfile.msgtrace.rollovertime" -v "86400"

Procedureメッセージ追跡ログの設定を解除する

手順

    msgtrace ログファイルの設定を解除するには、configutil コマンドを使用してその設定へのすべての参照を削除します。例: 


    configutil -o "local.logfile.msgtrace.buffersize" -v ""
configutil -o "local.logfile.msgtrace.expirytime" -v ""
configutil -o "local.logfile.msgtrace.flushinterval" -v ""
configutil -o "local.logfile.msgtrace.logdir" -v ""
configutil -o "local.logfile.msgtrace.loglevel" -v ""
configutil -o "local.logfile.msgtrace.logtype" -v ""
configutil -o "local.logfile.msgtrace.maxlogfiles" -v ""
configutil -o "local.logfile.msgtrace.maxlogfilesize" -v ""
configutil -o "local.logfile.msgtrace.maxlogsize" -v ""
configutil -o "local.logfile.msgtrace.minfreediskspace" -v ""
configutil -o "local.logfile.msgtrace.rollovertime" -v ""

ProcedureLMTP ログを設定する

手順

    LMTP を使用する場合に、単一の「msgtrace」ログファイルを使用しない場合は、ローカルに tcp_lmtp_server ログファイルも設定する必要があります。LMTP を使用しない場合、またはメッセージの追跡を使用しない場合、または「msgtrace」ログファイルのメッセージ追跡を使用する場合、LMTP メッセージストアサイドログを初期化する必要はありません。LMTP はすでに MTA 情報を分けてログに記録しています。例: 


    configutil -o "local.logfile.tcp_lmtp_server.buffersize" -v "0"
configutil -o "local.logfile.tcp_lmtp_server.expirytime" -v "604800"
configutil -o "local.logfile.tcp_lmtp_server.flushinterval" -v "60"
configutil -o "local.logfile.tcp_lmtp_server.logdir" -v \
   "/opt/SUNWmsgsr/data/log"
configutil -o "local.logfile.tcp_lmtp_server.loglevel" -v "Information"
configutil -o "local.logfile.tcp_lmtp_server.logtype" -v "NscpLog"
configutil -o "local.logfile.tcp_lmtp_server.maxlogfiles" -v "10"
configutil -o "local.logfile.tcp_lmtp_server.maxlogfilesize" -v "2097152"
configutil -o "local.logfile.tcp_lmtp_server.maxlogsize" -v "20971520"
configutil -o "local.logfile.tcp_lmtp_server.minfreediskspace" \
   -v "5242880"
configutil -o "local.logfile.tcp_lmtp_server.rollovertime" -v "86400"

その他のメッセージストアログ機能

Messaging Server では、テレメトリと呼ばれる機能が提供されており、ユーザーの IMAP または POP セッション全体をファイルに取得できます。この機能は、クライアント問題をデバッグするのに便利です。たとえば、メッセージアクセスクライアントが期待どおりに機能しないとユーザーが訴えた場合、この機能を使用してアクセスクライアントと Messaging Server 間の対話を記録することができます。「テレメトリを使用してユーザーの IMAP/POP セッションをチェックする」を参照してください。

メッセージストアのログの例

メッセージストアログファイルにログ記録されるフィールドの形式とフィールドのリストは、設定したログオプションによって異なります。ここでは、いくつかの典型的なログエントリの解釈の例を示します。

メッセージストアのログの例: 不良パスワード

ユーザーが無効なパスワードを入力すると、「ユーザーが見つからない」というメッセージではなく「認証」の失敗がログに記録されます。セキュリティー上の理由から、クライアントには「ユーザーが見つからない」というメッセージが渡されますが、ログには本当の理由 (無効なパスワード) が記録されます。

例 21–11 メッセージストアのログ: 無効なパスワード


 [30/Aug/2004:16:53:05 -0700] vadar imapd[13027]: Account Notice: badlogin:
[192.18.126.64:40718] plaintext user1 authentication failure

メッセージストアのログ: 無効になったアカウント

次の例は、無効になったアカウントが原因でユーザーがログインできない理由を示しています。さらに、無効になったアカウントは「(inactive)」または「(hold)」として明示されます。

例 21–12 メッセージストアのログ: 無効になったアカウント


[30/Aug/2004:16:53:31 -0700] vadar imapd[13027]: Account Notice: badlogin: 
[192.18.126.64:40720] plaintext user3 account disabled (hold)

メッセージストアのログの例: 付加されたメッセージ

次の例は、メッセージがフォルダに追加されるたびに発生する付加メッセージを示しています。メッセージストアのログは、ims_master および lmtp チャネルを介してメッセージストアに入るすべてのメッセージを記録します。ユーザー ID、フォルダ、メッセージのサイズ、およびメッセージ ID の「append」を記録します。

例 21–13 メッセージストアのログ: 付加


[31/Aug/2004:16:33:14 -0700] vadar ims_master[13822]: Store Information:append:
user1:user/user1:659:<Roam.SIMC.2.0.6.1093995286.11265.user1@vadar.siroe.com>

メッセージストアのログの例: クライアントが取得するメッセージ

メッセージストアのログは、クライアントがメッセージを取得すると、「fetch」メッセージを書き込みます。メッセージストアのログは、少なくとも 1 つの本体部分のすべてのクライアントのフェッチを記録します。ユーザー ID、フォルダ、およびメッセージ ID の「fetch」を記録します。

例 21–14 メッセージストアのログ: クライアントが取得するメッセージ


[31/Aug/2004:15:55:26 -0700] vadar imapd[13729]: Store Information:
fetch:user1:user/user1:<Roam.SIMC.2.0.6.1093051161.3655.user1@vad.siroe.com>

メッセージストアのログの例: フォルダから削除されるメッセージ

例 21–15 メッセージストアのログの例: フォルダから削除されるメッセージ

メッセージストアは、IMAP または POP メッセージがフォルダから削除される (ただし、システムからは削除されない) と、「expunge」メッセージを書き込みます。メッセージがユーザーまたはユーティリティーのどちらによって消去されたかがログに記録されます。フォルダおよびメッセージ ID の「expunge」を記録します。


31/Aug/2004:16:57:36 -0700] vadar imexpire[13923]: Store Information:
expunge:user/user1:<Roam.SIMC.2.0.6.1090458838.2929.user1@vadar.siroe.com>

メッセージストアのログの例: 重複したログインメッセージ

1 つの msgtrace ログファイルに対するメッセージの追跡を設定する場合、imap および pop ログファイルに記録される通常の「login」メッセージは、msgtrace ファイルに重複して記録されます。次に、正常なログインメッセージを示します。

例 21–16 メッセージストアのログ: ログイン


[30/Aug/2004:16:53:13 -0700] vadar imapd[13027]: Account Information: login
[192.18.126.64:40718] user1 plaintext