上一页
目录
索引
下一页
|
上一页
目录
索引
下一页
|
|
| iPlanet Messaging Server 5.2 管理员指南 | |
第 15 篇 监控 iPlanet Messaging Server
在大多数情况下，规划且配置良好的服务器可以在不需要管理员过多干预下执行。然而，作为管理员仍有责任监控服务器以便发现问题征兆。本章描述 iPlanet Messaging Server 的监控，包括如下几部分：故障诊断程序，请见第 14 篇 “MTA 故障诊断”。
日常监控任务
日常执行的基础操作中最重要的包括检查 Postmaster 邮件、监控日志文件以及设置 stored 实用程序。这些任务在下文中描述。
检查 Postmaster 邮件
Messaging Server 有一个为 Postmaster 电子邮件设置的预定义的管理性邮件发送列表。任何此邮件发送列表中的用户将自动收到发送给 Postmaster 的邮件。Postmaster 邮件的规则在 RFC822 中定义，它要求每个邮件站点接受寄给名为 postmaster 的用户或邮件发送列表的每个邮件，并且发送到此地址的邮件被传递给一个真实的人。所有发送到 postmaster@host.domain 的邮件被发送到 Postmaster 帐户或邮件发送列表。
Postmaster 地址通常是用户发送关于其邮件服务的电子邮件的地址。作为 Postmaster，可能会收到来自本地用户的关于服务器响应时间的邮件，或来自其他服务器管理员的关于遇到无法发送邮件至你的服务器的问题等等。Postmaster 应当每日检查 Postmaster 邮件。
也可以配置服务器发送一些出错信息邮件到 Postmaster 地址。例如，当 MTA 不能够路由或传递一封邮件时，可以通过发送到 Postmaster 地址的邮件而得到通知。也可以给 Postmaster 发送例外情况警告（磁盘空间不足，服务器响应迟缓等）。
监控及维护日志文件
iPlanet Messaging Server 为每一种它所支持的主要协议或服务分别创建一组日志文件，即SMTP、IMAP、POP 和 HTTP。应当例行监控日志文件，特别是当服务器出现问题的时候。请注意日志记录能够影响服务器性能。日志记录越详细，在一给定时间段内日志文件会占用的磁盘空间就越多。应当为服务器定义有效且实际的日志轮换、期满检测及备份策略。关于为服务器定义日志记录策略的信息请参阅第 13 篇 “日志记录和日志分析”。
设置 stored 实用程序
stored 实用程序为服务器执行自动监控及维护任务，例如：stored 实用程序可自动于每天半夜执行清理和期满检测操作。有关详细信息，请参阅“stored”。
监控系统性能
本章关注于 iPlanet Messaging Server 的监控，然而，也需要监控服务器所驻留的系统。一个配置良好的服务器无法在缺乏性能调整的系统上很好地运行，一些服务器失败的表象可能表明硬件功能不足以服务于电子邮件负荷。本章不提供关于系统性能监控的所有细节，因为许多程序是针对特定平台的，可能需要参阅针对特定平台的系统文档。下面的程序描述性能监控：
监控端到端的邮件传递时间
监控端到端的邮件传递时间
电子邮件需要及时传递。这或许是服务协议所要求的，但尽可能快速地传递邮件也是一种好策略。缓慢的端到端时间可能说明许多问题。可能是服务器工作不正常，或者一天中的某段时间经历了过量的邮件负荷，或者现有的硬件资源在超负荷运转。
漫长的端到端传递时间的表象
邮件的传递花费比通常更多的时间。
监控端到端邮件传递时间
使用任何可以发送和接收邮件的工具。比较服务器转发间的报头时间以及原点和检索点间的时间。
监控磁盘空间
磁盘空间不足是导致邮件服务器出现问题及失败的最常见原因之一。如果没有空间写入 MTA 队列或邮件存储库，邮件服务器将运行失败。此外，除非日志文件被监控和清理，否则它们将不受控制地增长直至充满整个磁盘空间。当 stored 的清理功能失效时磁盘空间很快耗尽，被删除的邮件不会从邮件存储库中清除。其它耗尽磁盘空间的原因还有 MTA 邮件队列增长过大，邮件存储库超过可用磁盘空间，以及未受监控的日志文件不受控制地增长等。（请注意象 LDAP、MTA 以及 Message Access 这样的日志文件有许多，并且这些日志文件中的每一个都可存储在不同的磁盘中。）
磁盘空间问题表象
不同的耗尽空间的磁盘或分区，可能产生不同的表象。MTA 队列会溢出并拒绝 SMTP 连接，邮件会保留在 ims_master 队列而不被传递到邮件存储库，并且日志文件会溢出。
监控磁盘空间
可能需要依据系统配置监控各个磁盘和分区。例如，MTA 队列可能驻留在一个磁盘/分区，邮件存储库可能驻留在另一个，而日志文件可能驻留在另外的第三个。这些空间中的每一个都需要监控，并且这些空间的监控方法可能有所不同。
监控邮件存储库
建议邮件存储库的磁盘使用率不超过 75%。通过使用 configutil 实用程序配置下面的报警属性能够监控邮件存储库的磁盘使用：通过设置这些参数，能够指定系统监控磁盘空间的频度以及在系统应当在何种情况下发出警告。例如，若要系统每 600 秒监控一次磁盘空间，则指定用下面的命令：
configutil -o alarm.diskavail.msgalarmstatinterval -v 600
如果每当可用磁盘空间低于 20% 时都希望收到警告信息，则指定使用下面的命令：
configutil -o alarm.diskavail.msgalarmthreshold -v 20
请参照表 15-1 以获得关于这些参数的更多信息。
监控 MTA 队列和日志记录空间
需要监控 MTA 队列磁盘和日志记录空间磁盘的使用。
监控 CPU 的使用情况
CPU 的高负荷使用是一个信号，表明 CPU 没有足够的应对如此高的负荷的能力，或者表明某个进程正在耗费过多的 CPU 周期。
CPU 使用问题的表象
漫长的系统响应时间。缓慢的用户登录。缓慢的传递率。
监控 CPU 使用
监控 CPU 使用是平台相关的任务。请参阅相关平台文件。
监控邮件队列的大小
监控邮件队列的大小
邮件队列的过度增长可能表明邮件没有被传递，在传递中被耽搁，或者到达过快以至系统不能传递。这可能由许多原因造成的，例如由于系统邮件泛滥造成的服务拒绝器型攻击，或是作业控制器不运行。请参阅“通道的邮件队列”，“邮件未入队”和“MTA 邮件未传递”以获得更多关于邮件队列的信息。
监控邮件队列的大小
或许监控邮件队列的最好方法是使用 imsimta qm。请参阅“imsimta qm 计数器”。也能够监控队列目录 (/ServeRoot/msg-instance/imta/queue/) 中的文件数目。文件的数目是针对特定站点的，需要建立一基线历史记录以便发现多少才是“太多”。这可以通过在两周的周期内记录队列文件的大小以获得一大约均值来完成。
监控传递失败率
传递失败是指向外部站点传递邮件的一次失败尝试。传递失败率的大规模增长可能是一个信号，表明存在象无反应的 DNS 服务器或远程服务器对连接的响应超时等这样的网络问题。
传递失败频度表象
没有外在的表象。大量的 Q 记录将出现在 mail.log_current。
监控传递失败率
传递失败被记录在 MTA 日志，日志条目代码为 Q。
在文件 msg-instance/log/imta/mail.log_current 中可查看 Q 记录。
监控入站 SMTP 连接
来自一给定 IP 地址的入站 SMTP 连接数目的不寻常增长可能表明：
外部用户转发邮件：查看 msg-instance/log/imta/mail.log_current 中日志条目代码为 J（被拒绝的转发）的记录。要开始远程 IP 地址的日志记录请将以下行加入到文件 option.dat：
服务拒绝型攻击：要查明有多少用户和哪些用户正在连接 SMTP 服务器，可以运行命令 netstat 并且检查在 SMTP 端口（默认：25）的连接。例如：
- log_connection=1
- 请注意此功能的启用时会付有轻微的性能代价。
- 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 服务器长时间闲置，就应当进行检查。
监控 Dispatcher 和作业控制器进程
MTA 如要工作，Dispatcher 和作业控制器进程必须运转。且每一种应当有一个进程。
Dispatcher 和作业控制器故障的表象
如果 Dispatcher 发生故障或者资源不足，SMTP 连接既被拒绝。
监控 Dispatcher 和作业控制器进程
请检查名为 dispatcher 和 job_controller 的进程是否存在。请参阅“检查确认作业控制器和 dispatcher 的运行状态”。
监控 imapd、popd 和 httpd
监控 imapd、popd 和 httpd
这些进程提供对 IMAP、POP 和 Web 邮件业务服务的访问。如果其中之一没有运行或没有响应，服务将不能正常发挥其功能。如果服务正在运行但超载，监控将使得检测到这一情况并将其配置更合适一些。
imapd、popd 和 httpd 问题的表象
连接被拒绝或系统过慢以至于无法连接。例如，在 IMAP 未运行的情况下直接连接 IMAP，会看到类似这样信息：telnet 0 143
Trying 0.0.0.0...
telnet: Unable to connect to remote host: Connection refusednetscape 不能连接到指定位置的服务器。服务器故障或忙。
能用 SNMP 监控。
检查日志文件。
- 如果已设置了 SNMP，这是监控这些进程的非常好的方法。请参阅附录 A “SNMP 支持”。服务器信息在 Network Services Monitoring MIB 上。
请参阅“counterutil”和 iPlanet Messaging Server Reference Manual。
- 查看目录 msg-instance/log/service 其中 service 可以是 http 或 IMAP 或 POP。在那个目录可以找到许多日志文件。其中一个文件名是 服务（imap、pop、http）的名称，其它文件名是服务名后跟一序列号和一日期。例如：
- imap imap.29.1010221593 imap.31.1010394412 imap.33.1010567224
- 仅包含服务名的文件是最新的日志文件。其它文件按顺序号（此处为 29, 31, 33）排序，且最高序列号的文件是次新的文件。（参阅第 13 篇 “日志记录和日志分析”。）
- 如果服务器关闭会看到象下面这样的信息：
- 可用 counterutil 检查[05/Jan/2002:08:36:38 -0800] gotmail-a imapd[10275]: General Warning: iPlanet Messaging Server IMAP4 5.2 (built Dec 9 2001) shutting down
运行针对特定平台的命令，以证实 imapd、popd 和 httpd 等进程正在运行。例如，在 Solaris 上可以使用命令 ps 寻找 imapd, popd 和 mshttpd。在 Windows NT 上，既可以使用任务管理器窗口也可以使用命令行。
可以通过设置服务器响应配置参数（在“建议使用的 stored 参数”中有描述）为指定的服务器性能阈值设置报警。
监控 stored
stored 执行多种重要任务，例如邮件数据库的死锁和事务操作，执行时限政策以及清除存储在磁盘上的邮件。如果 stored 停止运行，messaging server 将最终产生问题。如果当 start-msg 运行时 stored 未启动，其它进程也不会启动。有关 stored 命令的详细说明，请参阅 iPlanet Messaging Server Reference Manual。
请检查确认 stored 进程是正在运行。stored 在 msg-instance/config 中创建并更新一名为 pidfile.store 的 pid 文件。此 pid 文件在恢复时显示一 init 状态，当就绪时显示一 ready 状态。例如：
请检查在 msg-instance/store/mailboxlist 中建立的日志文件。请注意并不是每个日志文件的建立都是由直接的 stored 问题造成的。在 imapd 死掉或有数据库问题时也可能建立日志文件。
- 231: cat pidfile.store
28250
ready
- 第一行中的数字是 stored 的进程 ID。
- 232: ps -eaf | grep stored
mailsrv 28250 1 0 Jan 05 ? 8:44 /usr/iplanet/server5/bin/msg/admin/bin/stored -d
请检查 msg-instance/config 中下列文件上的时间截：
请检查在默认日志记录文件中储存的邮件，即 msg-instance/log/default/default
- stored.ckp - 当尝试检查点操作时被触及（touched）。应当每隔 1 分钟打一次时间戳。
stored.lcu - 在每个 db 日志清理时被触及（touched）。应当每隔 5 分钟打一次时间戳。
stored.per - 每当诞生一个逐用户 db 写出时被触及（touched）。应每隔 60 分钟打一次时间戳。
监控 LDAP Directory Server
本部分包括如下内容：
监控 slapd
监控 slapd
LDAP 目录服务器（slapd）为邮件系统提供目录信息。如果 slapd 出现故障，系统将不能正常工作。如果 slapd 响应过于迟缓，将影响到登录速度以及任何其它请求 LDAP 查找的事务。
监控邮件存储库
邮件被存储在一个数据库中。磁盘上的用户分布、其邮箱的大小以及磁盘空间要求都影响着存储性能。本部分包括如下内容：
监控邮件存储数据库锁定状态
监控邮件存储数据库锁定状态
数据库锁定状态被不同的服务器进程保持着。这些数据库锁定能够影响邮件存储库的性能。在死锁的情况下，邮件不会在合理的速度下被插入到邮件存储库，并且 ims-ms 通道队列也会因此而增长得更大。有合理的理由为对队列备份，因此拥有队列长度的历史记录对于问题的诊断是十分有用的。
邮件存储数据库锁定问题的表象
积累且得不到解决的事务的数目。
监控邮件存储数据库锁定
使用命令 counterutil -o db_lock
监控在 mboxutil 目录中的数据库日志文件的数目
数据库日志文件参照困猫（sleepycat）事物检查点日志文件（msg-instance/store/mboxlist）。日志文件的建立是未发生数据库检查点操作的表象。日志文件的建立也有可能源于 stored 问题。
数据库日志文件问题的表象
应当有 2个 或 3 个日志文件。如果有更多的日志文件，则是潜在的严重问题的信号。邮件存储库为邮件和空间配额使用几个数据库，它们出现问题会导致所有邮件服务器出现问题。
监控数据库日志文件
查看 msg-instance/store/mboxlist 目录并确认只有 2 个 或 3 个 文件。
stored
stored 实用程序在服务器上执行维护任务，但它也能用于监控。它能够周期性检查服务器状态、磁盘空间及服务响应时间，并且如果指定，它还能以邮件的形式发布报警给 Postmaster（请参阅 第 1 页）。来自 stored 的报警以电子邮件的形式发送给 Postmaster 以警告某种指定情况。以下是一个当某个阈值被超越时 stored 发送的电子邮件报警的例子：
主题：报警：“ldap_siroe.com_389”服务器响应时间为 10 秒
日期：Tue, 17 Jul 2001 16:37:08 - 0700 (PDT)
发件人：postmaster@siroe.com
收件人：postmaster@siroe.com服务器实例：/usr/iplanet/server5/msg-europa
报警 ID:serverresponse
实例：ldap_siroe_europa.com_389
说明服务器响应时间以秒计算
当前测量值 (17/Jul/2001:16:37:08 - 0700) ：10
最低记录值：0
最高记录值：10
监控间隔：600 秒
报警条件为当超过阈值 10
超过阈值的次数：1可以指定 stored 监控磁盘和服务器性能的频度以及在何种情况下发送报警。这通过使用 configutil 命令设置报警参数来完成。表 15-1 列出了有用的 stored 参数及其默认设置。
counterutil
此实用程序从不同的系统计数器获取统计信息。下面是一个可用计数器对象的当前列表：counterutil -l
entry = alarm
entry = diskusage
entry = serverresponse
entry = db_lock
entry = db_log
entry = db_mpool
entry = db_txn
entry = popstat
entry = imapstat
entry = httpstat
entry = cgimsg每一条目代表一计数器对象并提供针对此对象的多种有用的计数。在本部分中将仅讨论 alarm、diskusage、serverresponse、db_lock、popstat、imapstat 和 httpstat 这些计数器对象。counterutil 命令的使用细节请参阅 iPlanet Messaging Server Reference Manual。
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 -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 后缀的意思如表 15-3 中所示。对象 popstat 和 httpstat 以相同的格式和结构提供相同信息。
表 15-3 counterutil imapstat 统计
后缀
说明
使用 counterutil 进行磁盘使用的统计
命令：counterutil -o diskusage 产生如下信息：
表 15-4 counterutil diskstat 统计
后缀
说明
服务器响应统计数据
命令：counterutil -o serverresponse 产生如下信息。此信息对于检查服务器是否正在运行以及其响应的迅速程度是有用的。
表 15-5 counterutil serverresponse 统计
后缀
说明
日志文件
对 SMTP、IMAP、POP 和 HTTP 记录的 Messaging server 日志事件。用户可自定义建立和管理 Messaging Server 日志文件的策略。由于日志记录会影响服务器性能，在服务器承担此任务前应当仔细斟酌。有关详情，请参阅第 13 篇 “日志记录和日志分析”。
imsimta 计数器
MTA 依据 Mail Monitoring MIB、RFC 1566 对每个活动通道的邮件流通量进行累计。通道计数器意在帮助指出电子邮件系统的运行态势和状况。通道计数器并不是为准确计算邮件流通量而设计的。有关精确计数，可另行参阅第 13 篇 “日志记录和日志分析”中对 MTA 日志的讨论。MTA 通道计数器使用最精简的机制实现，以使它在实际操作中产生尽可能小的影响。通道计数器不会过度地尝试：如果映射存储块的尝试失败，则不会记录任何信息；如果几乎无法立即得到存储块中的一个锁，则不会记录任何信息；当系统关闭时，驻留内存的存储块将永久丢失。
imsimta counters -show 命令提供 MTA 通道邮件统计数据（见下）。这些计数器需要随时检查以发现最小值。对于某些通道，这个最小值竟可能是负数。一个负数最小值意味着在通道计数器被置零时（例如，计数器的群集数据库被创建），有邮件排队进入该通道。当这些邮件出队时，通道的相关计数器进行减值从而导致一个负数最小值。对于此种计数器，正确的“绝对”值是当前值减去计数器初始化以来的最小值。
1) Received（已接收）是入队至名为 tcp_local 的通道的邮件数目。也就是说，通过任何其它通道入队至通道 tcp_local 的邮件（在文件 mail.log* 中的 E 记录）。
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（首次入队时间/记数）是首次尝试即被传递的邮件滞留队列的平均时间。
请注意提交的邮件数可以比传递的邮件数大。这种情况经常发生，因为通道出队（传递）的每封邮件将导致至少一封但可能多于一封新邮件入队（被提交）。例如，如果一封邮件有两个通达不同通道的接收人，那么将需要两次入队。或者如果已邮件退回，它的一个副本会退回到发件人处，另一副本会发送给 Postmaster。通常这将是两次提交（除非两者通达同一通道）。
更一般地说，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 客户程序部分有关。它们是两种完全不同的程序，通过它们的邮件穿越也可能完全不同。
tcp_local -> elsewhere E record Submitted
elsewhere -> tcp_local E record Received
tcp_local D record Delivered通道出队（传递）将导致至少一封但可能多于一封新邮件入队（提交）。例如，如果一封邮件有两个通达不同通道的接收人，那么将需要两次入队。或者如果邮件退回，它的一个副本会退到发件人处，另一副本会发送给 Postmaster。通常通过同一通道到达。
在 UNIX 和 NT 上实现
由于性能原因，一个运行 MTA 的结点在内存中保留一个通道计数器缓存，这个缓存使用共享存储块（UNIX）或共享文件映像对象（NT）。在这个结点上的进程入队和出队邮件时，会修改这个驻留内存的计数器。如果当通道运行时驻留存储块不存在，地将会自动被创建。（imta start 命令也创建驻留存储块，如果它不存在的话。）命令 imta counters -clear 或 imta qm 命令 counters clear 可用于将计数器重置为 0。
imsimta qm 计数器
imsimta qm counters 实用程序显示 MTA 通道队列邮件计数器。必须在根目录或 mailsrv 处运行这个实用程序。输出字段与“imsimta 计数器”中描述的内容一样。有关使用细节，还可参阅 iPlanet Messaging Server Reference Manual。Channel Messages Recipients Blocks
---------------------- ---------- ---------- ----------
autoreply
Received 13077 13859 264616
Stored 92 91 -362
Delivered 12985 13768 264978
Submitted 2594 2594 3641
...
使用 SNMP 进行 MTA 监控
iPlanet Messaging Server 通过简单网络管理协议 (SNMP) 支持系统监控。使用 SNMP 客户机（有时称为 网络管理器），如 Sun Net Manager 或 HP OpenView（不随本产品提供），可监控 iPlanet Messaging Server 的特定部分。有关细节请参阅附录 A “SNMP 支持”。
用于邮箱配额检查的 mboxutil
您可通过 mboxutil 实用程序监控空间配额的使用和限制情况。mboxutil 实用程序可生成一份报告，列示任何已定义的空间配额和限制情况，并提供空间配额使用量方面的信息。报告中的空间配额及其使用量以千字节为单位。例如，下面的命令列示所有用户的空间配额信息：
下面的例子显示了用户 sorook 的配额使用情况：
上一页 目录 索引 下一页
(c) 2002 年 Sun Microsystems, Inc. 版权所有。
更新日期：2002 年 2 月 27 日