上一页    目录    索引    下一页
iPlanet Messaging Server 5.2 管理员指南

附录 A SNMP 支持


iPlanet Messaging Server 通过简单网络管理协议（SNMP）支持系统监控。使用 SNMP 客户机（有时称作网络管理器），比如 Sun Net Manager 或 HP OpenView（不随此产品提供），可以监控 iPlanet Messaging Server 的特定部分。有关监控 iPlanet Messaging Server 方面的详细说明，请参见第 15 篇 “监控 iPlanet Messaging Server”。

本章介绍如何启用 Messaging Server 的 SNMP 支持功能。同时还概要介绍 SNMP 所提供的信息种类。注意，本章不描述如何从 SNMP 客户机处查看这些信息。有关如何用 SNMP 查看基于 SNMP 的详细信息，请参阅 SNMP 客户机文档。本文档还介绍来自 Messaging Server SNMP 实现的某些可用数据，但对于 MIB 的完整细节还请参阅：RFC 2788 和 RFC 2789。

本章包括以下几部分：

• SNMP 实现

• 为 iPlanet Messaging Server 配置 Solaris 8 的 SNMP 支持

• 为 Windows 平台配置 SNMP 支持

• 来自 SNMP 客户机的监控

• 在 Unix 平台上与其它 iPlanet 产品共存

• SNMP 信息来自 Messaging Server

SNMP 实现

---

iPlanet Messaging Server 实现两个标准化的 MIB，网络服务监控程序 MIB（RFC 2788）和邮件监控程序 MIB（RFC 2789）。网络服务监控程序 MIB 是提供来监控如 POP、IMAP、HTTP 和 SMTP 等服务器这样的网络服务的。邮件监控程序 MIB 是提供来监控 MTA 的。邮件监控 MIB 用于监控每个 MTA 通道的状态，包括活动的和历史的状态。活动信息关注当前已入队邮件和打开网络连接（如已入队邮件计数，打开网络连接的源 IP 地址等），而历史信息则提供汇总数据（如已处理邮件总数和入站连接总数等）。

---

备注：	有关 Messaging Server 的 SNMP 监控信息的完整列表，请参阅 RFC 2788 和 RFC 2789。

---

只有 Solaris 8 平台 支持 SNMP。今后的版本会得到其它平台的支持。Solaris 上的 SNMP 支持利用了固有的 Solaris SNMP 技术 Solstice Enterprise Agents（SEA）。客户不须在 Solaris 8 系统上安装 SEA：必要的运行库已经存在。

对 Messaging Server SNMP 支持的限制如下：

• 每台主机计算机上只有一个 Messaging Server 实例可以通过 SNMP 进行监控。

• SNMP 支持只用于监控。不支持任何 SNMP 管理。

• 没有实现 SNMP 陷阱。（RFC 2788 提供了相似的功能，但不使用陷阱）。

Messaging Server 中的 SNMP 操作

在 Solaris 平台上，Messaging Server SNMP 进程是一个 SNMP 子代理，一开始就将其自身注册到平台固有的 SNMP 主代理处。来自客户机的 SNMP 请求被传达给主代理。主代理会把任何针对 Messaging Server 的请求转发给 Messaging Server 子代理进程。Messaging Server 子代理进程则处理这些请求，并通过把主代理把响应返回给客户机。具体过程，请参阅：图 A-1。

图 A-1 SNMP 信息流

为 iPlanet Messaging Server 配置 Solaris 8 的 SNMP 支持

---

虽然 SNMP 监控程序的开销非常小，但提供的 Messaging Server 一开始仍然禁用 SNMP 支持。要启用 SNMP 支持，执行下列命令：

# su user-id-for-ims
# configutil -o local.snmp.enable -v 1
# start-msg snmp

一旦启用了 SNMP，则 start-msg 命令，不须指定任何参数，即可使 SNMP 子代理进程和与其它 Messaging Server 进程一起自动启动。

注意，Solaris 自带的 SNMP 主代理必须运行，Messaging Server SNMP 子代理才能操作。Solaris 自带的 SNMP 主代理是 snmpdx 守护程序，此程序通常作为 Sloaris 的启动进程的一部分运行。

