第 23 章 监视 Messaging Server

在大多数情况下，一个经过很好计划和很好配置的服务器在执行时不需要管理员的过多介入。但是，作为管理员，监视服务器的问题信号是您的工作。本章介绍 Messaging Server 的监视。其中包含以下各节：

• 每天的监视任务

• 监视系统性能

• 监视 MTA

• 监视邮件访问

• 监视 LDAP Directory Server

• 监视邮件存储

• 用于监视的实用程序和工具

有关故障排除的过程，请参见第 22 章，MTA 故障排除。

自动监视和重新启动

Messaging Server 提供了一种方法，可以透明地监视服务并在服务崩溃或不响应（服务挂起或冻结）时自动重新启动服务。它可以监视所有邮件存储、MTA 和 MMP 服务，包括 IMAP、POP、HTTP、作业控制器、分发程序和 MMP 服务器。它不监视其他服务，例如 SMS 或 TCP/SNMP 服务器。（TCP/SNMP 由作业控制器监视。）请参见失败的服务或未响应服务的自动重新启动和使用 msprobe 和 watcher 功能进行监视。

每天的监视任务

应当每天执行的最重要的任务是检查邮寄主管邮件、监视日志文件和设置 stored 实用程序。下面介绍这些任务。

检查邮寄主管邮件

Messaging Server 具有一个为邮寄主管电子邮件设置的预定义的管理邮递列表。属于此邮递列表的所有用户将自动接收发给邮寄主管的邮件。

RFC822 中定义了邮寄主管邮件的规则，它要求每个电子邮件站点都接受发送给名为邮寄主管的用户或邮递列表的邮件，并且发送到此地址的邮件应当传送给一个实际的个人。发送到 postmaster@host.domain 的所有邮件都被发送到邮寄主管帐户或邮递列表。

通常，邮寄主管地址是用户应当发送有关其邮件服务的电子邮件的位置。作为邮寄主管，您可能会收到来自本地用户有关服务器响应时间的邮件、来自其他服务器管理员（他们在向您的服务器发送邮件时遇到问题）的邮件等等。您应当每天检查邮寄主管邮件。

您也可以将服务器配置为向邮寄主管地址发送特定的错误消息。例如，当 MTA 无法路由或传送邮件时，您可以通过发送给邮寄主管地址的电子邮件得到通知。您还可以向邮寄主管发送异常情况警告（磁盘空间不足、服务器响应迟缓）。

监视和维护日志文件

Messaging Server 为其支持的每个主要协议或服务（包括 SMTP、IMAP、POP 和 HTTP）分别创建了一组单独的日志文件。这些日志文件位于 msg_svr_base/data/log 中。您应当将监视这些日志文件作为例行程序，尤其是在服务器出现问题时。

请注意日志记录可能会影响服务器性能。在给定的时间内指定的日志记录越详尽日志文件所占用的磁盘空间越多。您应当为服务器定义有效且实际的日志旋转、失效和备份策略。有关为服务器定义日志记录策略的信息，请参见第 21 章，管理日志记录。

设置 msprobe 实用程序

msprobe 实用程序将自动执行监视和重新启动功能。有关详细信息，请参见使用 msprobe 和 watcher 功能进行监视

监视系统性能

虽然本章重点介绍的是 Messaging Server 监视，但是还需要监视服务器所在的系统。很好配置的服务器在未经过很好优化的系统上无法获得很好的性能，服务器的故障症状可能表明硬件不足以支持电子邮件负载。本章未提供有关监视系统性能的所有详细信息，因为其中的许多过程都是特定于平台的，并且可能要求您参考特定于平台的系统文档。下面介绍了性能监视的过程：

• 监视端对端邮件传送时间

• 监视磁盘空间

• 监视 CPU 使用情况

监视端对端邮件传送时间

电子邮件需要按时传送。这可能是一项服务协议要求，但尽快传送邮件也是一个很好的策略。较长的端对端时间可能预示着许多问题。可能是服务器运行不正常，或者是在一天中的特定时间内发生了邮件超负荷的情况，或者是对现有硬件资源的使用已经超出了它们的能力。

低效的端对端邮件传送时间的症状

邮件的传送时间比正常情况下要长。

监视端对端邮件传送时间

• 使用发送和接收邮件的任一工具。比较服务器中继器之间的标题时间以及起始点和检索点之间的时间。请参见immonitor-access。

监视磁盘空间

磁盘空间不足是导致邮件服务器出现问题和故障的最常见原因之一。如果没有用于写入到 MTA 队列或写入到邮件存储的空间，邮件服务器将会失败。此外，除非监视并清除日志文件，否则它们会无节制地增长并填满所有磁盘空间。

