この節では、メッセージストア (POP、IMAP、および HTTP)、管理、およびデフォルトの各サービスのログについて説明します (表 25–1 を参照)。
これらのサービスの場合、コンソールを使用してログの設定と表示を行うことができます。設定内容は、どのイベントを何件まで記録するかに影響します。これらの設定とその他の特徴を使用して、ログファイル解析時のログイベントの検索条件を微調整することができます。
ここで説明する内容は、次のとおりです。
ここでは、メッセージストアと管理サービスに関するログの特徴 (ログレベル、ログイベントのカテゴリ、ログファイル名の命名ルール、ログファイルのディレクトリ) について説明します。
ログのレベル (優先順位) は、ログのアクティビティーの詳細度を定義します。優先順位レベルが高いほど、詳細度は低くなります。優先順位 (重要度) の高いイベントだけがログに記録されるためです。レベルを下げると、ログは詳細なものとなり、より多くのイベントがログファイルに記録されます。
ログレベルは、logfile.service.loglevel 設定パラメータを設定することによって、POP、IMAP、HTTP、管理、およびデフォルトのサービスごとに個別に設定できます (「25.4.3 サービスログオプションを定義、設定する」を参照)。また、ログレベルを使用して、ログイベントを検索するときにフィルタリングすることもできます。表 25–6 に、利用可能なレベルを示します。これらのログレベルは、UNIX の syslog 機構で定義されるログレベルのサブセットです。
表 25–6 メッセージストアと管理サービスのログレベル
レベル |
説明 |
---|---|
Critical |
もっとも詳細度の低いログです。メールボックスや実行に必要なライブラリにサーバーがアクセスできない場合など、サーバーに重大な問題や致命的な状態が発生したときに、イベントがログに記録されます。 |
Error |
クライアントまたはほかのサーバーへの接続試行に失敗した場合など、エラー状態が発生したときに、イベントがログに記録されます。 |
Warning |
サーバーがクライアントから送られた通信を解釈できない場合など、警告状態が発生したときに、イベントがログに記録されます。 |
Notice |
ユーザーがログインに失敗したり、セッションが終了したりした場合など、通知 (正常だが重要な状況) が発生したときに、イベントがログに記録されます。これがデフォルトのログレベルです。 |
Information |
ユーザーがログオンやログオフを行なったり、メールボックスを作成したり名前を変更した場合など、重要なアクションが行われたときに、イベントがログに記録されます。 |
Debug |
もっとも詳細度の高いログです。デバッグを行う場合にのみ役立ちます。各プロセスまたはタスク内の個々のステップごとにイベントがログに記録されるため、問題の箇所を正確に突き止めることができます。 |
特定のログレベルを選択すると、そのレベルのイベントとそれ以上のレベル (詳細度の低い) のイベントがログに記録されます。デフォルトのログレベルは、Notice です。
より詳細なログを指定するほど、ログファイルがより多くのディスク容量を占有することになります。ガイドラインについては、「25.4.3 サービスログオプションを定義、設定する」を参照してください。
サポートされているサービスまたはプロトコル内で、Messaging Server は、どの機能領域で発生したかに基づいて、ログイベントをより細かくカテゴリに分類します。各ログイベントには、それを生成した機能領域の名前が含まれています。これらのカテゴリは、イベントを検索する際のフィルタリングに使用できます。表 25–7 に、Messaging Server がログのために認識するカテゴリのリストを示します。
表 25–7 ログイベントの発生場所のカテゴリ
機能領域 |
説明 |
---|---|
General |
プロトコルまたはサービスに関連するアクション全般です |
LDAP |
LDAP ディレクトリデータベースにアクセスする Messaging Server に関連するアクションです |
Network |
ネットワークの接続に関連するアクションです (ソケットエラーはこのカテゴリに分類される) |
Account |
ユーザーアカウントに関連するアクションです (ユーザーログインはこのカテゴリに分類される) |
Protocol |
プロトコル固有のコマンドに関連するプロトコルレベルのアクションです (POP、IMAP、または HTTP 機能によって返されるエラーはこのカテゴリに分類される) |
Stats |
サーバーの統計収集に関連するアクションです |
Store |
メッセージストアへのアクセスに関連する低レベルのアクションです (読み取りまたは書き込みエラーはこのカテゴリに分類される) |
ログ検索でカテゴリをフィルタとして使用する場合の例については、「25.4.4 サービスログを検索、表示する」を参照してください。
ログ記録される各サービスごとに、1 つのディレクトリが割り当てられ、ログファイルはそこに保存されます。IMAP ログファイルや POP ログファイルなどの各サービスのログファイルは、それぞれのディレクトリ内に一緒に保存されます。各ディレクトリの場所、そのディレクトリ内に保存できるログファイルの数、およびファイルのサイズを設定することができます。
すべてのログファイルを保存するのに十分な容量があることを確認してください。ログレベルが低い (詳細度が高い) ほど、ログファイルのサイズは大きくなります。
ログレベル、ログローテーション、ログの有効期間、およびサーバーのバックアップポリシーを正しく定義することが重要です。ログファイルディレクトリのすべてがバックアップされ、また、過負荷にならないようにするためです。これらを正しく定義しないと、情報を失ってしまうことがあります。「25.4.3 サービスログオプションを定義、設定する」を参照してください。
Messaging Server によって作成されたメッセージストアおよび管理サービスのログファイルのコンテンツの形式は、すべて同じです。ログファイルは複数行のテキストファイルであり、各行に 1 つのログイベントが記述されています。サポートされている各サービスに対するすべてのイベントは、通常は以下のような形式で記述されています。
dateTime hostName processName[pid]: category logLevel: eventMessage
表 25–8 に、ログファイルのコンポーネントを示します。このイベント記述形式は、日付/時刻形式が異なることと追加コンポーネント (category と logLevel) があることを除けば、UNIX の syslog 機構で定義されているものと同じです。
表 25–8 メッセージストアと管理サービスのログファイルのコンポーネント
コンポーネント |
定義 |
---|---|
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 (例 25–5 を参照) |
logLevel |
イベントのログレベル。例: Notice (例 25–4 を参照) |
eventMessage |
イベント固有の説明メッセージで、長さは任意です。例: Log created (894305624) |
以下に、ログに記録されたイベントの例を 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 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 などのイベント内の特定のコンポーネントを検索することによって、表示するイベントを制限することができます。詳細は、「25.4.4 サービスログを検索、表示する」を参照してください。
各ログエントリのイベントメッセージは、記録されるイベントのタイプに固有の形式です。つまり、各サービスのイベントメッセージに表示される内容は、各サービスによって定義されています。多くのイベントメッセージは単純で明白なものですが、複雑なものもあります。
メッセージストアおよび管理サービスのログ設定は、管理者のニーズに合わせて定義することができます。ここでは、最適な設定とポリシーを決定するために役立つ情報と、それらの適用方法を説明します。
ログファイルのネーミングの形式 (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 バイトものログデータが記録されることもあります。以下の設定を参考にしてください。
使用可能な保存領域の上限に合わせてログレベルを設定します。つまり、使用可能な保存領域の上限に基づき、ログデータの累積頻度を考慮してログレベルを判断します。
検索処理に影響が出ないように、ログファイルのサイズを設定します。ローテーションのスケジュールと合計保存容量の上限を考慮して調整します。ログエントリの累積頻度に基づいて、最大値を設定してもかまいません。この最大値は、ローテーションが自動的に発生するまでに蓄積されるサイズよりも少し大きめのサイズに設定します。最大ファイルサイズとファイルの最大数を掛けて得られる値が、合計保存領域の上限とほぼ等しくなります。
たとえば、IMAP ログローテーションが毎日、1 日当たりに累積される IMAP ログデータが 3M バイト、IMAP ログの合計保存領域の上限が 25M バイトの場合、IMAP ログファイルの最大サイズは 3.5M バイトに設定します。この例では、すべてのログファイルが最大サイズと最大ファイル数に達してしまうほど急速にログデータが蓄積された場合は、いくつかのログデータが失われる可能性があります。
サーバーのバックアップを週 1 回行い、IMP ログファイルを毎日ローテーションする場合、IMAP ログファイルの最大数を約 10 個 (個々のログサイズの上限を超える場合のローテーション頻度を考慮) と指定し、最長保存期間を 7 日または 8 日に指定します。
ハードウェアの容量とサーバーに対して計画したバックアップスケジュールに基づいて、合計保存領域の上限を設定します。ログデータの累積頻度を予測し、サーバーのバックアップ周期を超えないように合計保存容量の上限を少し大きめに設定します。
たとえば、IMAP ログファイルデータの累積が 1 日平均 3M バイト、サーバーのバックアップが週 1 回の場合、ディスクの保存領域が十分にあることを前提として、IMAP ログの記憶領域の上限は 25 〜 30M バイトに設定します。
安全性を確保するため、ログファイルを保存するボリュームに、最小空きディスク容量を設定します。ログファイルサイズ以外の要因によってボリュームがいっぱいになった場合は、いっぱいになったディスクにログデータを書き込もうとして障害が発生する前に、古いログファイルが削除されます。
ログファイルには、メッセージストアおよび管理サービスに関するログデータを表示するための基本的なインタフェースがあります。ログファイルはサービスごとに分かれており、それぞれ作成順に一覧表示されます。検索するログファイルを選択したら、検索パラメータを指定して検索対象を個々のイベントに限定することができます。
以下に、ログデータを表示するために指定できる便利な検索パラメータを示します。
期間: イベントを検索する期間の開始と終了を指定するか、検索する日数 (現時点からさかのぼる日数) を指定します。サーバーのクラッシュやその他の問題の原因となったログイベントを調べるために、通常は期間の範囲を指定します。また、現在のログファイルの中で今日のイベントだけを見る場合は、期間を 1 日に指定することもできます。
ログのレベル: ログレベルを指定できます (「25.4.1.1 ログレベル」を参照)。たとえば、サーバーがダウンした原因を調べる場合は Critical、失敗したプロトコルコールを検出する場合は Error を指定します。
機能領域: 機能領域を指定できます (「25.4.1.2 ログイベントのカテゴリ」を参照)。たとえば、サーバーのクラッシュにディスクエラーが関連していると思われる場合は Store、問題が IMAP プロトコルコマンドエラーにあると思われる場合は Protocol を選択します。
テキスト検索パターン: テキスト検索パターンを指定して検索対象を絞ることができます。検索するイベントについてすでにわかっているイベント時刻、プロセス名、プロセス ID、およびイベントメッセージの一部 (リモートホスト名、関数名、エラー番号など) などのイベントコンポーネント (「25.4.2 サービスログファイルの形式について」を参照) を使用して検索できます。
検索パターンには、次の特殊文字およびワイルドカード文字を使用することができます。
* 任意の文字セット (例: *.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 ログレベル) を指定します。
この節では、ログを検索および表示するための configutil コマンドを使用してサービスログを使用する方法について説明します。
次のように 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 ログファイルが使用されます。
使用しているシステムが HTTP メッセージアクセス (Web メール) をサポートしていない場合は、次の変数を設定して HTTP のログを無効にできます。システムに Web メールサポート (たとえば、Messenger Express) が必要な場合は、これらの変数を設定しないでください。
次のように configutil コマンドを実行します。
configutil -o service.http.enable -v no configutil -o service.http.enablesslport -v no
次のように configutil コマンドを実行します。
configutil -o logfile.service .loglevel -v level
ここで、service は admin、pop、imap、imta、または http に、loglevel は Nolog、Critical、Error、Warning、Notice、Information、または Debug になります。
次のように configutil コマンドを実行します。
configutil -o logfile.service.maxlogfilesize -v size |
size にはバイト数を指定します。
次のように configutil コマンドを実行します。
configutil -o logfile.service.rollovertime -v number |
number には秒数を指定します。
次のように configutil コマンドを実行します。
configutil -o logfile.service.maxlogfiles -v number |
number にはログファイルの最大数を指定します。
次のように configutil コマンドを実行します。
configutil -o logfile.service.maxlogsize -v number |
number にはバイト数を指定します。
次のように configutil コマンドを実行します。
configutil -o logfile.service.minfreediskspace -v number |
number にはバイト数を指定します。
configutil -o logfile.service.expirytime -v number |
number には秒数を指定します。
MTA がメッセージを追跡する方法と同様に、メッセージ ID によってメッセージを追跡するためにメッセージストアのログを使用できます。この方法でメッセージを追跡すると、メッセージのライフサイクルの重要なイベントを追跡できます。
メッセージストアログのメッセージを追跡するには、通常のログ設定に加えてメッセージの追跡も設定する必要があります。デフォルトでは、メッセージの追跡は有効になっていません。
メッセージの追跡は、ディスク領域を大量に使用します。十分なディスク容量がないかぎり、この機能を有効にしないでください。
メッセージストアのログは、次の操作を追跡できます。
append (付加) - メッセージストアライブラリがメッセージをフォルダに追加する主な方法。append の追跡は、メッセージストアに入るメッセージを示します。
fetch (フェッチ) - エンドユーザーのためにメッセージまたはメッセージの一部を取得する IMAP コマンド。メッセージの追跡のために、この意味はエンドユーザーが読むためにサービスがメッセージを取得する場合にまで拡大されます。
メッセージの追跡では、メッセージの本体の部分が取得された場合にのみ本体の取り込みとみなされるように、メッセージのヘッダーが読み取られたときの追跡を避ける必要がある場合があります。
expunge (消去) - IMAP の用語であり、この場合この意味は任意のサービスがユーザーのフォルダからメッセージを削除する場合にまで拡大されます。
次のように configutil コマンドを実行します。
configutil -o local.mstrace.active -v “yes” |
メッセージの追跡情報は、プロセスごとにデフォルトのログに書き込まれます。IMAP fetch は、imap ログファイルに書き込まれます。ims_master append は、ims_master チャネルログファイルに書き込まれます。
メッセージの追跡ログを単一の「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" |
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 "" |
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 間の対話を記録することができます。「20.14.1.3 テレメトリを使用してユーザーの IMAP/POP/Webmail セッションをチェックする」を参照してください。
メッセージストアログファイルにログ記録されるフィールドの形式とフィールドのリストは、設定したログオプションによって異なります。ここでは、いくつかの典型的なログエントリの解釈の例を示します。
ユーザーが無効なパスワードを入力すると、「ユーザーが見つからない」というメッセージではなく「認証」の失敗がログに記録されます。セキュリティー上の理由から、クライアントには「ユーザーが見つからない」というメッセージが渡されますが、ログには本当の理由 (無効なパスワード) が記録されます。
[30/Aug/2004:16:53:05 -0700] vadar imapd[13027]: Account Notice: badlogin: [192.18.126.64:40718] plaintext user1 authentication failure |
次の例は、無効になったアカウントが原因でユーザーがログインできない理由を示しています。さらに、無効になったアカウントは「(inactive)」または「(hold)」として明示されます。
[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」を記録します。
[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」を記録します。
[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> |
メッセージストアは、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 ファイルに重複して記録されます。次に、正常なログインメッセージを示します。
[30/Aug/2004:16:53:13 -0700] vadar imapd[13027]: Account Information: login [192.18.126.64:40718] user1 plaintext |