SNMP 子代理会自动选择一个需监听的 UDP 端口。如需要，可以向子代理指定固定的 UDP 端口，命令是：

# configutil -o local.snmp.port -v port-number

以后可以通过给端口号值指定为零来撤消这一设置。零值，即默认设置，告诉 Messaging Server 允许子代理自动选择任意可用的 UDP 端口。

有两个 SNMP 子代理设置文件放置在 /etc/snmp/conf 目录中：ims.acl，含有 SNMP 访问控制信息，和 ims.reg，含有 SNMP MIB OID 注册信息。

通常没有任何理由编辑这两个文件中的任何一个。受 Messaging Server 支持的 MIB 是只读的，而且不需要在 ims.reg 文件指定端口号。如果指定了端口号，MIB 就会满足，除非也用 configutil 实用程序设置了端口号。在那种情况下，用 configutil 设置的端口号是子代理将要使用的端口号。如果编辑了文件，则须停止并重新启动 SNMP 子代理，这样更改能够生效。

# stop-msg snmp
# start-msg snmp

为 Windows 平台配置 SNMP 支持

---

虽然 SNMP 监控程序的开销非常小，但提供的 Messaging Server 一开始仍然禁用 SNMP 支持。要启用 SNMP 支持，在 DOS 提示下运行下列命令：

X:\> server_root\msg-instance\configutil /o local.snmp.enable /v 1
X:\> %SYSTEMROOT%\SYSTEM32\regsvr32.exe server_root\bin\msg\imta\bin\madmand.dll

然后，用 Windows Services 实用程序重新启动 SNMP 服务。Services 实用程序有时又称为 Microsoft Management Console。

请注意，Windows SNMP 服务在 Messaging Server SNMP 支持操作以前必须已经在运行。默认情况下，Windows SNMP 服务没有随 Windows NT 一起安装。必须手工安装 Windows SNMP 服务。

在 Windows NT 上安装 SNMP 服务的步骤如下：

1. 在控制面板右键单击网络图标。

2. 在网络窗口选择服务选项

3. 在服务对话框单击添加...按钮。

4. 在弹出的选择网络服务窗口选择网络服务列表框中的 SNMP 服务。然后单击确定按钮。

5. Windows 开始安装 SNMP 服务。为完成安装可能需要提供 Windows NT CDROM。

关于安装 SNMP 服务更详细的信息，请参考 Microsoft 的 Windows 文档。

要撤消 Messaging Server SNMP 支持，使用命令：

X:\> server_root\msg-instance\configutil /o local.snmp.enable /v 0
X:\> %SYSTEMROOT%\SYSTEM32\regsvr32.exe /u server_root\bin\msg\imta\bin\madmand.dll

然后通过 Windows Services 实用程序重新启动 SNMP 服务。

在 Windows 平台上，start-msg snmp 命令和 stop-msg snmp 命令无效。Messaging Server SNMP 支持在 Windows SNMP Services 下运行，而且只能通过启动或停止 Windows SNMP Services 来启动或停止。

来自 SNMP 客户机的监控

---

RFC 2788 和 RFC 2789 的基础 OID 是

mib-2.27 = 1.3.6.1.2.1.27

mib-2.28 = 1.3.6.1.2.1.28

使 SNMP 客户机指向那两个 OID ，并将之作为“公共”SNMP 社区访问。

如要向 SNMP 客户机装载 MIB 副本，MIB 的 ASCII 副本位于 <server_root>/plugins/snmp 目录，文件名是：rfc2788.mib 和 rfc2789.mib。关于在 SNMP 客户机软件上装载 MIB 的指导，请参考 SNMP 客户机软件文档。MIB 使用的 SnmpAdminString 数据类型可能可能让一些老的 SNMP 客户机无法识别。在这种情况下，使用等价文件：rfc2248.mib 和 rfc2249.mib，这两个文件也在同一目录下。

在 Unix 平台上与其它 iPlanet 产品共存