邮件存储分区将随着新邮件传送到邮箱而增长；例如，如果不强制邮件存储配额，邮件存储可能会超出分区的可用磁盘空间。导致磁盘空间耗尽的另一个原因是 MTA 邮件队列增长得过大。涉及的第三个方面为问题是否因日志文件监视工具和日志文件增长失控而发生。（请注意，有许多日志文件，例如 LDAP、MTA 和邮件访问，其中的每个日志文件都可以存储在不同的磁盘上。）

磁盘空间问题的症状

根据耗尽空间的磁盘或分区不同，所出现的症状会有所不同。MTA 队列会溢出并拒绝 SMTP 连接，邮件可能保留在 ims_master 队列中而没有传送到邮件存储，并且日志文件会溢出。

如果邮件存储分区填满，则邮件访问守护进程可能会失败，邮件存储数据可能会被破坏。邮件存储维护实用程序（例如 imexpire 和 reconstruct）可以修复损坏并减少磁盘使用量。但是，这些实用程序需要其他磁盘空间，而且修复填满整个磁盘的分区可能会导致停机。

监视磁盘空间

根据系统配置，您可能需要监视各种磁盘和分区。例如，MTA 队列、邮件存储和日志文件可能分别位于不同的磁盘/分区上。其中的每个空间都需要监视，并且监视这些空间的方法也可能不同。

Messaging Server 提供特定的方法，以监视邮件存储磁盘空间的使用并防止分区填满所有可用磁盘空间。

您可以执行以下步骤来监视邮件存储的磁盘空间使用情况：

• 设置参数以监视邮件存储磁盘空间的使用

• 达到磁盘使用量阈值时锁定邮件存储分区

有关详细信息，请参见以下内容：监视邮件存储和监视邮件存储分区。

监视邮件存储

建议邮件存储的磁盘使用量不要超过磁盘容量的 75%。您可以通过配置以下警报属性（使用 configutil 实用程序）来监视邮件存储的磁盘使用量：

• alarm.diskavail.msgalarmstatinterval

• alarm.diskavail.msgalarmthreshold

• alarm.diskavail.msgalarmwarninginterval

• alarm.diskavail.msgalarmdescription

通过设置这些参数，您可以指定系统应监视磁盘空间的频率以及系统应在什么情况下发送警告。例如，如果您希望系统每 600 秒监视磁盘空间一次，请指定以下命令：

configutil -o alarm.diskavail.msgalarmstatinterval -v 600

如果您希望无论何时当可用磁盘空间低于 20% 时都接收到警告，请指定以下命令：

configutil -o alarm.diskavail.msgalarmthreshold -v 20

有关这些参数的更多信息，请参见表 23–6。

监视邮件存储分区

当邮件分区填充超过可用磁盘空间的指定百分比时，您可以停止向邮件存储分区传送邮件。设置两个 configutil 参数以启用此功能并指定磁盘使用量阈值，即可完成此设置。

邮件存储守护进程可以使用此功能来监视分区磁盘使用量。随着磁盘使用量的增加，存储守护进程将更加频繁地动态检查分区（从每 100 分钟一次到每 1 分钟一次）。

如果磁盘使用量超过指定的阈值，存储守护进程将：

• 锁定该分区。外来邮件将保存在 MTA 邮件队列中而不传送到邮件存储分区中的邮箱。

• 将邮件记录到默认日志文件中。

• 向邮寄主管发送电子邮件通知。（您可以通过设置 configutil 参数 alarm.msgalarmnoticercpt 来更改电子邮件的收件人。)

磁盘使用量降至阈值以下时，分区将取消锁定，邮件将再次传送到存储。

configutil 参数如下所示：

• local.store.checkdiskusage 启用分区监视功能。

  允许的值：yes、no

  默认值：yes

• local.store.diskusagethreshold 指定磁盘使用量阈值。local.store.diskusagethreshold 的值为 1% 到 99%。

  默认值：99

应将磁盘使用量阈值设置为一个足够低的百分比，以便有时间重新进行分区或为本地邮件存储指定更多的磁盘空间。

例如，假设分区以每小时 2% 的速率填充磁盘空间，并且需要一个小时的时间为本地邮件存储分配其他磁盘空间。在这种情况下，应将磁盘使用量阈值设置为低于 98% 的值。

监视 MTA 队列和日志记录空间

您需要监视 MTA 队列和日志记录空间的磁盘使用量。

有关管理日志记录空间的信息，请参见第 21 章，管理日志记录。例如，要了解如何监视 mail.log 文件，请参见管理 MTA 邮件和连接日志。

监视 CPU 使用情况

