Sun Java System Messaging Server 6 2005Q1 管理指南 |
第 23 章
监视 Messaging Server在大多数情况下,一个经过很好计划和很好配置的服务器在执行时不需要管理员的过多介入。但是,作为管理员,监视服务器的问题信号是您的工作。本章介绍 Messaging 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 监视,但是还需要监视服务器所在的系统。很好配置的服务器在未经过很好优化的系统上无法获得很好的性能,服务器的故障症状可能表明硬件不足以支持电子邮件负载。本章未提供有关监视系统性能的所有详细信息,因为其中的许多过程都是特定于平台的,并且可能要求您参考特定于平台的系统文档。下面介绍了性能监视的过程:
监视端对端邮件传送时间
电子邮件需要按时传送。这可能是一项服务协议要求,但尽快传送邮件也是一个很好的策略。较长的端对端时间可能预示着许多问题。可能是服务器运行不正常,或者是在一天中的特定时间内发生了邮件超负荷的情况,或者是对现有硬件资源的使用已经超出了它们的能力。
低效的端对端邮件传送时间的症状
邮件的传送时间比正常情况下要长。
监视端对端邮件传送时间
- 使用任何发送和接收邮件的工具。比较服务器中继器之间的标题时间以及起始点和检索点之间的时间。请参见 immonitor-access。
监视磁盘空间
磁盘空间不足是导致邮件服务器出现问题和故障的最常见原因之一。如果没有用于写入到 MTA 队列或写入到邮件存储的空间,邮件服务器将会失败。此外,除非监视并清除日志文件,否则它们会无节制地增长并填满所有磁盘空间。
邮件存储分区将随着新邮件传送到邮箱而增长;例如,如果不强制邮件存储配额,邮件存储可能会超出分区的可用磁盘空间。导致磁盘空间耗尽的另一个原因是 MTA 邮件队列增长得过大。涉及的第三个方面为问题是否因日志文件监视工具和日志文件增长失控而发生。(请注意,有许多日志文件,例如 LDAP、MTA 和邮件访问,其中的每个日志文件都可以存储在不同的磁盘上。)
磁盘空间问题的症状
根据耗尽空间的磁盘或分区不同,所出现的症状会有所不同。MTA 队列会溢出并拒绝 SMTP 连接,邮件可能保留在 ims_master 队列中而没有传送到邮件存储,并且日志文件会溢出。
如果邮件存储分区填满,则邮件访问守护进程可能会失败,邮件存储数据可能会被破坏。邮件存储维护实用程序(例如 imexpire 和 reconstruct)可以修复损坏并减少磁盘空间的使用。但是,这些实用程序需要其他磁盘空间,而且修复填满整个磁盘的分区可能会导致停机时间。
监视磁盘空间
根据系统配置,您可能需要监视各种磁盘和分区。例如,MTA 队列、邮件存储和日志文件可能分别位于不同的磁盘/分区上。其中的每个空间都需要监视,并且监视这些空间的方法也可能不同。
Messaging Server 提供特定的方法,以监视邮件存储磁盘空间的使用并防止分区填满所有可用磁盘空间。
您可以执行以下步骤来监视邮件存储磁盘空间的使用情况:
有关详细信息,请参见以下内容:监视邮件存储和监视邮件存储分区。
监视邮件存储
建议邮件存储的磁盘用量不要超过磁盘容量的 75%。您可以通过配置以下警报属性(使用 configutil 实用程序)来监视邮件存储的磁盘用量:
通过设置这些参数,您可以指定系统应监视磁盘空间的频率以及系统应在什么情况下发送警告。例如,如果您希望系统每 600 秒监视磁盘空间一次,请指定以下命令:
configutil -o alarm.diskavail.msgalarmstatinterval -v 600
如果您希望无论何时当可用磁盘空间低于 20% 时都接收到警告,请指定以下命令:
configutil -o alarm.diskavail.msgalarmthreshold -v 20
有关这些参数的详细信息,请参见表 23-6。
监视邮件存储分区
当邮件分区填充超过可用磁盘空间的指定百分比时,您可以停止向邮件存储分区传送邮件。设置两个 configutil 参数以启用此功能并指定磁盘使用量阈值即可完成此设置。
邮件存储守护进程可以使用此功能来监视分区磁盘使用量。随着磁盘使用量的增加,存储守护进程将更加频繁地动态检查分区(从每 100 分钟一次到每 1 分钟一次)。
如果磁盘使用量超过指定的阈值,存储守护进程将:
磁盘使用量降至阈值以下时,分区将取消锁定,邮件将再次传送到存储。
configutil 参数如下:
应将磁盘使用量阈值设置为一个足够低的百分比,以便有时间重新进行分区或为本地邮件存储指定更多的磁盘空间。
例如,假设分区以每小时 2% 的速率填充磁盘空间,并且需要一个小时的时间为本地邮件存储分配其他磁盘空间。在这种情况下,应将磁盘使用量阈值设置为低于 98% 的值。
监视 MTA 队列和日志记录空间
您需要监视 MTA 队列和日志记录空间的磁盘用量。
有关管理日志空间的信息,请参见第 21 章“管理日志记录”。 例如,要了解如何监视 mail.log 文件,请参见管理 MTA 邮件和连接日志。
监视 CPU 的使用率
高 CPU 使用率表明针对该使用级别没有足够的 CPU 容量,或者某些进程使用的 CPU 循环超出了正常范围。
CPU 使用问题的症状
系统响应时间长。用户的登录缓慢。传送率低。
监视 CPU 使用率
监视 CPU 使用率是一个特定于平台的任务。请参考相关的平台文档。
监视 MTA本节包含以下小节:
监视邮件队列的大小
邮件队列的过度增长可能表明邮件没有被传送出去,或者传送被延迟,或者传入的速度比系统所能传送它们的速度要快。这可能是由多种原因造成的,例如由系统中泛滥的大量邮件导致拒绝服务攻击,或者作业控制器未运行。
有关邮件队列的更多信息,请参见通道邮件队列、邮件未被排出队列和未传送 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 连接的适当数目及其状态(ESTABLISHED、CLOSE_WAIT 等),以便确定某个特定的读取是否超出了正常范围。
如果发现许多连接处于 SYN_RECEIVED 状态,则这可能是由断开的网络或拒绝服务攻击造成的。此外,SMTP 服务器进程的生存期是有限的。这是由 dispatcher.cnf 文件中的 MTA 配置变量 MAX_LIFE_TIME 控制的。默认值为 86,400 秒(一天)。类似地,MAX_LIFE_CONNS 指定了服务器进程在其生存期内所能处理的最大连接数。如果发现某个特定的 SMTP 服务器已经运行了很长时间,则可能需要进行调查。
监视分发程序和作业控制器进程
分发程序和作业控制器进程必须运行,MTA 才能工作。您应当具有每一种进程。
分发程序和作业控制器进程故障的症状
如果分发程序出现故障或没有足够的资源,则 SMTP 连接将被拒绝。
如果作业控制器出现故障,则队列的大小将增加。
监视分发程序和作业控制器进程
检查以确定存在名为 dispatcher 和 job_controller 的进程。请参见检查作业控制器和分发程序是否正在运行。
监视 LDAP 目录服务器本节包含以下小节:
监视 slapd
LDAP 目录服务器 (slapd) 为邮件传送系统提供了目录信息。如果 slapd 出现故障,系统将无法正常工作。如果 slapd 响应时间太长,则会影响登录速度以及任何需要 LDAP 查找的其他事务。
slapd 问题的症状
监视 slapd
- 检查 ns-slapd 进程是否在运行。
- 检查 slapd-instance/logs/ 中的 slapd 日志文件 access 和 errors
- 检查搜索用户时 ns-slapd 的响应时间。
- 查看 Console 来监视 slapd。
- 请参见 immonitor-access。
监视邮件访问本节包含以下小节:
监视 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 Administration Reference。
- 运行特定于平台的命令来验证 imapd、popd 和 httpd 进程是否正在运行。例如,在 Solaris 中,您可以使用 ps 命令并查找 imapd、popd 和 mshttpd。
- 您可以通过设置服务器响应配置参数(如警报邮件中所述)为指定的服务器性能阈值设置警报。
- 请参见 immonitor-access。
监视 stored
stored 可执行各种重要的任务,例如邮件数据库的死锁和事务操作、强制执行生存期策略以及擦除和删除磁盘上存储的邮件。如果 stored 停止运行,则邮件传送服务器最终将出现问题。如果 start-msg 运行时 stored 未启动,则其他进程也不会启动。有关 stored 的详细信息,请参见 Sun Java System Messaging Server Administration Reference。
stored 问题的症状
没有外部症状。
监视 stored
- 在默认日志文件 msg_svr_base/log/default/default 中检查 stored 邮件
- 可以使用 watcher 和 msprobe 进行监视。请参见失败的服务或未响应服务的自动重新启动和使用 msprobe 和 watcher 功能进行监视
监视邮件存储邮件存储在数据库中。用户在磁盘上的分布、用户邮箱大小以及磁盘要求都会影响存储性能。以下几个部分介绍了这些因素:
监视邮件存储数据库锁定的状态
数据库锁定的状态由不同的服务器进程保留。这些数据库锁定可以影响邮件存储的性能。在死锁情况下,邮件将无法以合理的速度插入到存储中,并且最终会使 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
immonitor-access 可监视以下 Messaging Server 组件/进程的状态:邮件传送(SMTP 服务器)、邮件访问和存储(POP 和 IMAP 服务器)、目录服务(LDAP 服务器)和 HTTP 服务器。此实用程序可测定各种服务的响应时间以及发送和检索邮件所需的总的往返时间。目录服务是通过在目录中查找指定的用户并测定响应时间来监视的。邮件传送是通过发送邮件 (SMTP) 来监视的,而邮件访问和存储是通过检索邮件来监视的。对 HTTP 服务器的监视限于查看它是否已启动并正在运行。
有关完整的说明,请参见 Sun Java System Messaging Server Administration Reference。
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 Administration Reference。
counterutil 输出
counterutil 具有各种标志。此实用程序的命令格式可能为:
以下是 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。表 23-2 中显示了 imapstat 后缀的含义。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 通道邮件统计数据(请参见下面的内容)。在一段时间过后需要检查这些计数器并记下所看到的最小值。对于某些通道,最小值实际上可能为负数。负值意味着在某个通道的计数器归零时该通道中有排队的邮件(例如,创建了计数器的群集范围的数据库)。当这些邮件取消排队时,将从该通道所关联的计数器中减去邮件数量,从而导致出现了负的最小值。对于这样的计数器,正确的“绝对”值是当前值减去计数器自初始化以来曾经具有的最小值。
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 通道队列邮件计数器。您必须是超级用户或 inetuser 用户才能运行此实用程序。输出字段与 imsimta 计数器中所述的字段相同。有关用法的详细信息,请参见 Sun Java System Messaging Server Administration Reference。
示例:
# imsimta counters -create
# imsimta qm counters showChannel 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 支持通过简单网络管理协议 (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 ajonkish
no quota 5 no quota 2 andrewt
no quota 355518 no quota 2500 aniksri
...
以下示例显示了用户 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 将使用其协议命令连接到已启用的服务器并测定这些服务器的响应时间。如果响应时间超出警报阈值,系统将发送警报邮件(请参见警报邮件)。如果启用了自动重新启动,当 msprobe 无法连接到服务器或服务器响应时间超出指定的超时值时,则将重新启动服务器。服务器响应时间被同时记录到计数器数据库和默认日志文件中。counterutil 可用于显示服务器响应时间统计信息(counterutil)。
- 磁盘使用量。msprobe 将检查每个邮件存储分区的磁盘可用性和使用量。特别是,它将检查邮件存储 mboxlist 数据库目录和 MTA 队列目录。如果磁盘使用量超出了配置的阈值,则发送警报邮件。磁盘大小和使用量被同时记录到计数器数据库和默认日志文件中。管理员可以使用 counterutil 实用程序(请参见 counterutil)来显示磁盘使用量统计信息。
- 邮件存储 mboxlist 数据库日志文件积累。日志文件积累表明了 mboxlist 数据库错误。msprobe 计算了活动日志文件的数目,如果活动日志文件的数目大于阈值,msprobe 会将紧急错误消息记录到 default 日志文件中通知管理员重新启动服务器。如果启用了 autorestart(local.autorestart 为 yes),将重新启动存储守护进程。
watcher 和 msprobe 是由 configutil 选项(如表 23-5 所示)控制的。可以在失败的服务或未响应服务的自动重新启动找到详细信息
表 23-5 msprobe 和 watcher configutil 选项
选项
说明
local.watcher.enable
启用 watcher,用于监视服务失败。IMAP、POP、HTTP、作业控制器、分发程序、邮件存储 (stored)、imsched 和 MMP。(LMTP/SMTP 服务器由分发程序监视,LMTP/SMTP 客户机由 job_controller 监视。)对于特定失败,会将错误消息记录到默认日志文件中。默认值:启用
local.autorestart
启用服务器自动重新启动。自动重新启动失败或挂起服务。默认值:否
local.autorestart.timeout
失败重试超时。如果服务器在此指定时间内失败超过两次,则系统将停止尝试重新启动服务器。应当将该值(以秒为单位设置)设置为比 msprobe 间隔 (local.schedule.msprobe) 长的时间段值。默认值:600 秒
local.schedule.msprobe
msprobe 运行时间安排。crontab 式样的时间安排字符串(请参见表 18-10)。默认值为 600 秒。
service.readtimeout
重新启动之前的默认服务器超时。
默认值:(smtp/lmtp 为 120 秒,其他协议为 30 秒)
local.probe.service.timeout
重新启动之前的特定服务器超时。service 可以是 imap、pop、http、cert、job_controller、smtp、lmtp、mmp 或 ens。
默认值:使用 service.readtimeout
local.probe.warningthreshold
警告邮件被记录到 default 日志文件之前的服务器非响应秒数。
默认值:5 秒
local.probe.service.warningthreshold
警告邮件被记录到 default 日志文件之前的特定服务器非响应秒数。service 可以是 imap、pop、http、cert、job_controller、smtp、lmtp、mmp 或 ens。
默认值:使用 local.probe.warningthreshold
local.queuedir
当队列大小超过由 alarm.diskavail.msgalarmthreshold 定义的阈值时,要检查的 MTA 队列目录。
默认值:无
local.schedule.msprobe
msprobe 运行时间安排。值为 crontab 样式的时间安排字符串。
默认值:600 秒
service.readtimeout
重新启动该服务器之前的服务器非响应时段。请参见 local.schedule.msprobe。
默认值:10 秒
警报邮件
msprobe 可以向邮寄主管发出电子邮件形式的警报(请参见
(更多信息...) ),针对指定的情况发出警告。下面显示了当超出特定阈值时发送的一个电子邮件警报样例:
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 Administration Reference。
表 23-6 有用的警报邮件 configutil 参数
参数
说明(括号中为默认设置)
alarm.msgalarmnoticehost
(localhost) 向其发送警告邮件的计算机。
alarm.msgalarmnoticeport
(25) 发送警报邮件时要连接的 SMTP 端口。
alarm.msgalarmnoticercpt
(Postmaster@localhost) 向其发送警报通知的用户。
alarm.msgalarmnoticesender
(Postmaster@localhost) 警报发件人的地址。
alarm.diskavail.msgalarmdescription
(可用邮件分区磁盘空间的百分比。)磁盘可用性警报的说明字段的文本。
alarm.diskavail.msgalarmstatinterval
(3600) 磁盘可用性检查之间的时间间隔(秒)。设置为 0 将禁用磁盘使用情况的检查。
alarm.diskavail.msgalarmthreshold
(10) 当磁盘空间的可用性低于此百分比时将发送警报。
alarm.diskavail.msgalarmthresholddirection
(-1) 指定当磁盘空间的可用性低于阈值 (-1) 或高于阈值 (1) 时是否发出警报。
alarm.diskavail.msgalarmwarninginterval
(24) 后续重复的磁盘可用性警报之间的时间间隔(小时)。
alarm.serverresponse.msgalarmdescription
(以秒为单位的服务器响应时间。)服务器响应警报的说明字段的文本。
alarm.serverresponse.msgalarmstatinterval
(600) 服务器响应检查之间的时间间隔(秒)。设置为 0 将禁用服务器响应的检查。
alarm.serverresponse.msgalarmthreshold
(10) 如果服务器响应时间超过此值(秒),则发出警报。
alarm.serverresponse.msgalarmthresholddirection
(1) 指定当服务器响应时间大于 (1) 或小于 (-1) 阈值时是否发出警报。
alarm.serverresponse.msgalarmwarninginterval
(24) 后续重复的服务器响应警报之间的时间间隔(小时)。