---

其它 Netscape 或提供 SNMP 支持的 iPlanet 产品可能通过置换平台自带的 SNMP 主代理来做到这一点。如果在与 Messaging Server 同一主机上运行这样的 iPlanet 产品并想要通过 SNMP 对其进行监控，那么请配置 iPlanet Proxy SNMP Agent，详情请见 Managing Servers with Netscape Console（http://docs.iplanet.com/docs/manuals/console/42/html/7_snmp.htm#1024620）的第 7 章。这将允许 Messaging Server SNMP 子代理 - SNMP 自带的子代理 - 与非自带的 iPlanet SNMP 子代理在其他 iPlanet 产品中共存。

SNMP 信息来自 Messaging Server

---

本节总结通过 SNMP 提供的 Messaging Server 信息。关于单个 MIB 表的详细信息，请参阅：RFC 2788 和 RFC 2789。注意，按照 RFC/MIB 的术语，邮件传输服务（MTA、HTTP 等等）称作应用程序（appl），Messaging Server网络连接称作关联（assoc），MTA 通道称作 MTA 组（mtaGroups）。

注意，在有多个 Messaging Server 实例的平台上，可能有多组 applTable 中的 MTA 和服务器以及多个其他表中的 MTA。

---

备注：	在 MIB 中报告的汇总值（例如，传输的邮件总数，IMAP 连接总数等）在重新启动之后被重新设置为零。

---

每个站点有不同的阈值和重要的监控值。正常的 SNMP 客户机允许进行趋势分析并在突然出现背离历史趋势的情况时发送报警。

applTable

applTable 提供服务器信息。启动后，为单维表，内有一行 MTA 信息，而且下列的每个服务器若启用都有一行信息：Web 邮件服务 HTTP、IMAP、POP、SMTP 和 SMTP Submit。这张表提供版本信息，正常运行时间，当前操作状态（上升，下降，堵塞），当前连接数，积累连接总数以及和其他有关数据。

下面是来自 applTable（mib-2.27.1.1）数据的一个例子。

applTable:

applName.11 = mailsrv-12 MTA on mailsrv-1.west.sesta.com

applVersion.1 = 5.1

applUptime.1 = 73223

applOperStatus.1 = up4

applLastChange.1 = 74223

applInboundAssociations.1 = 5

applOutboundAssociations.1 = 2

applAccumulatedInboundAssociations.1 = 873

applAccumulatedOutboundAssociations.1 = 234

applLastInboundActivity.1 = 10548223

applLastOutboundActivity.1 = 10542223

applRejectedInboundAssociations.1 = 05

applFailedOutboundAssociations.1 = 17

applDescription.1 = iPlanet Messaging Server 5.1

applName.21 = mailsrv-1 HTTP WebMail server on mailsrv-1.west.sesta.com

...

applName.3 = mailsrv-1 IMAP server on mailsrv-1.west.sesta.com

...

applName.4 = mailsrv-1 POP server on mailsrv-1.west.sesta.com

...

applName.5 = mailsrv-1 SMTP server on mailsrv-1.west.sesta.com

...

applName.6 = mailsrv-1 SMTP Submit server on mailsrv-1.west.sesta.com

...

说明：

1. .1, .2, 等等。这里的后缀是行号，applIndex。applIndex 的值 1 代表 MTA，值 2 代表 HTTP 服务器等等。在这个例子中，表的第一行提供 MTA 上的数据，第二行提供 POP 服务器上的数据，依此类推。

2. 实例 Messaging Server 的名称受到监控。在这个例子中，实例的名称是 mailsrv-1。

3. 这些是 SNMP 时间戳值并且是 sysUpTime 在事件发生时的值。sysUpTime，进而是 SNMP 主代理启动后以百之一秒为单位的时间。