高 CPU 使用情况表明针对该使用级别没有足够的 CPU 容量，或者某些进程使用的 CPU 周期数超出了正常范围。

CPU 使用情况问题的症状

系统响应时间长。用户的登录缓慢。传送率低。

监视 CPU 使用情况

监视 CPU 使用情况是一个特定于平台的任务。请参见相关的平台文档。

监视 MTA

本节包含以下几个部分：

• 监视邮件队列的大小

• 监视传送失败率

• 监视入站 SMTP 连接

• 监视分发程序和作业控制器进程

监视邮件队列的大小

邮件队列的过度增长可能表明邮件没有被传送出去、传送被延迟或者传入速度比系统所能传送它们的速度要快。这可能是由多种原因造成的，例如由系统中泛滥的大量邮件导致拒绝服务攻击，或者作业控制器未运行。

有关邮件队列的更多信息，请参见通道邮件队列、邮件未被排出队列和未传送 MTA 邮件。

邮件队列问题的症状

• 磁盘空间使用量增长。

• 用户没有在合理的时间内收到邮件。

• 邮件队列大小异常大。

监视邮件队列的大小

监视邮件队列的最好方法可能是使用 imsimta qm。请参见imsimta qm counters。

您也可以监视队列目录 (msg_svr_base/data/queue/) 中文件的数量。文件数量是特定于站点的，您需要建立一个基线历史记录以找出文件数量“过多”的标准。这可以通过记录两周内队列文件的大小获得一个近似平均值来完成。

监视传送失败率

传送失败是指尝试将邮件传送给外部站点时失败。传送失败率的大幅增加可能是出现网络问题（例如 DNS 服务器死机或者远程服务器在响应连接时超时）的信号。

传送失败率的症状

没有外部症状。mail.log_current 中会出现很多 Q 记录。

监视传送失败率

传送失败将记录在 MTA 日志中，日志记录条目代码为 Q。可以在文件 msg_svr_base/data/log/mail.log_current 中查看该记录。示例：

mail.log:06-Oct-2003 00:24:03.66 501d.0b.9 ims-ms Q 5 durai.balusamy@Sun.COM rfc822;durai.balusamy@Sun.COM durai@ims-ms-daemon <00ce01c38bda$c7e2b240$6501a8c0@guindy> Mailbox is busy

监视入站 SMTP 连接

来自给定 IP 地址的入站 SMTP 连接数的异常增长可能表示：

• 外部用户正在尝试转发邮件。

• 外部用户正在尝试进行拒绝服务攻击。

未经授权的 SMTP 连接的症状

• 外部用户转发邮件：没有外部症状。

• 拒绝服务攻击：外部用户尝试用邮件请求使 SMTP 服务器过载。

监视入站 SMTP 连接

• 外部用户转发邮件：在 msg_svr_base/log/mail.log_current 中查找具有日志记录条目代码 J（拒绝的转发）的记录。要启用远程 IP 地址的日志记录，请向 option.dat 文件添加以下行：

  log_connection=1

  请注意，启用此功能要付出少量性能代价。

• 拒绝服务攻击：要查找连接到 SMTP 服务器的用户及其数量，可以运行命令 netstat 并检查 SMTP 端口（默认值：25）上的连接。示例：

Local address       Remote address                                 State
192.18.79.44.25     192.18.78.44.56035    32768   0  32768   0   CLOSE_WAIT
192.18.79.44.25     192.18.136.54.57390    8760   0  24820   0   ESTABLISHED
192.18.79.44.25     192.18.26.165.48508   33580   0  24820   0   TIME_WAIT

请注意，您首先需要确定系统的 SMTP 连接的适当数量及其状态（ESTABLISHED、CLOSE_WAIT 等），以便确定某次特定的读取是否超出了正常范围。

如果发现很多连接处于 SYN_RECEIVED 状态，则可能是由网络断开或拒绝服务攻击造成的。此外，SMTP 服务器进程的生存期是有限的。它是由 dispatcher.cnf 文件中的 MTA 配置变量 MAX_LIFE_TIME 控制的。默认值为 86,400 秒（一天）。与此类似，MAX_LIFE_CONNS 可以指定服务器进程在其生存期内所能处理的最大连接数。如果发现某个特定的 SMTP 服务器已经运行了很长时间，则可能需要进行调查。

监视分发程序和作业控制器进程

分发程序和作业控制器进程必须运行，MTA 才能工作。您应当具有每一种进程。

分发程序和作业控制器进程故障的症状

如果分发程序出现故障或没有足够的资源，则 SMTP 连接将被拒绝。

如果作业控制器出现故障，则队列的大小将增加。

