| 前へ 目次 索引 次へ | |
| iPlanet Messaging Server 5.1 管理者ガイド | |
第 12 章 ログ記録とログ解析
iPlanet Messaging Server では、ログファイルを作成して、管理に関連したサーバのイベント、サーバでサポートされているプロトコル （SMTP、POP、IMAP、HTTP） を使った通信関連のイベント、およびサーバで処理されるその他のプロセスに関連するイベントを記録できます。そのログファイルを調べれば、サーバのアクションをさまざまな観点から監視できます。MTA は他のサービスとは異なるログ機構を使用しているため、iPlanet Console を使ってログサービスを設定したりログを表示することはできません。設定ファイルに情報を定義することで、MTA のログ設定を行います。この章は、以下のように 3 部構成になっています。第 1 部では概要について、第 2 部ではメッセージストアおよび管理のログ、第 3 部では MTA サービスのログについて説明します。
第 2 部 サービスログ （メッセージストアおよび管理サーバ）
第 1 部 概要
Messaging Server ログファイルの作成と管理に関するポリシーはカスタマイズできます。この章では、ログファイルの種類と構造、およびログファイルの管理と表示方法について説明します。
サービスとログファイル
Messaging Server は、サポートしている主なプロトコルやサービスごとに一連のログファイルを作成します。ログファイルの各タイプは、個別にカスタマイズしたり表示することができます。表 12-1 に、ログ記録が可能なサービスのリストとそれぞれのログファイルに関する説明を示します。
サービス
ログファイルの説明
Administration Server を介した iPlanet Console と Messaging Server （主に複数の CGI プロセス）間の通信に関連するログイベントが記録されます。
サーバのその他のアクティビティ （コマンドラインユーティリティやその他のプロセスなど）に関連するログイベントが記録されます。
サードパーティ製のツールを使ってログを解析する
iPlanet Messaging Server ではサポートされていないログ解析やレポート生成を行うには、別のツールを利用する必要があります。ログファイルは、テキストエディタや標準のシステムツールで操作できます。正規表現による構文解析をサポートするスクリプタブルなテキストエディタを利用すると、この章で説明しているような特定の条件に基づくログエントリの検索や抽出を実施できます。さらに、その結果を並べ替えたり、集計や統計を行うこともできます。
UNIX 環境では、UNIX の syslog ファイルを操作するために開発された既存のレポート生成ツールを変更して使用することも可能です。パブリックドメインの syslog 操作ツールを使用する場合は、日付/時刻フォーマットのほか、Messaging Server のログエントリにある syslog エントリにはないfacility と logLevel の 2 つの特殊コンポーネントの変更が必要な場合があります。
第 2 部 サービスログ （メッセージストアおよび管理サーバ）
ここでは、POP、IMAP、HTTP、Admin、および Default の各サービスに関するログについて説明します （表 12-1 を参照）。これらのサービスの場合には、iPlanet Console を使ってログの設定と表示ができます。設定内容は、どのイベントを記録するか、何件まで記録するかという点に影響します。これらの設定とその他の特徴を利用して、ログファイルの解析時にログイベントの検索条件を微調整できます。
ログの特徴
ここでは、メッセージストアおよび管理サービスに関するログの特徴（ ログレベル、ログイベントのカテゴリ、ログのファイル名規則、ログファイルのディレクトリ）について説明します。
ログレベル
ログのレベル（優先順位）設定では、ログのアクティビティをどれだけ詳細に行うのか（詳細度）を定義します。レベル (重要度) が高いほど、ログの詳細度は低くなります。優先順位の高いイベントだけがログに記録されるためです。一方、レベルを下げると、ログは詳細なものとなり、より多くのイベントがログファイルに記録されます。ログレベルは、POP、IMAP、HTTP、Admin、および Default の各サービスごとに個別に設定できます。ログレベルを設定することで、ログイベントを検索するときにフィルタリングが可能になります。表 12-2 に、設定可能なレベルを示します。これらのログレベルは、UNIXの syslog 機構で定義されるレベルのサブセットです。
特定のログレベルを選択すると、そのレベルのイベントおよびそれ以上のレベルの （詳細度の低い） イベントがログに記録されます。デフォルトのログレベルは、Notice に設定されています。
注 低レベルの （より詳細な） ログを指定するほど、ログファイルがより多くのディスク容量を使用するようになります。そのガイドラインにについては、「ログオプションを定義、設定する」を参照してください。
ログイベントのカテゴリ
サポートされているサービスあるいはプロトコル内で、Messaging Server はイベントが発生する機構すなわち機能上の領域に基づいてログイベントをさらに分類します。ログファイルに記録された各イベントには、そのイベントを生成した機構の名前が記されています。これらのカテゴリは、イベントを検索する際のフィルタリングに利用できます。表 12-3 に、Messaging Server がログ処理用に認識するカテゴリのリストを示します。
機構
プロトコル固有のコマンドに関連するプロトコルレベルのアクション （POP、IMAP、HTTP 機能によって返されるエラーなど）。
ログを検索する際のフィルタリングにカテゴリを使用する例については、「ログを検索、表示する」を参照してください。
メッセージストアおよび管理に関連するログファイルの名前
POP、IMAP、HTTP、Admin、および Default サービスのログファイルには、同一のネーミング規則が適用されます。各ログファイルのファイル名は、以下の形式に従います。表 12-4 に、メッセージストアに関連するログファイルのネーミング規則を示します。
たとえば、imap.63.915107696 という名前のログファイルは、IMAP ログファイルのディレクトリで 63 番目に作成されたログファイルであり、作成日および作成時刻が 1998 年 12 月 31 日 12:34:56 PM であることを表します。
拡張可能なシーケンス番号とタイムスタンプを組み合わせることによって、解析するファイルのローテーション、期間、および選択における柔軟性が増します。詳細については、「ログオプションを定義、設定する」を参照してください。
ログファイルのディレクトリ
ログされる各サービスごとにディレクトリが 1 つ割り当てられ、ログファイルはそこに保存されます。IMAP ログファイルや POP ログファイルなど、各サービスのログファイルは、それぞれのディレクトリ内に一緒に保存されます。各ディレクトリの場所、そのディレクトリ内に保存できるログファイルの数、ファイルの最大サイズは、設定できます。すべてのログファイルを保存するのに十分な容量があることを確認してください。ログレベルが低いほど、(詳細度が高くなるほど) ログファイルのサイズは大きくなり易くなります。
すべてのログファイルディレクトリのバックアップが行われ、ディレクトリが過負荷状態にならないように、ログレベル、ログローテーション、ログ有効期間、およびサーバのバックアップポリシーを正しく設定することが重要です。詳細については、「ログオプションを定義、設定する」を参照してください。
ログファイルのフォーマット
Messaging Server によって作成されたメッセージストアログファイルと管理サービスログファイルのコンテンツフォーマットはすべて同じです。ログファイルは、複数のテキスト行から構成されており、各行にイベントが 1 つ記述されています。サポートされている各サービスに対するすべてのイベントは、通常以下のようなフォーマットで記述されています。日付時刻 ホスト名 プロセス名[pid]: カテゴリ ログレベル: イベントメッセージ
表 12-5 に、ログファイルの構成要素を示します。このイベント記述フォーマットは、日付/時刻フォーマットが異なることと、さらに別の 2 つの構成要素（カテゴリとログレベル）があることを除き、UNIX の syslog 機構で定義されているものと同じです。
表 12-5 ストアログファイルと管理ログファイルの構成要素
構成要素
定義
イベントが記録された日付および時刻。dd/mm/yyyy hh:mm:ss の形式で表記されます。タイムゾーンフィールドは GMT を基準とした +/-hhmm の形式で表記されます。以下に例を示します。02/Jan/1999:13:08:21 -0700
サーバが実行されているホストマシンの名前。以下に例を示します。showshoe
注意 : ホストに複数の Messaging Server インスタンスがある場合には、プロセス ID （pid） を使ってログイベントのインスタンスを区別できます。
イベントが属するカテゴリ。例 : General（表 12-3を参照）
イベントのログレベル。例 : Notice（表 12-2を参照）
以下に、iPlanet Console を使って表示した 3 つのログイベントの例を示します。
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 connect03/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 0IMAP および POP のイベントエントリの末尾は、3 つの数値である場合があります。上の例では「0 115 0」となっています。最初の数値はクライアントによって送信されたバイト数、2 番目の数値はサーバによって送信されたバイト数、3 番目の数値は選択されたメールボックスの数 (POP の場合は常に 1) を表しています。
[ログビューア]ウィンドウにログファイルを表示する場合は、ログレベルやカテゴリ、あるいはプロセス ID などのイベント固有の構成要素を検索し、表示するイベントを制限できます。詳細については、「ログを検索、表示する」を参照してください。
各ログエントリのイベントメッセージは、ログに記録されるイベントのタイプに特有のフォーマットで表記されます。つまり、各サービスごとに、イベントメッセージに含まれるコンテンツが定義されます。ほとんどのイベントメッセージは簡単で明白なものですが、中には複雑なものもあります。
ログオプションを定義、設定する
メッセージストアと管理サービスのログ設定は、管理業務のニーズに合わせて定義できます。ここでは、最適な設定およびポリシーを決定するために役立つ情報、およびそれらの適用方法について説明します。
柔軟性のあるログ構造
ログファイルの名前形式 （サービス.シーケンス番号.タイムスタンプ） は、柔軟性のあるログローテーションとバックアップポリシーの設定に役立ちます。異なるサービスのイベントは、それぞれ別のファイルに記録されるため、問題箇所の素早い検出が可能になります。また、ファイル名中のシーケンス番号は常に増え続け、タイムスタンプは常に固有のものであるため、指定したシーケンス番号の限界に達しても、新しいログファイルが古いログファイルを自動的に上書きしてしまうことはありません。古いログファイルの上書きや削除が行われるのは、ログファイルの保存期間や最大ファイル数、あるいは合計ログ容量など、より柔軟性のある制限がその限界に達したときにだけです。Messaging Server では、管理やバックアップの作業を簡素化できるように、ログファイルの自動ローテーションがサポートされています。後続のログイベントを記録するために，手作業で記録中のログファイルを回収して新しいログファイルを作成する必要はありません。ディレクトリ内にあるファイルはすべて (記録中のログファイル以外)、サーバを停止させたり、新しいログファイルの開始を手作業で指定することなく、いつでもバックアップを作成できます。
ログポリシーの設定では、各サービスごとに、合計保存容量、最大ログファイル数、個々のファイルサイズ、ログファイルの最長保存期間、ログファイルのローテーション頻度といったオプションを設定できます。
適切なオプションを判断する
複数の制限を設定する必要があることと、それらの中にはログファイルのローテーションや削除を発生させるものがあることを理解しておいてください。最初に限界に達する制限が制御の中心となります。たとえば、ログファイルの最大サイズを 3.5 MB に設定し、新規のログを毎日作成するように設定したとします。しかし、24 時間以内に 3.5 MB 以上のデータが記録される場合は、指定期間内に複数のログファイルが作成されることになります。したがって、最大ログファイル数が 10 個、最長有効期間が 8 日に設定されている場合でも、8 日に達する前に 10 個のファイルが作成され、指定期間まで達しない可能性があります。以下に、適切なオプションを判断する際に役立つ一般的な設定を示します。これは Messaging Server 管理ログのデフォルトです。
ディレクトリ内の最大ログファイル数 : 10
最大ログファイルサイズ : 2 MB
全ログファイルを対象とする合計最大サイズ : 20 MB
最小空きディスク容量 : 5 MB
ログロールオーバー期間 : 1 日
最長有効期間 : 7 日
ログレベル : Noticeこの設定の場合、サーバ管理ログのデータは 1 日あたり 2 MB 記録され、バックアップは毎週作成されます。また、管理ログの保存に割り当てられている合計容量は 25 MB 以上です （ログレベルの詳細度を上げると、この設定では不十分になる可能性があります）。
POP、IMAP、HTTP のログの場合も、同様の設定から始めてみるとよいでしょう。すべてのサービスに上記のデフォルト値と同じ容量のログが必要だとすると、最初にログを保存するために 150 MB のディスク容量が必要になります （ここに示した設定はあくまでも一般例であるため、実際の条件とは異なる場合があります）。
ログオプションを設定する
メッセージストアのログ設定を制御するオプションは、iPlanet Console あるいはコマンドラインを使って指定できます。これらのオプションの最適な設定は、ログデータが集積される頻度によって異なります。1 MB の保存領域には、約 4,000～10,000 件のログエントリを記録できます。適度に使用されているサーバでは、ログレベルが低い場合 （Notice など）、1 週間あたり数百メガバイトのログデータが記録されます。以下の設定方法を参考にしてください。
使用可能な保存領域の上限に合わせてログレベルを設定します。つまり、使用可能な保存領域の上限に基づき、ログデータの集積頻度を考慮してログレベルを判断します。
ログ情報は、サーバによるログファイルではなく、syslog 機構に送るよう選択することもできます。ログ情報を syslog に送るには、syslogfacility オプションを以下のように設定します。検索処理に影響が出ないように、ログファイルのサイズを設定します。ローテーションスケジュールと合計保存領域の上限を考慮して調整します。ログエントリが集積される頻度に基づいて、ローテーションが自動的に発生するまでに集積されるデータのサイズより少し多めに最大値を設定します。最大ファイルサイズと最大ファイル数を掛け合わせることによって得られる値が、合計保存領域の上限とほぼ等しくなります。
サーバのバックアップが毎週で IMAP ログローテーションが毎日である場合、最大 IMAP ログファイル数を約 10 （個々のログファイルのサイズの上限を越える場合のローテーション頻度を考慮）、および有効期間を 7～8 日に設定します。
- たとえば、IMAP ログローテーションを毎日、1 日あたりに集積される IMAP ログデータが 3 MB、IMAP ログの合計保存領域の上限が 25 MB である場合、IMAP ログファイル の最大サイズは 3.5 MB に設定します （この例では、データ集積頻度が高く、すべてのログファイルが最大サイズおよび最大ファイル数に達するほど速いスピードでデータが集積される場合、ログデータが失われる可能性があります）。
使用するハードウェアの容量とサーバのバックアップスケジュールに基づいて、合計保存領域の上限を設定します。データの集積頻度を予測し、サーバのバックアップ周期を超えないように保存容量の上限値を少し多めに設定します。
安全性を確保するため、ログファイルを保存するボリュームに、最小空きディスク容量を設定します。ログファイルサイズ以外の要因でボリュームがいっぱいになることがあった場合、いっぱいになったディスクにログデータを書き込もうとすることが原因でエラーが発生する前に古いファイルが削除されます。
- たとえば、1 日あたりに集積される IMAP ログデータが平均 3 MB、サーバのバックアップが毎週である場合、IMAP ログの保存領域限度は 25～30 MB に設定します （十分な保存領域があると仮定した場合）。
configutil -o logfile. サービス.syslogfacility -v 値
この場合の サービス には admin、pop、imap、あるいは http を、値 には user、mail、daemon、local0 ～ local7、または none を指定します。
値が設定されると、設定値に対応する syslog 機構のログにメッセージが記録され、その他のすべてのログファイルサービスオプションが無視されます。オプションが設定されていないか、あるいは値が none の場合には、Messaging Server のログファイルが使用されます。
コンソール- iPlanet Console を使ってログオプションを設定するには、以下の手順に従います。
ログファイルオプションを設定する Messaging Server を開きます。
[環境設定] タブをクリックし、左側のパネルで [ログファイル] フォルダを開き、サービス （IMAP、HTTP、Admin など） のログファイルを選択します。
[詳細レベル] ドロップダウンリストからログレベルを選択します。
[ログファイルのディレクトリパス] フィールドに、ログファイルの保存先となるディレクトリの名前を入力します。
[各ログのファイルサイズ] フィールドに、ログファイルの最大サイズを入力します。
[新規ログエントリの作成] フィールドに、ログローテーションスケジュールの値を入力します。
[ディレクトリ当たりのログ数] および [ログが次の日付よりも古い場合] フィールドに、最大ログファイル数と期限を示す値を入力し、バックアップスケジュールとの兼ね合いを調整します。
コマンドライン- コマンドラインでログオプションを設定するには、以下の例のように configutil コマンドを使用します。
configutil -o logfile.サービス.loglevel -v レベル
「サービス」には、admin、pop、imap、または http のいずれかを、「レベル」には、Nolog、Critical、Error、Warning、Notice, Information、または、 Debug のいずれかを指定します。
configutil -o logfile.サービス.logdir -v ディレクトリパス
各ログの最大ファイル サイズを指定するには、以下の手順に従います。
configutil -o logfile.サービス.maxlogfilesize -v サイズ
ログのローテーションスケジュールを指定するには、以下の手順に従います。
configutil -o logfile.サービス.rollovertime -v 数値
ディレクトリ内の最大ログファイル数を指定するには、以下の手順に従います。
configutil -o logfile.サービス.maxlogfiles -v 数値
configutil -o logfile.サービス.maxlogsize -v 数値
確保しておく空きディスク容量の最小値を指定するには、以下の手順に従います。
configutil -o logfile.サービス.minfreediskspace -v 数値
configutil -o logfile.サービス.expirytime -v 数値
ログを検索、表示する
iPlanet Console には、メッセージストアおよび管理に関するログデータを表示するための基本的なインターフェースがあります。個々のログファイルを選択したり、それらのファイル内で柔軟にフィルタリングを行って、ログエントリを検索することができます。ログファイルは、サービスごとに分かれており、それぞれ作成順に表示されます。検索するログファイルを選択し、検索パラメータを指定して個々のイベントの検索対象を限定できます。
検索パラメータ
以下に、表示するログデータを特定するための検索パラメータを示します。
期間 : イベントを読み取る期間の開始と終了を指定するか、または検索する日数 （現時点からさかのぼる日数） を指定します。サーバがクラッシュしたり、その他のイベントが発生した時点までの一定期間のログイベントを調べる場合に使用します。また、記録中のログファイルで今日のイベントだけを見る場合は、期間を 1 日に指定することもできます。
注意 : 検索では、大文字と小文字が区別されます。ログレベル : ログレベルを指定できます （「ログレベル」を参照）。特定の問題を検出するために該当するレベルを選択します。たとえば、サーバがダウンした原因を調べるためには Critical を、失敗したプロトコルコールを検出するためには Error を選択します。
機能 : 機能を指定できます （「ログイベントのカテゴリ」を参照）。問題が含まれている機能領域が分かっている場合には、特定の機能を選択できます。たとえば、サーバのクラッシュにディスクエラーが関連していると思われる場合は Storeを、IMAP プロトコルコマンドに問題があると思われる場合には Protocol を選択します。
テキスト検索パターン : テキスト検索パターンを指定して検索対象を絞ることができます。イベントの構成要素を含めることができます （「ログファイルのフォーマット」を参照）。イベント時刻、プロセス名、プロセス ID、イベントメッセージの一部 (リモートホスト名、関数名、エラー番号など) のイベント構成要素をワイルドカードなどで表現して目的のイベントを指定できます。
- 検索パターンには、以下の特殊文字およびワイルドカード文字を使用できます。
- * 任意の文字セット （例 : *.com）
? 任意の 1 文字（例 : 199?）
[nnn] 中の一連の文字 nnn（例 : [aeiou]）
[^nnn] 一連の文字 nnn 以外の任意の文字 （例 : [^aeiou]）
[n-m] 範囲 n-m 内 の任意の文字 （例 : [A-Z]）
[^n-m] 範囲 n-m 外の任意の文字 （例 : [^0-9]）
\ エスケープ文字 : *、?、[、または ] の前に配置してリテラルとして使用
ログを表示する際にログレベルと機能を組み合せた検索を行う場合は、以下のオプションを含めることができます。
潜在的なセキュリティ違反を調べる際に役立つエラーログを表示するには、Account 機能 （および Notice ログレベル） を指定します。
接続に関する問題を調べるときには、Network 機能 （およびすべてのログレベル） を指定します。
サーバの機能に関する基本的な問題を調べるときには、すべての機能 （および Critical ログレベル） を指定します。
検索を指定し、結果を表示する
指定したサービスに固有のログイベントを検索するには、以下の手順に従います。
iPlanet Console で、ログファイルの対象となる Messaging Server を開きます。
以下のいずれかの方法で、指定したサービスログの [コンテンツ] タブを表示します。
[タスク] タブをクリックし、[<サービス> ログの表示] をクリックします。この場合の<サービス> は、ログに記録されているサービスの名前 （IMAP や Admin など） です。
ログされたサービスの [コンテンツ] タブが表示されます。[環境設定] タブをクリックし、左側のパネルで該当サービス （IMAP や Admin など） のログファイルフォルダを選択します。右側のパネルで [コンテンツ] タブをクリックします。
[ログファイル名] フィールドで、調べたいログファイルを選択します。
[選択したログの表示] ボタンをクリックし、[ログビューア]ウィンドウを開きます。
[ログビューア]ウィンドウで、検索パラメータを指定します （前述の「検索パラメータ」を参照）。
第 3 部 サービスログ （MTA）
MTA には、各メッセージがキューに入ったりキューから取り出されるときに、それらのメッセージをログに記録する機能が備わっています。チャネルごとにログに記録することも、またはすべてのチャネルにおけるメッセージアクティビティをログに記録することもできます。初期設定では、すべてのチャネルでログが無効になっています。ログ機能を有効にすると、メッセージが MTA チャネルを通過するたびに mail.log* ファイルにエントリが追加されます。これらのログエントリは、MTA （あるいは特定チャネル） を通過するメッセージの件数を調べたり、メッセージが送信あるいは配信されたかどうか、いつ送信あるいは配信されたのかなどを調べるときに役に立ちます。
特定の MTA チャネルを通過したメッセージの件数について統計を得るだけであれば、該当する MTA チャネルについてのみ logging チャネルキーワードを有効にするとよいでしょう。ほとんどのサイトでは、すべての MTA チャネルについてログ機能を有効にしています。特に、問題の原因を追求する際には、問題分析の最初のステップとして特定のチャネルにメッセージが送られているかどうかを調べることができるように、すべてのチャネルについてのログが有効になっていると便利です。
ログ機能が有効になっている場合は、mail.log が大きくなりつづけるため、そのままにしておくと使用可能なディスク容量がなくなってしまいます。このファイルのサイズを監視し、定期的に不要なコンテンツを削除するようにしてください。ファイル自体を削除することもできます。その場合は、必要に応じて新しいファイルが作成されます。
MTA のログ機能を有効にする
目的のチャネルについてログ機能を有効にするには、以下の例のように、MTA 設定ファイルのチャネル定義に logging キーワードを追加します。すべてのチャネルについてメッセージアクティビティをログファイルに記録する場合には、defaults チャネルブロックを MTA 設定ファイルのチャネルブロックセクションの冒頭に追加します。例 :
defaults logging
l defragment charset7 us-ascii charset8 iso-8859-01
siroe.comdefaults チャネルは、MTA 設定ファイルの最初の空白行のすぐ後にあるはずです。defaults logging 行の前後には、それぞれ空白行が必要です。
メッセージがキューに入ったりキューから取り出されるたびに、そのメッセージに関するログが記録されます。ログエントリはすべて、MTA ログディレクトリ内の mail.log_current ファイルに記録されます(MTA ログディレクトリ : msg-インスタンス/log/imta/mail.log_current)。
毎晩深夜に実行されるメッセージリターンジョブでは、まず既存の mail.log_yesterday が mail.log というログファイルに追加されます。その後、現在の mail.log_current ファイルが mail.log_yesterday というファイル名に変更され、新規の mail.log_current ファイルが作成されます。connection.log* ファイルについても同様の処理が行われます。
LOG_MESSAGES_SYSLOG オプションを設定して、MTA ログメッセージを syslog に送ることもできます。
その他の MTA ログオプションを指定する
ログ機能を有効にしたときに与えられる基本的な設定のほかにも、MTA オプションファイルでさまざまなMTA オプション LOG_* を設定することにより、オプションの情報フィールドを含めることができます。オプションファイルの詳細については、『Messaging Server リファレンスマニュアル』を参照してください。
LOG_MESSAGE_ID : エントリとメッセージの関連性を示すことができます。
LOG_FILENAME : 特定のメッセージファイルの配信を何回試みたのかを即座に把握できるようになります。また、複数の受信者宛に MTA がいつメッセージを分割し、メッセージファイルをディスクにコピーしたのかを調べる際にも役立ちます。
LOG_CONNECTION が TCP/IP 接続およびメッセージトラフィックのログを記録できます。接続に関するログエントリは、mail.log* ファイルに記録されるようにデフォルトで設定されていますが、connection.log* ファイルに記録することもできます（SEPARATE_CONNECTION_LOG を参照）。
SEPARATE_CONNECTION_LOG : 接続に関するログエントリを connection.log ファイルに記します。
LOG_PROCESS : LOG_CONNECTION といっしょに使用することで、接続エントリとメッセージエントリとの関連性をプロセス ID によって示すことができます。
LOG_USERNAME : メールをキューに入れるプロセスに関連付けられているユーザ名を mail.log ファイルに保存するかどうかを制御します。SASL （SMTP AUTH） を使用している SMTP 送信の場合は、ユーザ名フィールドが認証ユーザ名となります （先頭にアスタリスク「*」が付きます）。
MTA ログエントリのフォーマット
MTA ログファイルは、ASCII テキストとして記述されます。デフォルトでは、図 12-1 に示すように、各ログファイルエントリに 8 個または 9 個のフィールドが含まれます。図 12-1 MTA ログエントリのフォーマット
19-Jan-1998 19:16:57.64 l tcp_local E 1 adam@sesta.com
rfc822;marlowe@siroe.com marlowe@siroe.com
エントリが記録された日付および時刻。
表 12-6 に、ログエントリの各コードを示します。宛先チャネルのチャネル名 （上記の例では tcp_local）。SMTP チャネルの場合は、LOG_CONNECTION が有効になっているとき、プラス記号「+」が SMTP サーバの受信、マイナス記号「-」が SMTP クライアント経由の送信を表します。
エントリのタイプ（上記の例では E）。表 12-6を参照。
メッセージのサイズ（上記の例では l）。デフォルトでは、キロバイト単位に設定されていますが、MTA オプションファイルで BLOCK_SIZE キーワードを使って単位を変更することもできます。
エンベロープ From: アドレス（上記の例では adam@sesta.com）。通知メッセージのように、エンベロープの From: アドレスが空白のメッセージの場合、このフィールドは空白になります。
オリジナルのエンベロープ To: アドレス （上記の例では marlowe@siroe.com）。
LOG_CONNECTION、LOG_FILENAME、LOG_MESSAGE_ID、LOG_NOTARY、LOG_PROCESS、および LOG_USERNAME がすべて有効になっている場合、フォーマットは、図 12-2 のようになります。以下の例ではログエントリ行は改行されて表示されていますが、実際のログエントリは 1 行に記述されます。
図 12-2 その他のフィールドを含むログフォーマット
チャネルプロセスを実行しているノードの名前 （上記の例では HOSTA）。
プロセス ID （16 進数）、およびその後に続くドット文字 （ドット） とカウント。マルチスレッドのチャネルエントリ （tcp_* チャネルエントリなど） の場合は、プロセス ID とカウントの間にスレッド ID が挿入されます。上記の例では 2e2d.2.1 がプロセス ID です。
メッセージの NOTARY （配信受け取りリクエスト） フラグ。整数値で表記 （上記の例では 276）。
MTA キュー領域内のファイル名 （上記の例では /imta/queue/l/ZZ01IWFY9ELGWM00094D.00）。
メッセージ ID （上記の例では <01IWFVYLGTS499EC9Y@siroe.com>）。
実行プロセスの名前 （上記の例では inetmail）。UNIX における SMTP サーバなどのディスパッチャプロセスの場合は、通常 inetmail （SASL が使用されない場合）。
接続情報 （上記の例では siroe.com (siroe.com [192.160.253.66]）。接続情報は、送信システム、チャネル名（送信側システムが HELO/EHLO 行に示す名前など）、あるいは (他の種類のチャネルに対する) チャネルの正式なホスト名から構成されています。TCP/IP チャネルの場合は、送信側システムの正式な名前です。ident* チャネルキーワードを使用して、DNS 逆参照により報告されるシンボリック名や IP アドレスを括弧内に示すこともできます （「IDENT 検索」を参照）。この例では、DNS から見つかった名前と IP アドレスの両方を表示するように選択するキーワードの 1 つ (たとえば、デフォルトの identnone キーワード) が使用されていると仮定しています。
MTA ログファイルを管理する
毎晩深夜に実行されるメッセージリターンジョブでは、まず既存の mail.log_yesterday が mail.log という集積ログファイルに追加されます。その後、現在の mail.log_current ファイルの名前が mail.log_yesterday に変更され、新しい mail.log_current ファイルが作成されます。また、connection.log* ファイルについても同様の処理が行われます。MTA は、自動的にロールオーバーを行って現在のファイルを維持しますが、エントリが累積される mail.log ファイルでは、ファイルのバックアップ、切り捨て、ファイルの削除などのタスクのポリシーを決めて管理する必要があります。
ログファイルの管理方法を考えるときには、MTA の定期的なリターンジョブが、サイトから提供された サーバ-インスタンス/imta/bin/daily_cleanup プロシージャを実行する （該当プロシージャがある場合） ことに注意してください。したがって、サイトによっては、古い mail.log ファイルの名前を 1 週間に 1 回 （または 1 月に 1 回） 変更するなど、独自のクリーンアッププロシージャを適用することがあります。
MTA メッセージログの例
MTA メッセージファイルにログされるフィールドのフォーマットおよびフィールドのリストは、設定したオプションによって異なります。ここでは、いくつかの典型的な例を見ながらログエントリについて解説します。その他のオプションのフィールドについては、「その他の MTA ログオプションを指定する」を参照してください。
注 ここでは、ログファイルエントリの例が複数行にわたって表示されていることがありますが、実際のログファイルエントリは常に 1 行に記述されます。
ログファイルを見直す際、システムでは通常一度に多くのメッセージが処理されていることに留意してください。したがって、特定のメッセージに関連するエントリは、同時に処理された他のメッセージに関連するエントリの中にあります。基本的なログ情報を見ることにより、何件のメッセージが MTA を通過したのかを把握できます。
同じのメッセージに関する特定のエントリをそのメッセージの同じ受信者に関連付けたい場合は、LOG_MESSAGE_ID を有効にします。MTA キュー領域内の特定のメッセージと特定のファイルを関連付けたり、キューからの取り出しに成功していない特定のメッセージの配信試行が何度行われたかをエントリを見て調べたりする場合には、LOG_FILENAME を有効にします。また、SMTP メッセージ （TCP/IP チャネルを経由して処理されるメッセージ） の場合は、リモートシステムとの TCP 接続とメッセージ送信を関連付けるには、LOG_PROCESS と何らかのレベルの LOG_CONNECTION を有効にします。
図 12-3 に、ローカルユーザが TCP/IP チャネルからインターネットなどにメッセージを送信した場合の基本的なログエントリの例を示します。この例では、LOG_CONNECTION が有効になっています。(1) と (2) の行は 1 つのエントリで、実際のログファイルでは 1 行に記述されます。同様に、(3) ～ (7) の行も 1 つのエントリで、実際のログファイルでは 1 行に記述されます。
図 12-3 ログ : ローカルユーザが送信メッセージを送った場合
この行は、ブロックメッセージ (1) をチャネル l から tcp_local チャネルのキューに入れた (E) ときの日付と時刻を示します。
図 12-4 に示すログエントリは 図 12-3 の例に似ていますが、LOG_FILENAME=1 および LOG_MESSAGE_ID=1 を設定したことによって、その他の情報 （ファイル名とメッセージ ID） も示されています。(1) と (2) を参照してください。特に、メッセージ ID は、エントリとメッセージの関連を示すために使用されます。この部分は、実際にはログファイルの行 (1) の後に続く部分です。ここでは、印刷上の理由から改行されています。エンベロープ From: アドレス （adam@sesta.com）、およびエンベロープ To: アドレスの元のバージョンと現在のバージョン （marlowe@siroe.com） を示しています。
ブロックメッセージ (1) を tcp_local チャネルのキューから取り出した (D) ときの日付と時刻を示します。つまり、tcp_local チャネルからリモートの SMTP サーバにメッセージが送信されたことを示します。
エンベロープ From: アドレス、元のエンベロープ To: アドレス、および現在のエンベロープ To: アドレスを示しています。
接続先のシステムは DNS で thor.siroe.com という名前であること、ローカルの送信システムの IP アドレスは 206.184.139.12 で、ポート 2788 から送信していること、およびリモート送信先システムの IP アドレスは 192.160.253.66 で、その接続ポートは 25 であることを示します。
リモート SMTP サーバの SMTP バナー行を示します。
このアドレスに対して返された SMTP ステータスコードを示しています。250 は 基本的な SMTP 成功コードです。また、このリモート SMTP サーバは拡張 SMTP ステータスコードとその他のテキストを返しています。
図 12-4 ログ : オプションのログフィールドを含めた場合
図 12-5 は、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 は同一です。
図 12-5 ログ : リスト宛に送信した場合
図 12-6 は、存在しないドメイン（very.bogus.com） 宛にメッセージを送信しようとした場合の例です。つまり、MTA の書き換え規則によって「存在しない」と判断されないドメイン名で、かつ送信 TCP/IP チャネルに対して一致するドメイン名を使った場合です。この例では、LOG_FILENAME=1 と LOG_MESSAGE_ID=1 という MTA オプションが設定されていると仮定しています。
TCP/IP チャネルが DNS のドメイン名を調べると、DNS はそのような名前は存在しないという旨のエラーを返します。(5) の拒否エントリ (R) のように、DNS は (6) エラーを返し、ドメイン名が不正であることを示します。(6)
メッセージが発行された後でアドレスが拒否されたため、MTA はオリジナルの送信者宛にバウンスメッセージを生成します。MTA は、この新しい拒否メッセージをキューに入れ、オリジナルの送信者 (1) に送り、オリジナルの送信メッセージを削除する前にそのコピーを postmaster (4) に送信します （(5) の R エントリ）。
例の (2) および (8) に示すように、バウンスメッセージなどの通知メッセージのエンベロープ From: アドレスは空白であるため、エンベロープ From: フィールドも空白になります。MTA で生成されたバウンスメッセージが最初のキューに入れられることにより、オリジナルメッセージのメッセージ ID の後に新規通知メッセージのメッセージ ID が示されます (3)。（この情報は、MTA が常に利用できるわけではありません。この情報がログ用に得られる場合には、失敗した送信メッセージに対応するログエントリを通知メッセージに関連付けることができます。） この通知メッセージは、プロセスチャネルのキューに入れられた後、適切な宛先チャネルのキューに送られます (7)。
図 12-6 ログ : 存在しないドメインに送信しようとした場合
図 12-7 は、メッセージがリモートシステムの不正アドレス宛に送信された場合の例を示しています。この例では、LOG_FILENAME=1 と LOG_MESSAGE_ID=1 という MTA オプション設定、および LOG_BANNER=1 と LOG_TRANSPORTINFO=1 というチャネル オプション設定を使用していると仮定しています。(1) の拒否エントリ (R) を見てください。図 12-6 の拒否エントリとは異なり、この拒否エントリにはリモートシステムとの接続が示されています。また、リモート SMTP サーバが発行した SMTP エラーコードも示されています (2)、(3)。(2) に示されている情報は、LOG_BANNER=1 と LOG_TRANSPORTINFO=1 というチャネル オプション設定によるものです。
図 12-7 ログ : 存在しないリモート ユーザ宛に送信した場合
図 12-8 は、MTA がリモート側のメッセージ送信試行を拒否した場合のログファイルエントリを示しています。 この例では、LOG_* オプションが有効になっていないものと仮定しているため、ログエントリには基本的なフィールドしか記述されていません。LOG_CONNECTION オプションを有効にすると、J エントリなどに他の情報フィールドが追加されます。この例は、以下の ORIG_SEND_ACCESS マッピングを使って SMTP リレーブロッキング （「SMTP リレーブロッキングを設定する」 を参照） が設定された MTA に対するものです。
ORIG_SEND_ACCESS
! ...numerous entries omitted...
!
tcp_local|*|tcp_local|* $NRelaying$ not$ permittedalan@very.bogus.com は内部アドレスではありません。したがって、リモートユーザharold@varrius.com が MTA システムを介したリレーを利用してメッセージをリモートユーザ alan@very.bogus.com に送信しようとしても拒否されます。
図 12-8 ログ : リモート側のメッセージ送信試行が拒否された場合
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)
このログは、MTA がリモート側のメッセージ送信を拒否したときの日付と時刻を示します。拒否は J レコードで表されています。MTA チャネルのメッセージ送信が拒否されたことは 図 12-6 および 図 12-7 に示されているように、R レコードで表されます。
図 12-9 に、一回目の試行でメッセージを配信できなかったために、MTA が何度も配信試行を行う場合のログファイル エントリの例を示します。この例では、LOG_FILENAME=1 および LOG_MESSAGE_ID=1 オプションが設定されているものと仮定しています。試行されたエンベロープ From: アドレス および To: アドレスが示されています。この場合、オリジナルの To: 情報がなかったため、そのフィールドは空白になっています。
図 12-9 ログ : 複数回の配信試行が行われた場合
メッセージが tcp_internal チャネルに入ります。これは、おそらく POP クライアントまたは MAP クライアント、あるいは SMTP リレーとして MTA を使った組織内の別のホストからきたものです。MTA は、そのメッセージを出力用の tcp_local チャネルのキューに入れます。
図 12-10 に、メッセージが変換チャネルを通過した場合の例を示します。このサイトには、以下のような CONVERSIONS マッピングテーブルがあるものとします。これが一回目の配信試行であることは ZZ* ファイル名からわかります。
この配信試行は、TCP/IP パッケージがリモート側へのルートを見つけられなかったために失敗しています。図 12-6 とは異なり、DNS は宛先ドメイン名 some.org の存在を否定していません。ホストへのルートがないことを示すエラーにより、送信側と受信側の間にネットワークに関連する問題があったことが示されています。
MTA の定期的なジョブ実行により配信の再試行が行われ、再び失敗しています。
ファイル名が ZY* となり、2 回目の試行であることを示しています。
ファイル名が ZX* となり、3 回目の試行であることを示しています。
定期的なジョブ実行により配信の再試行が行われ、再び失敗しています。ただし、ここでは、TCP/IP パッケージがリモートの SMTP サーバに接続できなかったことが示されているのではなく、リモートの SMTP サーバが接続を受け入れなかったことが示されています。（リモート側におけるネットワーク問題は解消されたが、SMTP サーバをまだ立ち上げていない、あるいはその SMTP サーバのメッセージ処理が追いつかないなどの理由で、MTA の接続試行が受け入れられなかったことが考えられます。）
IN-CHAN=tcp_local;OUT-CHAN=l;CONVERT Yes
この例では、LOG_FILENAME=1 および LOG_MESSAGE_ID=1 オプションが設定されているものと仮定します。
図 12-10 ログ : 変換チャネルを介して送られた受信 SMTP メッセージ
外部ユーザ amy@siroe.edu からのメッセージが届きました。このメッセージは、チャネル l から受信者 bert@sesta.com に渡されるものです。しかし、CONVERSIONS マッピングエントリによって、このメッセージは、直接チャネル l に送られず、最初に変換チャネルのキューに入ります。
図 12-11 は、接続に関するログ機能が有効 (LOG_CONNECTION=3) になっているときの送信メッセージのログ出力例を示しています。この例では、LOG_PROCESS=1、LOG_MESSAGE_ID=1、および LOG_FILENAME=1 オプションが設定されているものとします。この例は、ユーザ adam@sesta.com が 1 つのメッセージ （各メッセージコピーのメッセージ ID は同じであることに注意） を bobby@hosta.sesta.com、carl@hosta.sesta.com、および dave@hostb.sesta.com の 3 人の受信者宛に送信した場合を示しています。また、ここでは、メッセージが single_sys チャネルキーワードで示された tcp_localチャネルから送信されると仮定しています。したがって、(1)、(2)、(3) に示されているように、各ホスト名のそれぞれの受信者について、別のメッセージファイルがディスクに作成されます。bobby@hosta.sesta.com と carl@hosta.sesta.com の受信者は同じメッセージファイルに保存されますが、dave@hostb.sesta.com の受信者は別のメッセージファイルに保存されます。変換チャネルが実行され、メッセージがチャネル l のキューに入ります。
図 12-11 ログ : 送信接続ログ
1 人目の受信者へのメッセージがキューに入れられます。
図 12-12 は、接続に関するログが有効(LOG_CONNECTION=3) になっているときの受信 SMTP メッセージのログ出力例を示しています。続いて、2 人目の受信者へのメッセージがキューに入れられます。
最後に 3 人目の受信者へのメッセージがキューに入れられます。
LOG_CONNECTION=3 が設定されているため、MTA によってこのエントリが書き込まれています。マイナス記号「-」は、このエントリが送信接続であることを示しています。「O」は、このエントリが接続開始に対応したものであることを示しています。接続開始の処理はスレッド 2 とスレッド 3 によって実行されていますが、これらの接続に対するマルチスレッド TCP/IP チャネルには同一のプロセスが使用されているため、プロセス ID「1f625」が同一であることに注意してください。
2 つの異なるリモートシステムに接続するために、マルチスレッド SMTP クライアントがそれぞれの接続を開いています。最初はこのエントリで、2 つ目は (7) に示されています。このエントリには、送信側と受信側の IP 番号とポート番号、および最初のホスト名と DNS 検索で見つかったホスト名の両方が表示されます。SMTP/最初のホスト/dns-ホスト の部分には、最初のホスト名と DNS MX レコード検索を実行した後のホスト名が表示されています。mailhub.sesta.com は、hostb.sesta.com の MX サーバであることがわかります。
マルチスレッド SMTP クライアントが、別のスレッドで 2 つ目のシステムとの接続を開いています （プロセスは同じ）。
2 つの異なるリモートシステムに接続するために、マルチスレッド SMTP クライアントがそれぞれの接続を開きます。2 つ目がこのエントリで、最初の接続は上記の 5 に示されています。このエントリには、送信側と受信側の IP 番号とポート番号、および最初のホスト名と DNS 検索で見つかったホスト名の両方が表示されています。この例では、hosta.sesta.com というシステムがメールを直接受信することがわかります。
この例に示されているように、特定の接続エントリのほか、LOG_CONNECTION=3 によって接続に関連する情報が標準のメッセージエントリに含まれます。
このエントリは、LOG_CONNECTION=3 の設定によって書き込まれます。キューからメッセージ （上記の例では bobby と carl のメッセージ） が取り出され、接続が終了しています。C は接続の終了を表しています。
このエントリは、LOG_CONNECTION=3 の設定によって書き込まれます。キューからメッセージ （上記の例では dave のメッセージ） が取り出され、接続が終了しています。C は接続の終了を表しています。
図 12-12 ログ : 受信接続ログ
リモートシステムが接続を開きます。「O」は、このエントリが接続開始に対応したものであることを示しています。また、「+」は、このエントリが受信接続であることを示しています。
IP 番号とポートが示されています。このエントリから、受信システム （ログファイル エントリを記録しているシステム） の IP アドレスは 206.184.139.12で、接続ポートは 25 であることが分かります。また、送信システムの IP アドレスは 192.160.253.66 で、ポートは 1244 です。
このエントリは、受信 TCP/IP チャネル （tcp_local） からチャネル l の受信者へ送られるメッセージがキューに入ったことを示しています。LOG_CONNECTION=3 が有効になっているため、デフォルト以外の情報も含まれています。特に、送信システムが HELO/EHLO 行に示す名前、接続 IP 番号に関する DNS 逆検索で見つかった送信システムの名前、および送信システムの IP アドレスなどがすべて記録されています。このアクションに影響するチャネルキーワードの詳細については、第 8 章「チャネル定義を設定する」を参照してください。
受信接続が閉じました。「C」は、このエントリが接続終了に対応したものであることを示しています。また、「+」は、このエントリが受信接続であることを示しています。
前へ 目次 索引 次へ
Copyright (c) 2001 Sun Microsystems, Inc. 既存部分の一部: Copyright (c) 2001 Netscape Communications Corp. All rights reserved.
最終更新日 2001 年 5 月 24 日