4. HTTP、IMAP、POP、SMTP 和 SMTP Submit 服务器的操作状态是由针对它们的实际连接决定的，完成这样的连接须通过其已配置的 TCP 端口并采用适当协议（比如 HEAD 请求 和 HTTP 响应， HELO 命令和 SMTP 响应等等）执行一简单的操作。从这次连接尝试，每个服务器的状态即被决定，包括：上升（1），下降（2）或堵塞（4）。

   注意，这些检测表现为向服务器的正常入站连接，并影响每个 MIB 服务器的 applAccumulatedInboundAssociations 变量。

   MTA 的操作状态也即作业控制器的操作选状态。如果 MTA 表现为上升，那么作业控制器也上升。如果 MTA 表现为下降，那么作业控制器也下降。这种 MTA 操作状态独立于 MTA 的 服务 Dispatcher 的状态。MTA 的操作状态的值只有上升或下降。虽然作业控制器确有“堵塞”的概念，但是它没有作为 MTA 状态的一种。

5. 对 HTTP、IMAP 和 POP 服务器来说，applRejectedInboundAssociations MIB 变量表明失败登录尝试的数量，而不是被拒绝的入站连接尝试的数量。

applTable 用法

监控每个列出的应用程序的服务器状态（applOperStatus）对于监控每个服务器是至关重要的。

如果 applLastInboundActivity 所表明的最后一次入站活动已经过了很久，那么可能有些部分出现故障阻碍着连接。如果 applOperStatus=2（下降），那么受监控的服务器也下降。如果 applOperStatus=1（上升），那么问题可能出现在别的地方。

assocTable

该表向 MTA 提供网络连接信息。这是一个二维表，提供关于每个活动网络连接的信息。这样的连接信息不是向其它服务器提供的。

下面是来自 applTable（mib-2.27.2.1）的数据的一个实例。

assocTable:

assocRemoteApplication.1.11 = 129.146.198.1672

assocApplicationProtocol.1.11 = applTCPProtoID.253

assocApplicationType.1.1 = peerinitiator(3)4

assocDuration.1.1 = 4005

...

说明：

1. 在后缀 .x.y 中，x 是应用程序索引 applIndex，表明报告是针对 applTable 中的哪个应用程序的。在此例中，就是 MTA。y 用来给报告中的应用程序的每个连接编号。

2. 远程 SMTP 客户机的源 IP 地址。

3. 这是一个 OID，表明网络连接所使用的协议。aplTCPProtoID 表示 TCP 协议。后缀 .n 表明使用的是 TCP 端口，.25 表明在 TCP 端口 25 上使用的协议是SMTP。

4. 无法判断远程 SMTP 客户机是用户代理（UA）还是另一个 MTA。这样，子代理总是报告 peer-initiator；而从不会报告 ua-initiator。

5. 这是一个 SNMP TimeInterval 并以百分之一秒为单位。在这个例子中，连接打开了 4 秒。

assocTable 用法

该表用来诊断活动问题。例如，如果突然出现了 200,000 个入站连接，查看这个表可以知道它们是从哪里来的。

mtaTable

这是一个一维表，其中的每一行对应 applTable 表里的一个 MTA。每行为 mtaGroupTable 中的选择变量提供在相应 MTA 中所有通道（称为组）的总数。

下面是来自 applTable（mib-2.28.1.1）中数据的一个实例。

mtaTable:

mtaReceivedMessages.11 = 172778

mtaStoredMessages.1 = 19

mtaTransmittedMessages.1 = 172815

mtaReceivedVolume.1 = 3817744

mtaStoredVolume.1 = 34

mtaTransmittedVolume.1 = 3791155

mtaReceivedRecipients.1 = 190055

mtaStoredRecipients.1 = 21

mtaTransmittedRecipients.1 = 3791134

mtaSuccessfulConvertedMessages.1 = 02

mtaFailedConvertedMessages.1 = 0

mtaLoopsDetected.1 = 03

说明：

1. 后缀 .x 提供此应用程序在 applTable 中的行号。在此例中，.1 表示这些是 applTable 表中第一个应用程序的数据。这就是 MTA 上的数据。

2. 转换通道只能取非零值。

3. 对当前存储在 MTA 邮件入队中的 .HELD 邮件文件进行计数。

mtaTable 用法