监视分发程序和作业控制器进程

检查是否存在名为 dispatcher 和 job_controller 的进程。请参见检查作业控制器和分发程序是否正在运行。

监视 LDAP Directory Server

本节包含以下几个部分：

• 监视 slapd

监视 slapd

LDAP Directory Server (slapd) 为邮件服务系统提供目录信息。如果 slapd 出现故障，系统将无法正常工作。如果 slapd 响应时间太长，则会影响登录速度以及需要使用 LDAP 进行查找的任何其他事务。

slapd 问题的症状

• 客户机 POP、IMAP 或 Webmail 验证失败或者比预期的速度慢。

• MTA 无法正常工作

监视 slapd

• 检查 ns-slapd 进程是否在运行。

• 检查 slapd-instance/logs/ 中的 slapd 日志文件 access 和 errors。

• 检查搜索用户时 ns-slapd 的响应时间。

• 查看 Console 以监视 slapd。

• 另请参见immonitor-access

监视邮件访问

本节包含以下几个部分：

• 监视 imapd、popd 和 httpd

• 监视 stored

监视 imapd、popd 和 httpd

这些进程提供了对 IMAP、POP 和 Webmail 服务的访问。如果其中的任何进程未运行或未响应，则服务将无法正常工作。如果服务正在运行，但是出现了过载情况，您可以通过监视检测到这种情况并对其进行更合适的配置。

imapd、popd 和 httpd 问题的症状

连接被拒绝或系统的连接速度太慢。例如，如果 IMAP 未在运行而您尝试直接连接至 IMAP，则会看到类似如下的内容：

telnet 0 143 Trying 0.0.0.0... telnet: Unable to connect to remote host: Connection refused

如果尝试与客户机连接，则会收到一条消息，例如：

Client is unable to connect to the server at the location you have specified. The server may be down or busy.

监视 imapd、popd 和 httpd

• 可以使用 watcher 和 msprobe 进行监视。请参见失败的服务或未响应服务的自动重新启动和使用 msprobe 和 watcher 功能进行监视

• 可以使用 SNMP 进行监视。

  如果您设置了 SNMP，则这是监视这些进程的一个非常好的方法。请参见附录 A，SNMP 支持。服务器信息位于网络服务监视 MIB 中。

• 检查日志文件。

  查看 msg_svr_base/log/service 目录，其中 service 可以是 http、IMAP 或 POP。在该目录中，您会找到许多日志文件。其中一个文件名是 service 的名称（imap、pop 或 http），其他文件名是服务名称加上序列号以及级联至该服务名称的日期。例如：

  imap imap.29.1010221593 imap.31.1010394412 imap.33.1010567224

  只具有服务名称的文件是最新的日志。其他文件按序列号排列（在这里是 29、31、33），序列号最大的文件是次新的文件。（请参见第 21 章，管理日志记录。）

  如果服务器被关闭，您可能会看到类似如下的内容：

  imap.12.1065431243:[07/Oct/2003:01:15:43 -0700] gotmail-2 imapd[20525]: General Warning: Sun Java System Messaging Server IMAP4 6.1 (built Sep 24 2003) shutting down

• 可以使用 counterutil 进行检查。请参见counterutil和《Sun Java System Messaging Server 6 2005Q4 Administration Reference》中的“counterutil”。

• 运行特定于平台的命令来验证 imapd、popd 和 httpd 进程是否正在运行。例如，在 Solaris 中，可以使用 ps 命令并查找 imapd、popd 和 mshttpd。

• 您可以通过设置服务器响应配置参数（如警报邮件中所述）为指定的服务器性能阈值设置警报。

• 请参见immonitor-access。

监视 stored

stored 可执行多种重要的任务，例如邮件数据库的死锁和处理操作、强制执行生存期策略以及擦除和删除磁盘上存储的邮件。如果 stored 停止运行，Messaging Server 终将出现问题。如果 start-msg 运行时 stored 未启动，则其他进程也不会启动。有关 stored 的更多信息，请参见《Sun Java System Messaging Server 6 2005Q4 Administration Reference》中的“stored”。

stored 问题的症状

没有外部症状。

监视 stored

• 检查 stored 进程是否在运行。stored 进程会在 msg_svr_base/config 中创建一个 pid 文件并对其更新，该文件的名称为 pidfile.store。该 pid 文件在恢复时显示 init 状态，在就绪时显示 ready 状态。例如：

  231: cat pidfile.store 28250 ready

  第一行中的数字是 stored 的进程 ID。

  232: ps -eaf | grep stored inetuser 28250 1 0 Jan 05 ? 8:44 /opt/SUNWmsgsr/lib/stored -d

