上一页
目录
索引
下一页
|
上一页
目录
索引
下一页
|
|
| iPlanet Messaging Server 5.2 管理员指南 | |
第 13 篇 日志记录和日志分析
iPlanet Messaging Server 可创建用来记录有关事件的日志文件，这些事件涉及管理、用服务器所支持的任何一种协议（SMTP、POP、IMAP 和 HTTP）的通信、以及由服务器所进行的其他处理。通过检查日志文件，可以监控服务器运行的许多方面。因为 MTA 使用一个区别于其他服务的单独的日志工具，所以不能用 iPlanet Console 配置日志服务和查看日志。但是可以通过在配置文件中指定信息来配置 MTA 日志记录。因此，本章共分为三部分。第一部分提供总的介绍性信息；第二部分介绍邮件存储库与管理服务的日志记录问题；第三部分介绍 MTA 服务的日志记录问题。
第二部分：服务日志（邮件存储库、Administration Server 和 MTA）
第一部分：绪论
您可自定义创建和管理 Messaging Server 日志文件的策略。本章介绍日志文件的类型和结构，并讨论如何管理和如何查看日志文件。这一部分由下列分节组成：
日志服务
日志服务
Messaging Server 可为每一种所支持的主要协议或服务分别创建一组日志文件。这样就可单独制定、查看每一种类型日志文件。表 13-1 列出了可记录的服务，并对每一项服务的日志文件进行了说明。
服务
日志文件说明
以 Administration Server 的方式，包含与 iPlanet Console 和 Messaging Server 之间通信有关的日志事件（主要通过几个 CGI 进程）。
用第三方工具分析日志
对于超出了 iPlanet Messaging Server 能力的日志分析和报告生成事项，需要使用其他的工具。可以借助于文本编辑器或标准的系统工具自己操纵日志文件。通过使用一种支持正则表达式分析的可使用脚本语言的文本编辑器，可以做到在本章所讨论的任何标准的基础上搜索和抽取日志条目，并可对结果进行分类，甚至生成合计或其他统计数据。
在 UNIX 环境下，您还能够修改和使用已有的、被开发来操纵 UNIX syslog 文件的报告生成工具。如果希望使用一个不受版权限制的 syslog 操纵工具，切记需要修改该工具以解决不同日期/时间格式问题和两个额外组件（facility 和 logLevel）的问题，这两个组件在 Messaging Server 日志条目中显示，而不在 syslog 条目中显示。
第二部分：服务日志（邮件存储库、Administration Server 和 MTA）
本节对以下服务的日志记录进行了说明：POP、IMAP、HTTP、MTA、Admin 和 Default（参见表 13-1）。对于这些服务，您可使用 iPlanet Console 指定日志设置并查看日志文件。所指定的设置影响到日志事件的种类和数量。当分析日志文件时，可使用这些设置和其他特性来改善对日志事件的搜索。有关 MTA 使用的服务日志方面的附加说明，请见“第三部分：服务日志（MTA）”。
日志特性
日志特性
本节说明了下面这些邮件存储库和管理服务的日志特性：日志记录级别、日志事件的种类、日志文件名约定和日志文件目录。
日志记录级别
日志记录的级别，或称为优先级，定义了日志记录活动的详细程度（冗长度）。优先级较高意味着详细程度较低；这也意味着只有较高优先级（高重要性等级）的事件才记录到日志中。级别较低意味着详细程度较高；这也就意味着日志文件中记录了更多的事件。您可分别为每一项服务 - 即 POP、IMAP、HTTP、Admin 和 Default - 分别设置日志记录的等级，方法是通过设置 logfile.service.loglevel 配置参数（见“定义和设置日志记录选项”）。您还可用日志记录等级筛选通过搜索获得的日志事件。表 13-2 说明了这些可用的等级。这些日志记录级别是 UNIX syslog 功能的一个子集。
一旦选择了一个特定的日志记录级别，对应于该级别，以及所有更高（较不冗长）级别的事件都将记录到日志中。日志记录的默认级别为 Notice。
备注： 设置的日志记录越冗长，日志文件所占用的磁盘空间就越大；关于这一问题的指导方针，参见“定义和设置日志记录选项”。
日志事件的种类
在每一个所支持的服务或协议中，Messaging Server 依据工具或事件所发生的功能区对日志事件进一步分类。所有记录事件都包含了生成该事件的工具的名字。依据这样的分类可在搜索时过滤事件。表 13-3 列出了 Messaging Server 能识别的日志事件种类。有关在日志搜索中将事件种类用作过滤器的范例，请参见“搜索并查看日志”。
邮件存储库与管理日志的文件名约定
POP、IMAP、HTTP、Admin 和 Default 服务的日志文件使用相同的命名约定。每一个文件具有如下形式的文件名：表 13-4 列出了邮件存储库日志文件名的约定。
组件
定义
指定此日志文件创建顺序的整数，这是相对于日志文件目录中的其他日志文件而言的。较高顺序号的日志文件相对于较低顺序号的日志文件要更新一些。顺序号不循环使用，在服务器生命周期（从服务器安装开始）内单调增长。
指定文件创建的日期与时间的整数。（其数值以标准的 UNIX 时间表示：从 1970 年 1 月 1 日午夜开始的秒数。）
例如，一个名为 imap.63.915107696 的日志文件应该是 IMAP 日志文件目录中创建的第 63 个日志文件，它创建于 1998 年 12 月 31 日下午 12:34:56。
将末端开放的顺序计数方式与时间戳相结合，使得为分析而轮换、终止和选择文件更为便利。关于更多的相关建议，参见“定义和设置日志记录选项”。
日志文件目录
每一项日志服务被分配到一单个目录中，它的日志文件即存储于该目录中。如同所有的 POP 日志文件和其他服务中的日志文件一样，所有的 IMAP 日志文件存储在一起。要为每一个目录定义位置，还须定义目录的最大空间以及该空间中允许存储的日志文件的最大数量。须确保存储容量足够容纳所有的日志文件。日志数据可占有相当大的空间，在较低的日志记录级别（更冗长）情况下更是如此。
定义日志记录级别、日志轮换、日志终止以及服务器备份策略等也是很重要的。这可使所有的日志文件目录都能备份，而且不会出现超载情况；否则，会丢失信息。请参阅“定义和设置日志记录选项”。
日志文件格式
所有由 Messaging Server 创建的邮件存储库和管理服务日志文件具有相同的内容格式。日志文件为多行文本文件，其中的每一行中描述一个日志事件。对于每一种所支持的服务，所有事件描述都具有如下所示的通用格式：dateTime hostName processName[pid]:category logLevel:eventMessage
表 13-5 列出了日志文件的各个组件。注意，除了日期/时间格式不同以及格式中包含了两个额外的组件（category 和 logLevel）外，这里的事件描述格式与 UNIX 的 syslog 工具所定义的格式相同。
组件
定义
事件被记录到日志的日期和时间，表示为 dd/mm/yyyy hh:mm:ss 格式，并有一时区字段，表示为 +/-hhmm，相对于 GMT。例如：
02/Jan/1999:13:08:21 -0700注意：如果主机中有一个以上的 Messaging Server 实例，您则可用进程 ID（pid）将不同实例的日志事件分隔开。
事件所属类别：例如，General（参见表 13-3）。
事件所表现的日志记录级别：例如，Notice（参见表 13-2）。
下面是三个可用 iPlanet Console 查看的日志事件的例子：
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 事件条目的结尾可有三个数。上面的例子中有0 115 0。第一个数是客户机发送的字节，第二个数是服务器发送的字节，第三个数是所选的邮箱（POP 永远是 1）。
通过“日志查看器”（Log Viewer）窗口查看一日志文件时，通过搜索事件中的任何指定的组件（例如一个指定的日志记录级别、种类或一个指定的进程 ID），可限制显示出的事件的数量。有关详情，请参见“搜索并查看日志”。
每个日志条目的事件消息的格式都是该日志事件类型所特有的格式：也即，每一项服务定义了什么内容将出现在它的事件消息中。许多事件消息是简单明了的；但也有较复杂的消息。
定义和设置日志记录选项
可定义邮件存储库和和管理服务的日志记录配置以更好地满足管理上的需要。本节讨论的问题有助于就最佳配置和策略做出决策，并解释如何实现。
灵活的日志记录体系
日志文件（service.sequenceNum.timeStamp）的命名方案有助于设计一个灵活的日志轮换和备份策略。事实上，由于不同服务的事件被写入不同的文件中，使得快速分离问题变得更容易。另外，由于文件名中的顺序号总是递增的，而且时间戳总是唯一的，因此后创建的日志文件不会因耗尽了有限数量的顺序号而简单地覆盖先创建的日志文件。反之，只有到达时限、文件数量或总存储空间这些更为灵活的限制时，老日志文件才被覆盖或删除。Messaging Server 支持日志文件的自动轮换，这简化了管理，方便了备份。无须手工废除当前日志文件并创建一个新日志文件以容纳随后的日志事件。可随时对目录中除当前日志文件以外的所有文件进行备份，而无须停止服务器或手工通报服务器去启动一个新的日志文件。
在确立了日志记录策略后，可设置选项（对于每一项服务而言）以控制总日志存储空间、日志文件的最大数量、单个文件大小、文件最大时限以及日志文件轮换频率等限制。
规划所需的选项
需要注意的是，必须设置若干种限制，而且其中不止一个可使日志文件被轮换或被删除。哪个限量先到达，哪个限量就是起控制作用的限制条件。例如，若最大日志文件空间为 3.5MB，而且指定每天创建一个新日志文件，则当日志数据增长速率大于每 24 小时 3.5MB 时，实际创建日志文件的速率大于每天一个。因此，若日志文件的最大数量为 10，日志文件的最大时限为 8 天，就有可能永远无法达到该时限。这是因为，较快的日志文件轮换速率意味着在不到 8 天的时间内要创建 10 个日志文件。为 Messaging Server 的管理日志提供的下列默认值，可能是规划的一个合理的出发点：
目录中日志文件的最大数量： 10
最大日志文件空间：2 MB
所有日志文件总的最大空间：20 MB
最小可用磁盘空间：5 MB
日志轮换时间：1 天
最大时限：7 天
日志记录级别：Notice（通知）可以看出，这种配置是基于这样的假定：服务器管理日志数据预计以每天 2MB 的速率积累，备份为每周一次，而分配给总管理日志的存储空间至少为 25MB。（若日志记录级别更为冗长，这些设置可能不够充分。）
对于 POP、IMAP 或 HTTP 日志而言，采用与默认同样的值也许是合理的开端。如果所有服务都具有与前面列出的默认值几乎相同的日志存储需求，则一开始可按 150MB 的估计值安排总日志存储空间。（需要注意的是，这仅仅是一个大概的存储空间需求；实际存储空间需求可能有很大的不同。）
设置日志记录选项
您可用 iPlanet Console 或命令行来设置选项以控制邮件存储库日志记录配置文件。这些选项的最优设置取决于日志数据累积的速率。这个速率可能是每 4000 到 10000 个日志条目占用 1MB 存储空间。在更冗长的日志记录级别（如 Notice）情况下，一个适度繁忙的服务器每周可生成几百兆字节的日志数据。下面是一个可采用的方案：
设置一个与存储空间限制相一致的日志记录级别，也就是这样一种日志记录级别，它使得估计的日志数据累积速率与用以估计存储空间限制的速率大致相同。
需要注意的是，可以选择将日志信息发送给 syslog 工具，而非服务器所支持的日志文件。通过按如下方式设置 syslogfacility 选项以将日志信息发送到 syslog：定义日志文件的空间，以便执行搜索不受影响。还需进一步调整，使之与轮换空间安排和总存储空间限制协调一致。对于给定的日志条目累积速率，应设置一个比预期略大的最大值，以适应轮换自动发生时的累积。文件的最大空间乘以文件的最大数量应大致等于总存储空间限制。
若服务器每周备份一次，IMAP 日志文件每天轮换一次，则需将 IMAP 日志文件的最大数量指定为大约 10 个（考虑到由于单个文件达到存储空间限制而使轮换加速的情况），最大时限为 7 或 8 天。
- 例如，若 IMAP 日志设置为每天轮换一次，则所预期的 IMAP 日志数据累积速率为每天 3MB，而 IMAP 日志的总存储空间限制为 25MB，则可将 IMAP 日志文件的最大空间设置为 3.5MB。（在这个例子中，若累积太快，以至于所有的日志文件都达到最大空间，且达到日志文件最大数量，则仍会丢失一些日志数据。）
在硬盘容量范围内挑选一个总存储空间限制，使之与为服务器所规划的备份时间安排协调一致。估计出日志数据累积的速率，加上安全因素，即可定义总存储空间限制，使到达该限制的时间不至于超过两次备份之间的时间。
为安全起见，挑选一个在保存日志文件的卷中容许的最小自由磁盘空间容量。用这种方法，若是由除日志文件空间以外的因素导致卷空间被充满，则在把日志文件写入已满磁盘而导致失败之前，老日志文件将被删除。
- 例如，若预期 IMAP 日志文件数据的平均累积速率为每天 3MB，服务器备份每周一次，则应当为 IMAP 日志设置一个 25-30MB 等级的存储空间限制（假定磁盘存储空间足够大）。
configutil -o logfile.service.syslogfacility -v value
其中，service 是 admin、pop、imap、imta 或 http 和 value 是 user、mail、daemon、local0 至 local7，或为无。
若设置了“值”，邮件被记录到对应与设置值的 syslog 工具，而其他日志文件服务选项均被忽略。若没有设置选项，或值被设置为 none，日志记录将使用 Messaging Server 的日志文件。
Console 使用 iPlanet Console 设置日志记录选项：
打开要设置其日志文件选项的 Messaging Server。
单击“配置”选项卡，打开左面板中的 Log Files 文件夹，选择一项服务（例如 IMAP、HTTP 或 Admin 等）的日志文件。
在“创建一个新日志，每隔：”字段中，为日志轮换计划输入一个数。
在“每个目录的日志数量”和“如果一个日志生成时间超过”这两个字段中，输入与备份时间安排相协调的最大日志文件数和最大时限。
命令行 在命令行中设置选项须使用 configutil 命令，如下例所示：
configutil -o logfile.service.loglevel -v level
其中，service 是 admin、pop、imap、imta 或 http 和 loglevel 是 Nolog、Critical、Error、Warning、Notice、Information 或 Debug。
configutil -o logfile.service.logdir -v dirpath
configutil -o logfile.service.maxlogfilesize -v size
configutil -o logfile.service.rollovertime -v number
configutil -o logfile.service.maxlogfiles -v number
configutil -o logfile.service.maxlogsize -v number
configutil -o logfile.service.minfreediskspace -v number
configutil -o logfile.service.expirytime -v number
搜索并查看日志
iPlanet Console 提供了一个查看邮件存储和管理日志数据的基本界面。通过它可以选择单个日志文件，并可对文件中的日志条目进行灵活的带过滤的搜索。对于一个给定的服务，日志文件是按日期时间顺序列出的。一旦选定一个日志文件进行搜索，通过指定搜索参数，可缩小单个事件的搜索范围。
时间段。可以指定一特定时间段的起始和结束时间以便从该时间段中检索事件，也可以指定一个（在此之前的）日数来搜索。当发生了服务器崩溃或其他类似事件而且知道发生时间时，通常可以设置一个范围来找到相关的事件。或者也可以指定日范围，仅查看当前日志文件中当天发生的事件。
注释：搜索须区分大小写的。日志记录级别。可设置一个日志记录级别（参见“日志记录级别”）。应选择一个特定的级别来发现一个特定的问题；例如，Critical 可用来寻找服务器崩溃的原因，Error 可用于定位失败的协议调用。
工具。可指定一个工具（参见“日志事件的种类”）。如果知道包含问题的功能区，可选择一个特定的工具；例如，如果认为服务器崩溃是由磁盘错误引起的，则应选择 Store；如果问题的产生是由于 IMAP 协议的命令错误，则应选择 Protocol。
文本搜索模式。可提供一个文本搜索模式以进一步缩小搜索范围。在定义要检索的事件时，可以包含事件的任何部件（参见“日志文件格式”），只要它能在通配符类型的搜索中表示出来，诸如事件时间、进程名、进程 ID 以及事件消息的任何部分（例如远程主机名、功能名、错误号等等）。
- 搜索模式中可以包含下列特殊字符和通配符：
- * 任何字符集（例如：*.com）
? 任何单字符（例如，199?）
[nnn]nnn 集里的任何字符（例如：[aeiou]）
[^nnn] 不在集合 nnn 中的任何字符（例如：[^aeiou]）
[n-m] 范围 n-m 中的任何字符（例如：[A-Z]）
[^n-m] 不在范围 n-m 中的任何字符（例如：[^0-9]）
\转换参数：置于 *、?、[或]之前以将它们用做常值（即字符本身）。
关于将日志记录级别与工具相结合以查看日志，请参见下面的例子：
指定搜索项和查看结果
遵循以下步骤，用属于一个给定服务的指定特性来搜索日志事件：
在 iPlanet Console 中，打开要对其日志文件进行检查的 Messaging Server。
按两种步骤中的任何一种，显示一给定日志服务中的日志文件内容选项卡：
单击“任务”选项卡，然后单击“查看服务日志”选项，这里的服务与是日志记录服务的名称（如“IMAP 服务”或“管理”）。
该日志服务的“内容”选项卡完整显示出来。单击“配置”选项卡，然后打开左面板中的 Log Files 文件夹，选择一项服务的日志文件（例如 IMAP 或 Admin）。然后单击右面板中的“内容”选项卡。
在“日志阅读器”窗口中，指定所需的搜索参数（在前节已有说明，“搜索参数”）。
第三部分：服务日志（MTA）
MTA 提供的工具可记录每一封入队和出队的邮件。此外，它还可提供调度程序出错和调试输出。第二部分包含以下各节：
启用 MTA 的日志记录功能
可逐个通道控制日志记录，也可设定对所有通道上活动的邮件都进行日志记录。在初次配置中，日志记录在所有通道上都被禁用。启用了日志记录后，每当邮件通过 MTA 通道时，MTA 都会把一个条目写入 mail.log* 文件中。若希望获得有多少邮件通过 MTA（或特定的通道）的统计数据，或者调查一邮件是否或何时被发送或传递之类的问题时，这些日志条目是很有用的。
如果您感兴趣的只是在若干特定 MTA 通道上通过的邮件数这样的统计数据，则可以只在那些感兴趣的 MTA 通道上启用日志记录通道关键字。许多站点更喜欢在所有 MTA 通道上启用日志记录。特别地，如果试图跟踪问题，则诊断问题的第一步就是注意到邮件并没有通过预期的或预定的通道，而针对所有通道启用日志记录有助于调查此类问题。
如果启用了记录功能，mail.log 会逐渐增大，若任其增大而不管，该文件会消耗所有可用磁盘空间。因此，必须监控这个文件的大小，定期删除不需要的内容。您也可删除整个文件，然后根据需要创建另一个版本。
启用 MTA 的日志记录功能
若需为一特定通道启用日志记录，须将关键字 logging 添加到 MTA 配置文件的通道定义中，如下例所示：channel-name keyword1 keyword2 logging
此外，您还可设置一些配置参数，如日志文件的目录路径、日志级别等。请参阅“第二部分：服务日志（邮件存储库、Administration Server 和 MTA）”。
如果希望所有通道的日志消息对日志文件都是活动的，则只需简单地将一 defaults 通道块添加在 MTA 配置文件的通道块节的开头部分即可。例如：
defaults logging
l defragment charset7 us-ascii charset8 iso-8859-01
siroe.comdefaults 通道将紧跟在 MTA 配置文件中的在第一个空白行后出现。defaults logging 所在行的前一行和后一行都应当是空白行，这一点十分重要。
每个邮件都按入、出队列的方式记入日志。所有的日志条目都放在 MTA 日志目录的 mail.log_current 文件中：msg-instance/log/imta/mail.log_current。
邮件退回工作，主要在半夜时分运行，将任何存在的 mail.log_yesterday 添加到累积日志文件 mail.log 中，再将当前的 mail.log_current 文件更名为 mail.log_yesterday，然后启用一个新的 mail.log_current 文件。系统对任何 connection.log* 文件也执行类似的操作。
您可将 MTA 邮件记录发送到 syslog (UNIX) 或 event log (Windows NT)，方法是将 LOG_MESSAGES_SYSLOG 选项设置为 1。0 是默认设置，用于指示系统不进行 syslog (event log) 记录。
指定其它 MTA 日志记录选项
除了当日志记录被启用时总是提供的基本信息以外，通过设置 MTA 选项文件中的各种 LOG_* MTA 选项，还可将指定额外的、可选的信息字段包含于其中。关于选项文件的完整细节，请参见 iPlanet Messaging Server Reference Manual。
LOG_MESSAGE_ID。 此选项可用来确立条目与邮件的关联关系。
LOG_FILENAME。此选项使获得传递一特定邮件文件的重试次数更为容易，而且对于理解邮件分割（MTA 有可能将一邮件分割为多个收件人并存入磁盘中的不同邮件文件拷贝中）是很有用的。
LOG_CONNECTION。 该选项致使 MTA 对 TCP/IP 连接和邮件流通量进行日志记录。连接日志条目按默认值方式写入 mail.log* 文件，也可选择将其写入 connection.log* 文件；参见 SEPARATE_CONNECTION_LOG 选项。
SEPARATE_CONNECTION_LOG。 此选项用于指定将连接日志条目写入文件 connection.log。
LOG_PROCESS. 与 LOG_CONNECTION 结合使用时，此选项建立由进程 ID 标识的连接条目与邮件条目的对应关系。
LOG_USERNAME。 此选项控制与一个处理邮件队列的进程相关联的用户名是否保存在文件 mail.log 中。由于 SMTP 规范中使用了 SASL（SMTP AUTH），因此用户名字段中应是经过认证的用户名（以星号为前缀）。
MTA 日志条目格式
MTA 日志文件以 ASCII 码文本写入。在默认状态下，每一个日志文件条目包含八九个字段，如图 13-1 所示。图 13-1 MTA 日志条目格式
19-Jan-1998 19:16:57.64 l tcp_local E 1 adam@sesta.com
rfc822;marlowe@siroe.com marlowe@siroe.com
生成条目的日期和时间。
表 13-6 说明日志记录条目代码。目标通道的通道名（例中的 tcp_local）。（对于 SMTP 通道，当 LOG_CONNECTION 被启用时，用加号 + 表示入站到 SMTP 服务器；用减号 - 表示经由 SMTP 客户机出站)。
条目类型（E）；参见表 13-6。
邮件大小（1）。默认单位为千字节，可通过使用 MTA 选项文件中的 BLOCK_SIZE 关键字改变这个默认单位。
信封发件人：地址（adam@sesta.com）。注意有的邮件其信封发件人：地址是空的，例如通知邮件，该字段就是空的。
信封收件人：地址的原格式（marlowe@siroe.com）。
条目
说明
有些是成功的收件人中，但此收件人暂时不成功；所有收件人原邮件文件出列，取而代之的是，一个为此受件人以及其他不成功收件人而创建的新邮件文件将立即入列。
SMTP 通道的 LOG_CONNECTION + 或 - 条目
在 LOG_CONNECTION、LOG_FILENAME、LOG_MESSAGE_ID、LOG_NOTARY、LOG_PROCESS 以及 LOG_USERNAME 都启用的情况下，格式改变情况如图 13-2 所示。（由于印刷上的原因，日志条目行被折行；实际的日志条目应显示在一个物理行上。）
图 13-2 带附加字段的日志格式
通道进程得以运行的节点的名称（例中的 HOSTA）。
进程 ID（以十六进制表示），后跟一逗号（点）和一计数。如果它是一个多线程通道条目（例如，tcp_* 通道条目），就会在进程 ID 和计数之间出现一个线程 ID。在示例中，进程 ID 为 2e2d.2.1。
邮件的 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 行中呈现的名字（对于到访 SMTP 邮件），或入列通道的正式主机名（对于其他类型的通道）。对于 TCP/IP 通道而言，发送系统的“真”名，即通过 DNS 反向查找发现的象征性名字和/或 IP 地址，也可在通道关键字 ident* 的控制下呈现在括弧内；参见“IDENT 查找”。在这个例子中，假定使用其中的一个关键字，以默认关键字 identnone 为例，它意味着显示从 DNS 中找到的名字和 IP 地址。
管理 MTA 日志文件
邮件退回工作，主要在半夜时分运行，将任何存在的 mail.log_yesterday 添加到累积日志文件 mail.log 中，再将当前的 mail.log_current 文件更名为 mail.log_yesterday，然后启用一个新的 mail.log_current 文件。对于任何 connection.log* 文件也执行类似的操作。MTA 自动执行轮换以维护当前文件，但必须针对备份文件、截断文件、删除文件等等任务确定一个策略，以便管理累积文件 mail.log。
在考虑如何管理日志文件的问题时，需要注意的是，MTA 的周期性回复工作将执行网站提供的 server-instance/imta/bin/daily_cleanup 程序，如果存在的话。因此，某些站点可能选择提供自己的清理程序更名旧的 mail.log 文件，例如每周一次（或每月一次，等等）。
MTA 邮件日志记录示例
作为日志记录在 MTA 邮件文件中的字段格式和字段列表是多样化的，确切情况完全取决于对日志记录选项所做的设置。本节展示一些解释典型的日志条目类型的例子。对于其它可选的字段的说明，参见“指定其它 MTA 日志记录选项”。
备注： 由于印刷上的原因，日志文件条目会呈现在多行中。在实际环境中，每个日志文件条目只占用一行。
检查日志文件时需要注意的是，在一个典型的系统中，许多邮件会被同时处理。具有代表性的是，与一个特定邮件有关的条目会散布于与其他邮件有关的条目中，而这些“其他邮件”也正在相同的时间里被处理。通过基本日志信息可获得经由 MTA 移动的邮件总数的大致情况。
如果希望将与同一邮件有关的特定条目与同一收件人相关联，可能需要启用 LOG_MESSAGE_ID。如果希望将 MTA 队列区内的特定邮件与特定文件相关联，或希望通过查看条目了解某尚未成功出队的邮件尝试传递的次数，可能需要启用 LOG_FILENAME。对于（通过 TCP/IP 通道进行处理的）SMTP 邮件，如果需要将往来于远程系统的 TCP 连接与发送的邮件相关联，可能需要启用 LOG_PROCESS 以及 LOG_CONNECTION 的某些级别。
图 13-3 展示了一个相当基本的涉及某些类型的日志条目的例子。如果一个本地用户通过一个外发 TCP/IP 通道发送一邮件到 Internet，即可见到例子中的条目类型。在本例中，LOG_CONNECTION 被启用。标有（1）和（2）的行是一个条目，在实际的日志文件中该条目出现在一个物理行中。类似地，标有（3）-（7）的行也是一个条目，也应出现在一个物理行中。
图 13-3 日志记录：一本地用户发送一外发邮件
此行表明，从 l 通道到 tcp_local 通道的入列（E）日期和时间。
图 13-4 所示为类似于图 13-3 中的日志记录条目，不同的是，通过设置 LOG_FILENAME=1 和 LOG_MESSAGE_ID=1 而显示文件名和邮件 ID 等附加的日志信息；参见（1）和（2）。特别是邮件 ID 可用于建立条目与邮件的关联。这是（1）中日志文件的同一物理行的一部分，只是为了印刷上的方便才另行显示。它显示了信封发件人：地址，在此例中为 adam@sesta.com，以及原始版本和当前版本的收件人：地址，在此例中为 marlowe@siroe.com。
此行表明，一组（1）邮件从 tcp_local 通道出列（D），即由 tcp_local 通道成功发送到远程 SMTP 服务器的日期与时间。
此行表明，信封发件人：地址，原信封收件人：地址，以及当前格式的收件人：地址。
此行表明，连接得以建立的 DNS 中的实际系统被命名为 thor.siroe.com；本地发送系统具有 IP 地址 206.184.139.12，发送端口为 2788；远程目标系统具有 IP 地址 192.160.253.66，远程目标系统上的连接端口为 25。
此行表明了为此地址返回的 SMTP 状态码；250 是基本的 SMTP 成功代码，而且，这个远程 SMTP 服务器以扩展 SMTP 状态码和一些附加文本加以响应。
图 13-4 日志记录：包含可选日志记录字段
图 13-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 中。需要注意的是，对于每个收件人，原信封收件人：地址都是 test-list@sesta.com，尽管当前信封收件人：地址是各不相同的地址。注意，尽管涉及到两个不同的文件（一个针对 l 通道，而另一个针对外发的 tcp_local 通道），邮件 ID 却始终保持不变。
图 13-5 日志记录：发送到列表
图 13-6 说明了试图向一个不存在的域（在此为 very.bogus.com）发送邮件；也即，发送到一个未被 MTA 重写规则宣布为不存在的域名而且 MTA 匹配到一个外发 TCP/IP 通道。此例假定 MTA 选项设置为 LOG_FILENAME=1 和 LOG_MESSAGE_ID=1。
当 TCP/IP 通道运行并检查 DNS 中的域名时，DNS 返回的错误讯息表明该名字不存在。请注意“rejection”条目（R），见（5），以及 DNS 返回的出错讯息，说明此乃一非法域名，见（6）。
由于地址被拒收是发生在邮件被提交后，所以 MTA 生成一个退回到原发件人的邮件。MTA 将新的拒收邮件入列到原发件人（1）处，在删除原出站邮件（显示于（5）中的 R 条目）之前，发送给 Postmaster（4）一个副本。
通知类邮件，如退回邮件，具有空的信封发件人：地址，如（2）和（8）中所见到的，其中的信封发件人：字段显示为空白。由 MTA 生成的退回邮件的初始入列显示新通知邮件的邮件 ID，后跟一个原邮件（3）的邮件 ID。（这样的信息对于 MTA 并不总是可用的，但当可被日志记录时，可用于建立对应于出站失败邮件的日志条目与对应于结果通知邮件的条目之间的关联。）这样的通知邮件入列到进程通道中，然后再次入列到适当的目标通道（7）中。
图 13-6 日志记录：发送到不存在的域
图 13-7 说明了试图发送错误的地址到远程系统。这个例子假定 MTA 选项设置为 LOG_FILENAME=1 和 LOG_MESSAGE_ID=1，通道选项设置为 LOG_BANNER=1 和 LOG_TRANSPORTINFO=1。注意拒收条目（R），参见（1）。相对于图 13-6 中的拒收条目，对这里的拒收条目需要注意的是，它表明到远程系统的连接已建立，并显示了远程 SMTP 服务器所生成的 SMTP 错误码，参见（2）和（3）。显示在（2）中的信息内容是由通道选项设置 LOG_BANNER=1 和 LOG_TRANSPORTINFO=1 决定的。
图 13-7 日志记录：发送到不存在的远程用户
图 13-8 说明了当 MTA 拒收一远程端试图 提交的一邮件时，所产生的那一类日志文件条目。（在这个例子中，假定没有任何可选的 LOG_* 选项被启用，因此仅有基本字段被记录到日志条目中。应特别注意，启用 LOG_CONNECTION 选项，会导致在这样的 J 条目中包函额外的信息字段。）在这种情况之下，这个例子是为了说明已经以 ORIG_SEND_ACCESS 映射设置了 SMTP 转发阻塞的 MTA（参见“配置 SMTP 转发阻塞”），该映射包含：
ORIG_SEND_ACCESS
! ...numerous entries omitted...
!
tcp_local|*|tcp_local|* $NRelaying$ not$ permitted且该处的 alan@very.bogus.com 不是内部地址。因此，远程用户 harold@varrius.com 通过 MTA 系统向远程用户 alan@very.bogus.com 转发的尝试被拒收。
图 13-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 通道试图发送一个被拒收的邮件的情况，由 R 记录表明，如图 13-6 和图 13-7 所示）。
图 13-9 说明了这样因下面的原因而产生的那一类日志文件条目：一邮件在初次尝试时不能传递，所以 MTA 试图多次发送该邮件。这个例子假定选项设置为 LOG_FILENAME=1 和 LOG_MESSAGE_ID=1。图 13-9 日志记录：多次传递尝试
进入 tcp_internal 通道的邮件，无论来自 POP 或 IMAP 客户，还是来自使用 MTA 作为 SMTP 转发的组织内的另一个主机，MTA 均将之入列到外发的 tcp_local 通道中。
图 13-10 说明邮件经过转换通道而进行路由选择的情况。站点假定有一个如下所示的 CONVERSIONS 映射表：当 TCP/IP 包无法找到一个通往远程用户的路由时这次传递尝试失败。与图 13-6 不同的是，DNS 并不拒绝目标域名 some.org；相反，“no route to host”错误表明，是在发送方和接收方之间出现了一个网络方面的问题。
当 MTA 作为定期工作下一次运行它时，再次尝试传递，但再次失败。
下一次定期工作再次尝试传递时，传递又失败，尽管这次 TCP/IP 包没有抱怨它不能通往远程 SMTP 服务器，而实际原因是远程 SMTP 服务器没有接受连接。（或许远程端已经确定了问题之所在,但他们的 SMTP 服务器尚未恢复；或者该 SMTP 服务器正忙于处理其他邮件而没有在 MTA 试图连接时接受连接。）
IN-CHAN=tcp_local;OUT-CHAN=l;CONVERT Yes
这个例子假定选项的设置为 LOG_FILENAME=1 和 LOG_MESSAGE_ID=1。
图 13-10 日志记录：到访 SMTP 邮件通过转换通道路由
来自外部用户 amy@siroe.edu 的邮件到达，所标注的地址是 l 通道收件人bert@sesta.com。然而，CONVERSIONS 的映射条目致使邮件初始入列到转换通道（而不是直接到 l 通道）。
图 13-11 说明了当连接日志记录通过选项设置 LOG_CONNECTION=3 而被启用时，一外发邮件的日志输出。本例还假定 LOG_PROCESS=1，LOG_MESSAGE_ID=1 和 LOG_FILENAME=1。本例显示了这样一种情况：用户 adam@sesta.com 发送同一邮件（注意，所有邮件副本的邮件 ID 都是相同的）给三个收件人的情况，这三个收件人是 bobby@hosta.sesta.com，carl@hosta.sesta.com 和 dave@hostb.sesta.com。本例假定邮件输出到一个标有（正如这类通道的通常情况那样）single_sys 通道关键字的 tcp_local 通道中。因此，磁盘上将为每一个不同主机名上的收件人分别创建一个邮件文件，如（1）、（2）以及（3）所示，其中收件人 bobby@hosta.sesta.com 和 carl@hosta.sesta.com 存储于同一邮件文件中，但收件人 dave@hostb.sesta.com 则存储于另一个邮件文件中。图 13-11 日志记录：出站连接日志记录
邮件入列到第一个收件人
图 13-12 说明了通过 LOG_CONNECTION=3 启用连接日志记录时，到访 SMTP 邮件的日志输出情况。设置 LOG_CONNECTION=3 使 MTA 写入该条目。减号 - 表示该条目涉及到一个外发连接。O 意味着该条目对应连接的打开操作。还需注意的是，这里的进程 ID 是相同的，即 1f625，这是因为针对这些不同连接的打开操作，多线程 TCP/IP 通道所使用的是同一个进程，尽管这里的打开操作是由线程 2 及线程 3 所实施。
由于有两个不同的远程系统需要连接，在不同线程中的多线程 SMTP 客户机分别打开一个每个系统的连接，第一个在此条目中，第二个见 7 中所示。条目这部分显示了发送方和目标方的 IP 地址和端口号，同时也显示了初始主机名，以及通过执行 DNS 查寻找到的主机名。在 SMTP/initial-host/dns-host 子句中，注意初始主机名和在初始主机名上执行 DNS MX 记录查询找到的主机名的显示：mailhub.sesta.com 显然是 hostb.sesta.com 处的 MX 服务器。
在不同的线程（通过同一个进程）中，多线程 SMTP 客户打开到第二个系统的连接。
由于有两个不同的远程系统需要连接，在不同线程中的多线程 SMTP 客户机分别打开一个与每个系统的连接，第二个在此条目中，第一个见 5 中所示。条目这部分显示了发送方和目标方的 IP 地址和端口号，同时也显示了初始主机名，以及通过执行 DNS 查寻找到的主机名。在本例中，系统 hosta.sesta.com 显然是直接收邮件的。
除了产生具体的连接条目中外，LOG_CONNECTION=3 也使与连接有关的信息包含在常规邮件条目中，如例中所示。
LOG_CONNECTION=3 致使 MTA 写入此条目。在所有邮件（本例中的 bobby 和 carl）出列后，连接被关闭，如此条目中的 C 所示。
LOG_CONNECTION=3 致使 MTA 写入此条目。在所有邮件（本例中的 dave）出列后，连接被关闭，如此条目中的 C 所示。
图 13-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 篇 “配置通道定义”中关于影响此行为的通道关键字的讨论。
Dispatcher 调试和日志文件
Dispatcher 的错误和调试输出（如果启用的话）将被写入 MTA 日志记录目录中的 dispatcher.log 文件。调试输出可用 Dispatcher 配置文件中的 DEBUG 选项启用，或用 IMTA_DISPATCHER_DEBUG 环境变量（UNIX）在每一进程上启用。
DEBUG 选项或 IMTA_DISPATCHER_DEBUG 环境变量（UNIX）以十六进制定义了 32 位的调试掩码。若需启用所有调试项，可将该选项设置为 -1，或将全系统的逻辑或环境变量定义为值 FFFFFFFF。每一比特的实际意义请见表 13-7。
比特
十六进制值
十进制值
用途
Solaris 上的系统参数
系统的堆大小（datasize）必须足以容纳 Dispatcher 的线程栈用量。因为每项 Dispatcher 服务都计算 STACKSIZE*MAX_CONNS，然后总计每项服务的计算值。系统的堆大小至少需为此数的两倍。Dispatcher 配置文件中提供的 Dispatcher 服务可影响对各种系统参数的要求。
若需显示堆大小（即默认的 datasize），可用 csh 命令：
上一页 目录 索引 下一页
(c) 2002 年 Sun Microsystems, Inc. 版权所有。
更新日期：2002 年 2 月 27 日