如果 mtaLoopsDetected 不是零，则存在循环邮件问题。定位并诊断 MTA 入队里的 .HELD 文件以解决问题。

如果系统对一个转换通道进行病毒扫描并拒绝带病毒的邮件，那么 mtaSuccessfulConvertedMessages 提供不包括其他转换失败在内的带病毒邮件的计数。

mtaGroupTable

这个二维表为 applTable 中的每个 MTA 提供通道信息。这些信息包括已存储（即已入队）和已传递邮件的计数这样的数据。监控已存储邮件计数 mtaGroupStoredMessages 对每个通道都是很重要的：当该值过高时，邮件服务正在队列中备份。

下面是来自 mtaGroupTable（mib-2.28.2.1）中数据的一个实例。

mtaGroupTable:

mtaGroupName.1.11 = autoreply2

...

mtaGroupName.1.21 = ims-ms

...

mtaGroupName.1.31 = tcp_local

mtaGroupDescription.1.3 = mailsrv-1 MTA tcp_local channel

mtaGroupReceivedMessages.1.3 = 12154

mtaGroupRejectedMessages.1.3 = 0

mtaGroupStoredMessages.1.3 = 2

mtaGroupTransmittedMessages.1.3 = 12148

mtaGroupReceivedVolume.1.3 = 622135

mtaGroupStoredVolume.1.3 = 7

mtaGroupTransmittedVolume.1.3 = 619853

mtaGroupReceivedRecipients.1.3 = 33087

mtaGroupStoredRecipients.1.3 = 2

mtaGroupTransmittedRecipients.1.3 = 32817

mtaGroupOldestMessageStored.1.3 = 1103

mtaGroupInboundAssociations.1.3 = 5

mtaGroupOutboundAssociations.1.3 = 2

mtaGroupAccumulatedInboundAssociations.1.3 = 150262

mtaGroupAccumulatedOutboundAssociations.1.3 = 10970

mtaGroupLastInboundActivity.1.3 = 1054822

mtaGroupLastOutboundActivity.1.3 = 1054222

mtaGroupRejectedInboundAssociations.1.3 = 0

mtaGroupFailedOutboundAssociations.1.3 = 0

mtaGroupInboundRejectionReason.1.3 =

mtaGroupOutboundConnectFailureReason.1.3 =

mtaGroupScheduledRetry.1.3 = 0

mtaGroupMailProtocol.1.3 = applTCPProtoID.25

mtaGroupSuccessfulConvertedMessages.1.3 = 03

mtaGroupFailedConvertedMessages.1.3 = 0

mtaGroupCreationTime.1.3 = 0

mtaGroupHierarchy.1.3 = 0

mtaGroupOldestMessageId.1.3 = <01IFBV8AT8HYB4T6UA@red.iplanet.com>

mtaGroupLoopsDetected.1.3 = 04

mtaGroupLastOutboundAssociationAttempt.1.3 = 1054222

说明：

1. 在后缀 .x.y 中，x 是应用程序索引 applIndex，表明报告是针对 applTable 中的哪个应用程序。在此例中，就是 MTA。y 用来给 MTA 中的每个通道编号。编号索引 mtaGroupIndex 也用于 mtaGroupAssociationTable 和 mtaGroupErrorTable 表。

2. 报告的通道名称。在此例中，就是 autoreply 通道。

3. 转换通道只能取非零值。

4. 对当前存储在 MTA 邮件入队中的 .HELD 邮件文件进行计数。

mtaGroupTable 用法

对 *Rejected* 和 *Failed* 的趋势分析可能对确定潜在的通道问题有用。

如果 mtaGroupStoredVolume 对 mtaGroupStoredMessages 的比率突然增高，可能意味着入队退回了一个巨大的垃圾邮件。

如果 mtaGroupStoredMessages 突然增高，可能表明正在发送大宗垃圾邮件或由于某种原因传递失败。

如果 mtaGroupOldestMessageStored 的值比无法传递邮件通知次数（notices 通道关键字）还多，可能表明对一邮件无法进行即使象退回这样的处理。注意，退回是在夜里进行的，因此将需要使用
mtaGroupOldestMessageStored >（最大时限＋24 小时）检测。