• 检查在 msg_svr_base/store/mboxlist 中生成的日志文件。请注意，并非每个生成的日志文件都是直接由 stored 问题造成的。imapd 中断或数据库问题也会生成日志文件。

• 检查 msg_svr_base/config 中以下文件上的时间戳：

  stored.ckp—尝试进行检查点操作时改写该文件。应当每 1 分钟标记一次时间戳。 stored.lcu—每次清除数据库日志时改写该文件。应当每 5 分钟标记一次时间戳。 stored.per—每次按用户写出数据库时改写该文件。应当每 60 分钟标记一次时间戳

• 检查默认日志文件 msg_svr_base/log/default/default 中的 stored 邮件

• 可以使用 watcher 和 msprobe 进行监视。请参见失败的服务或未响应服务的自动重新启动和使用 msprobe 和 watcher 功能进行监视。

监视邮件存储

邮件存储在数据库中。用户在磁盘上的分布、用户邮箱大小以及磁盘要求都会影响存储性能。以下几个部分介绍了这些因素：

• 监视磁盘空间

• 监视邮件存储数据库锁定的状态

• 监视 mboxlist 目录中的数据库日志文件的数目

• 监视配额限制

监视邮件存储数据库锁定的状态

数据库锁定的状态由不同的服务器进程保留。这些数据库锁定可以影响邮件存储的性能。在死锁情况下，邮件将无法以正常的速度插入到存储中，最终将导致 ims-ms 通道队列增大。由于一些合理的理由，需要将队列备份；因此，为诊断问题而保留队列长度的历史记录是很有用的。

邮件存储数据库锁定问题的症状

事务数目不断积累且没有得到解决。

监视邮件存储数据库锁定

使用命令 counterutil -o db_lock

监视 mboxlist 目录中的数据库日志文件的数目

数据库日志文件是指 sleepycat 事务检查点操作日志文件 (msg_svr_base/store/mboxlist)。如果生成日志文件，则表明没有发生数据库检查点操作。stored 出现问题也会生成日志文件。

数据库日志文件问题的症状

应当有 2 个或 3 个日志文件。如果有更多的日志文件，则表明可能出现了潜在的严重问题。邮件存储使用了一些用于邮件和配额的数据库，这些数据库的问题会导致所有邮件服务器出现问题。

监视数据库日志文件

查看 msg_svr_base/store/mboxlist 目录，确保其中只有 2 个或 3 个文件。

用于监视的实用程序和工具

以下工具可用于进行监视：

• immonitor-access

• stored

• counterutil

• 日志文件

• imsimta 计数器

• imsimta qm counters

• 使用 SNMP 的 MTA 监视

• 用于邮箱配额检查的 imquotacheck

• 使用 msprobe 和 watcher 功能进行监视

immonitor-access

immonitor-access 监视以下 Messaging Server 组件/进程的状态：邮件传送（SMTP 服务器）、邮件访问和存储（POP 和 IMAP 服务器）、目录服务（LDAP 服务器）和 HTTP 服务器。此实用程序可测定各种服务的响应时间，以及发送和检索邮件所需的总的往返时间。目录服务是通过在目录中查找指定的用户并测定响应时间来监视的。邮件传送是通过发送邮件 (SMTP) 来监视的，而邮件访问和存储是通过检索邮件来监视的。对 HTTP 服务器的监视限于查看它是否已启动并正在运行。

有关完整的说明，请参见《Sun Java System Messaging Server 6 2005Q4 Administration Reference》中的“immonitor-access”。

stored

stored 实用程序执行服务器上的维护任务，也可以执行监视任务。但是，现在 msprobe 能更好地处理处理监视任务。请参见使用 msprobe 和 watcher 功能进行监视。

counterutil

此实用程序提供了从不同系统计数器获得的统计信息。下面是可用计数器对象的当前列表：

# /opt/SUNWmsgsr/sbin/counterutil -l
Listing registry (/opt/SUNWmsgsr/data/counter/counter)
numobjects = 11
refcount = 1
created = 25/Sep/2003:02:04:55 -0700
modified = 02/Oct/2003:22:48:55 -0700
     entry = alarm 
     entry = diskusage
     entry = serverresponse
     entry = db_lock 
     entry = db_log
     entry = db_mpool
     entry = db_txn
     entry = imapstat
     entry = httpstat
     entry = popstat
     entry = cgimsg

每个条目都表示一个计数器对象，并且为该对象提供了各种有用的计数。在本节中，我们将仅讨论 alarm、diskusage、serverresponse、db_lock、popstat、imapstat 和 httpstat 计数器对象。有关 counterutil 命令的用法的详细信息，请参见《Sun Java System Messaging Server 6 2005Q4 Administration Reference》中的“counterutil”。

counterutil 输出

counterutil 有多种标志。此实用程序的命令格式可能为：

counterutil -o CounterObject -i 5 -n 10

其中，

-o CounterObject 表示计数器对象 alarm、diskusage、serverresponse、db_lock、popstat、imapstat 和 httpstat。

-i 5 指定时间间隔为 5 秒。

-n 10 表示重复次数（默认值：无穷大）。

以下是 counterutil 的用法示例：

# counterutil -o imapstat -i 5 -n 10 
Monitor counteroobject (imapstat) 
registry /gotmail/iplanet/server5/msg-gotmail/counter/counter opened 
counterobject imapstat opened 

count = 1 at 972082466 rh = 0xc0990 oh = 0xc0968 

global.currentStartTime [4 bytes]: 17/Oct/2000:12:44:23 -0700 
global.lastConnectionTime [4 bytes]: 20/Oct/2000:15:53:37 -0700 
global.maxConnections [4 bytes]: 69 
global.numConnections [4 bytes]: 12480 
global.numCurrentConnections [4 bytes]: 48 
global.numFailedConnections [4 bytes]: 0 
global.numFailedLogins [4 bytes]: 15 
global.numGoodLogins [4 bytes]: 10446 
...

使用 counterutil 的警报统计信息

以下警报统计信息指的是由 stored 发送的警报。警报计数器可以提供以下统计信息：

使用 counterutil 的 IMAP、POP 和 HTTP 连接统计信息

要获取有关当前 IMAP、POP 和 HTTP 连接数、失败的登录次数、自开始时间以来的总连接数等的信息，可使用命令 counterutil -o CounterObject -i 5 -n 10。其中 CounterObject 代表计数器对象 popstat、imapstat 或 httpstat。imapstat 后缀的含义如表 23–2 中所示。popstat 和 httpstat 对象可以通过同样的格式和结构提供同样的信息。

使用 counterutil 的磁盘使用情况统计信息

命令counterutil -o diskusage 可以生成以下信息：

服务器响应统计信息

命令counterutil -o serverresponse 可以生成以下信息。这些信息可用于检查服务器是否正在运行以及它们的响应速度。

日志文件

Messaging Server 为 SMTP、IMAP、POP 和 HTTP 提供事件记录日志。可以自定义创建和管理 Messaging Server 日志文件的策略。

由于日志记录会影响服务器的性能，因此在向服务器添加这一负担之前应当对日志记录进行慎重考虑。有关更多信息，请参见第 21 章，管理日志记录。

imsimta 计数器

MTA 会为其每个活动通道积累邮件通信流量计数器（基于邮件监视 MIB，RFC 1566）。通道计数器旨在帮助表明电子邮件系统的趋势和运行状况。通道计数器并不用于提供精确的邮件通信流量计数。要获得精确的计数，请查看 MTA 日志记录，如第 21 章，管理日志记录中所述。

MTA 通道计数器是使用可用的最轻量级的机制实现的，以尽可能减小它们对实际操作的影响。通道计数器并不尝试成为强硬功能：如果尝试映射某部分失败，则不会记录任何信息；如果几乎无法立即获得该部分中的其中一个锁定，也不会记录任何信息；当关闭系统时，内存中的部分所包含的信息将永远丢失。

imsimta counters -show 命令可以提供 MTA 通道邮件统计信息（请参见下文）。在一段时间过后需要检查这些计数器并记下所看到的最小值。对于某些通道，最小值实际上可能为负数。负值意味着在某个通道的计数器归零时该通道中有排队的邮件（例如，创建了计数器的群集范围的数据库）。当这些邮件取消排队时，与该通道相关联的计数器便会减少，从而导致出现负的最小值。如果计数器出现这种情况，用当前值减去自计数器初始化以来曾经具有的最小值便可得到正确的“绝对”值。

Channel          Messages    Recipients    Blocks 
-------          --------    ----------    ------- 
tcp_local
   Received       29379       79714      982252                (1)
   Stored            61         113       -2004                (2)
   Delivered      29369       79723      983903 (29369 first time)  (3)
   Submitted      13698       13699       18261                (4)
   Attempted          0           0           0                (5)
   Rejected           1          10           0                (6)
   Failed           104         104        4681                (7)

   Queue time/count        16425/29440 = 0.56                  (8)
   Queue first time/count  16425/29440 = 0.56                  (9)

   Total In Assocs           297637
   Total Out Assocs           28306

1) Received 是加入到名为 tcp_local 的通道队列中的邮件数。即，由任何其他通道加入到 tcp_local 通道队列中的邮件（mail.log* 文件中的 E 记录）。