如果 mtaGroupLoopsDetected 大于零，即检测到邮件循环。

mtaGroupAssociationTable

这是一个三维表，其条目是 assocTable 中的索引值。对于 applTable 表中的每个 MTA，都有一个两维子表。这个两维子表中的每一行对应相应 MTA 的一个通道。每个通道里的每个当前活动网络连接都有一个条目。这个条目的值就是 assocTable 的一个索引值（通过条目的值索引和并且要被 MTA 的 applIndex 索引查看）。这个 assocTable 中的表示条目是通道所保持的网络连接。

简单说来，mtaGroupAssociationTable 表与 assocTable 表中显示的网络连接以及 mtaGroupTable 表中的对应通道相关。

下面是来自 mtaGroupAssociationTable（mib-2.28.3.1）表中数据的一个实例。

mtaGroupAssociationTable:

mtaGroupAssociationIndex.1.3.11 = 12

mtaGroupAssociationIndex.1.3.2 = 2

mtaGroupAssociationIndex.1.3.3 = 3

mtaGroupAssociationIndex.1.3.4 = 4

mtaGroupAssociationIndex.1.3.5 = 5

mtaGroupAssociationIndex.1.3.6 = 6

mtaGroupAssociationIndex.1.3.7 = 7

说明：

1. 在后缀 .x.y.z 中，x 是应用程序索引 applIndex，表示报告的是 applTable 中的哪个应用程序。在此例中，就是 MTA。而 y 表明报告的是 mtaGroupTable 的哪个通道。在此例中，3 表明是 tcp_local 通道。而 z 则用来给向通道打开的或来自通道的关联编号。

2. 此值是 assocTable 的一个索引值。特别是，x 和这个值分别成为 applIndex 和 assocIndex 在 assocTable 里的索引。或者，换句话说，（忽略 applIndex）assocTable 中的第一行描述受 tcp_local 通道控制的网络连接。

mtaGroupErrorTable

这是另外一个三维表，它给出每个 MTA 尝试传递邮件时遇到的临时性和永久性的错误的计数。具有索引值为 4000000 的条目是临时性错误，索引值为 5000000 的条目是永久性错误。临时性错误导致邮件重新入队以便以后尝试传递，永久性错误则导致邮件被拒绝或者作为无法传递邮件而被退回。

下面是来自 mtaGroupErrorTable（mib-2.28.5.1）中数据的一个实例。

mtaGroupErrorTable:

mtaGroupInboundErrorCount.1.1.40000001 = 0

mtaGroupInboundErrorCount.1.1.5000000 = 0

mtaGroupInternalErrorCount.1.1.4000000 = 0

mtaGroupInternalErrorCount.1.1.5000000 = 0

mtaGroupOutboundErrorCount.1.1.4000000 = 0

mtaGroupOutboundErrorCount.1.1.5000000 = 0

mtaGroupInboundErrorCount.1.2.40000001 = 0

...

mtaGroupInboundErrorCount.1.3.40000001 = 0

...

说明：

1. 在后缀 .x.y.z 中，x 是应用程序索引 applIndex，表示报告的是 applTable 中的哪个应用程序。在此例中，就是 MTA 而 y 表明报告的是 mtaGroupTable 的哪个通道。在此例中，1 是 autoreply 通道，2 是 ims-ms 通道，3 是 tcp_local 通道。最后，z 是 4000000 或 5000000，分别表示在该通道尝试传递邮件时遇到的临时性和永久性错误的计数。

mtaGroupErrorTable 用法

错误计数的突然增高很可能表明出现不正常传递问题。例如，tcp_channel 通道的计数突然增高可能表明出现 DNS 或网络问题。ims_ms 通道的计数突然增高可能表明向邮件存储库传递邮件时遇到问题（例如，分区已满、存储问题，等等。）

上一页    目录    索引    下一页

---

(c) 2002 年 Sun Microsystems, Inc. 版权所有。

更新日期：2002 年 2 月 27 日