2) Stored 是存储在要被传送的通道队列中的邮件数。

3) Delivered 是已经由通道 tcp_local 处理（已取消排队）的邮件数。（即 mail.log* 文件中的 D 记录。）取消排队操作可能是由于传送成功（即，加入到另一个通道队列中），也可能是由于邮件被返回给发件人而进行的取消排队操作。通常此值等于 Received 值与 Stored 值之差。

MTA 还跟踪了首次尝试时被取消排队的邮件数，此数值显示在括号中。

4) Submitted 是由通道 tcp_local 加入到任何其他通道队列中的邮件数（mail.log 文件中的 E 记录）。

5) Attempted 是在排出队列过程中遇到临时问题的邮件数（即 mail.log* 文件中的 Q 记录或 Z 记录。

6) Rejected 是被拒绝的入队尝试次数（即 mail.log* 文件中的 J 记录）。

7) Failed 是失败的取消排队尝试次数（即 mail.log* 文件中的 R 记录）。

8) Queue time/count 是所传送的邮件在队列中花费的平均时间。这包括首次尝试时传送的邮件（请参见 [9]）以及需要进行额外传送尝试的邮件（因而通常会在队列中花费很长的闲置等待时间）。

9) Queue first time/count 是首次尝试即传送成功的邮件在队列中所花费的平均时间。

请注意，提交的邮件数可能会大于传送的邮件数。这是一个很常见的情况，因为通道取消排队（传送）的每封邮件都将导致至少一封新邮件加入队列（提交），但可能会多于一封。例如，如果一封邮件具有两个分别经由不同通道到达的收件人，则将需要进行两次加入队列操作。或者，如果邮件退回，则一个副本将返回给发件人，同时另一个副本可能会发送给邮寄主管。通常将有两次提交（除非两者通过同一个通道到达）。

更常见的情况是，Submitted 和 Delivered 之间的连接会根据通道的类型而不同。例如，在转换通道中，邮件将由其他任意通道加入队列，然后，转换通道将处理该邮件并将其加入到第三个通道中的队列，并在该邮件的自身队列中将其标记为已取消排队。每封单独的邮件都将获取一个路径：

elsewhere -> conversion E record Received
conversion -> elsewhere E record Submitted
conversion              D record Delivered

但是，对于 tcp_local 这样的通道（不是“直通式”通道，而是具有两个单独的部分 [从部分和主部分]），在 Submitted 和 Delivered 之间没有连接。Submitted 计数器必须使用 tcp_local 通道的 SMTP 服务器部分，而 Delivered 通道则必须使用 tcp_local 通道的 SMTP 客户机部分。它们是两个完全独立的程序，通过它们传送的邮件也可能是完全独立的。

提交给 SMTP 服务器的邮件：

tcp_local -> elsewhere E record Submitted

通过 SMTP 客户机发送给其他 SMTP 主机的邮件：

elsewhere -> tcp_local E record Received
tcp_local              D record Delivered

通道的取消排队（传送）操作将导致至少一封新邮件加入队列（提交），但可能会多于一封。例如，如果一封邮件具有两个分别经由不同通道到达的收件人，则将需要进行两次加入队列操作。或者，如果邮件退回，则一个副本将返回给发件人，同时另一个副本可能会发送给邮寄主管。通常将通过同一个通道到达。

在 UNIX 和 NT 上的实现

由于性能原因，运行 MTA 的节点将使用共享的内存部分（在 UNIX 上）或共享的文件映射对象（在 NT 上）在内存中保留通道计数器的高速缓存。当该节点上的进程将邮件加入队列或取消排队时，将更新此内存中的高速缓存中的计数器。如果通道运行时该内存中的部分不存在，则会自动创建该部分。（如果内存中的部分不存在，imta start 命令也会创建该部分。）

可以使用命令 imta counters -clear 或 imta qm 命令 counters clear 将计数器重置为零。

imsimta qm counters

imsimta qm counters 实用程序可显示 MTA 通道队列邮件计数器。只有 root 或 inetuser 用户才能运行该实用程序。程序的输出字段与imsimta 计数器中所述的字段相同。另请参见《Sun Java System Messaging Server 6 2005Q4 Administration Reference》中的“imsimta counters”。

示例：

# imsimta counters -create
# imsimta qm counters show
Channel                Messages   Recipients Blocks
---------------------- ---------- ---------- ----------
tcp_intranet
   Received              13077      13859     264616 
   Stored                   92         91       -362 
   Delivered             12985      13768     264978 
   Submitted              2594       2594       3641
...

每次重新启动 MTA 时，都必须运行：# imsimta counters -create

使用 SNMP 的 MTA 监视

Messaging Server 支持通过简单网络管理协议 (Simple Network Management Protocol, SNMP) 进行系统监视。使用 SNMP 客户机（有时称为网络管理器），例如 Sun Net Manager 或 HP OpenView（没有随此产品一起提供），可以监视 Messaging Server 的特定部分。有关详细信息，请参见附录 A，SNMP 支持。

用于邮箱配额检查的 imquotacheck

您可以使用 imquotacheck 实用程序监视邮箱配额使用情况和限制。imquotacheck 实用程序将生成列出定义的配额和限制的报告，并提供有关配额使用情况的信息。

例如，以下命令将列出所有用户配额信息：

% imquotacheck 
-------------------------------------------------------------------------
Domain red.siroe.com (diskquota = not set msgquota = not set) quota usage
-------------------------------------------------------------------------
diskquota         size(K)    %use    msgquota      msgs    %use    user
# of domains = 1
# of users = 705

no quota          50418             no quota      4392             ajonk
no quota              5             no quota      2                andrt
no quota         355518             no quota      2500             ansri
 ...

以下示例显示了用户 sorook 的配额使用情况：

% imquotacheck -u sorook
-------------------------------------------------------------------------
quota usage for user sorook
-------------------------------------------------------------------------
diskquota      size(K)    %use    msgquota      msgs     %use    user

no quota       1487               no quota      305              sorook

使用 msprobe 和 watcher 功能进行监视

Messaging Server 提供了 watcher 和 msprobe 两个进程来监视各种系统服务。watcher 监视服务器崩溃并根据需要重新启动服务器。msprobe 监视服务器挂起（不响应）。具体来讲，msprobe 可以监视以下内容：

• 服务器响应时间。msprobe 可以使用已启用服务器的协议命令连接至这些服务器并测定其响应时间。如果服务器响应时间超出报警阈值，系统将向服务器发送报警邮件（请参见警报邮件）；如果该响应时间超出指定的超时时长，将重新启动服务器。服务器响应时间同时记录到计数器数据库和默认日志文件中。可以使用 counterutil 来显示服务器响应时间的统计信息（counterutil）。

  以下服务器由 msprobe 监视：imap、pop、 http、cert、job_controller、smtp、lmtp、mmp 和 ens。smtp 或 lmtp 未响应时，系统将重新启动分发程序。ens 无法自动重新启动。

• 磁盘使用量. msprobe 检查每个邮件存储分区的磁盘可用性和使用量。具体来讲，它可以检查邮件存储 mboxlist 数据库目录和 MTA 队列目录。如果磁盘使用量超出了配置的阈值，则发送警报邮件。磁盘大小和使用量被同时记录到计数器数据库和默认日志文件中。管理员可以使用 counterutil 实用程序（请参见counterutil）显示磁盘使用量的统计信息。

• 邮件存储 mboxlist 数据库日志文件积累。日志文件积累是 mboxlist 数据库错误的迹象。msprobe 计算活动日志文件的数目，如果活动日志文件的数目大于阈值，msprobe 会将紧急错误消息记录到 default 日志文件中，以通知管理员重新启动服务器。如果启用了 autorestart（local.autorestart 为 yes），将重新启动存储守护进程。

watcher 和 msprobe 由 configutil 选项（如表 23–5 所示）控制。有关详细信息，请参见失败的服务或未响应服务的自动重新启动。

警报邮件

msprobe 可以通过电子邮件向邮寄主管发出报警（请参见监视 imapd、popd 和 httpd），针对指定的情况发出警告。下面显示了当超出特定阈值时发送的一个电子邮件警报样例：

Subject:    ALARM: server response time in seconds of “ldap_siroe.com_389” is 10
Date:    Tue, 17 Jul 2001 16:37:08 -0700 (PDT) 
From:    postmaster@siroe.com 
To:     postmaster@siroe.com 

Server instance: /opt/SUNWmsgsr
Alarmid: serverresponse 
Instance: ldap_siroe_europa.com_389 
Description: server response time in seconds 
Current measured value (17/Jul/2001:16:37:08 -0700): 10 
Lowest recorded value: 0 
Highest recorded value: 10 
Monitoring interval: 600 seconds 
Alarm condition is when over threshold of 10 
Number of times over threshold: 1

            

您可以指定 msprobe 监视磁盘和服务器性能的频率，以及在什么情况下发送警报。可以通过使用 configutil 命令设置报警参数完成此操作。表 23–6 显示了有用的报警参数及其默认设置。请参见《Sun Java System Messaging Server 6 2005Q4 Administration Reference》中的“configutil Parameters”。