Sun Java System Messaging Server 6.3 管理指南

附录 A SNMP 支持

Messaging Server 支持通过简单网络管理协议 (Simple Network Management Protocol, SNMP) 进行系统监视。使用 SNMP 客户端（有时称为网络管理器），例如 Sun Net Manager 或 HP OpenView（未与此产品一起提供），您可以监视 Messaging Server 的特定部分。有关监视 Messaging Server 的更多信息，请参阅第 27 章，监视 Messaging Server。

本章介绍如何为 Messaging Server 启用 SNMP 支持。同时还概述了 SNMP 所提供的信息类型。请注意，本章不介绍如何从 SNMP 客户端查看此信息。有关如何使用 SNMP 客户端查看基于 SNMP 的信息的详细信息，请参见 SNMP 客户端文档。本文档还介绍了 Messaging Server SNMP 实现的某些可用数据，但完整的 MIB 详细资料可以从 RFC 2788 和 RFC 2789 获得。

本章包含以下几个部分：

A.1 SNMP 实现

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 和 Red Hat Linux 的平台支持 SNMP。 Solaris 9 操作系统中的 Messaging Server 使用 Solstice Enterprise Agent (SEA)。从 Solaris 10 操作系统开始，Messaging Server 支持开放源代码 Net-SNMP 监视框架，使得 Solaris 9 操作系统 Solstice Enterprise Agent (SEA) 技术成为历史（不再受支持）。此外，Net-SNMP 广泛用于 Linux 平台。Messaging Server 将在 Solaris 10 中使用其基于 Net-SNMP 的 SNMP 子代理，以后也会在 Linux 平台上使用。

通过采用 Net-SNMP 框架，Messaging Server 的 SNMP 子代理提供了新的功能：

支持 SNMP 版本 2c 和版本 3。这是通过 Net-SNMP 框架实现的。以前的 SNMP 技术 Solstice Enterprise Agent 只提供对 SNMP 版本 1 的支持。增强的安全功能和访问控制是 SNMP 这两个版本的主要优点。
可以配置子代理作为“独立”SNMP 代理运行。这为站点提供了一些附加方法，可将运行在同一系统上的各种 SNMP 代理进行隔离。
在同一系统上运行的多个 Messaging Server“实例”可以同时被监视。该支持可通过以上第 2 项提供，也可以通过 SNMP 版本 3“上下文名称”来实现。这允许在故障转移群集中对 Messaging Server 进行 SNMP 监视。

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

在 Solaris 9 操作系统中，只能通过 SNMP 监视每台主机的一个 Messaging Server 实例。
SNMP 支持仅用于监视。不支持 SNMP 管理。
不实现 SNMP 陷阱。（RFC 2788 提供相似的功能，但不使用陷阱。）

A.1.1 Messaging Server 中的 SNMP 操作

Messaging Server SNMP 进程是一个 SNMP 子代理，该子代理在启动时将自身注册到平台的本机 SNMP 主代理。来自客户端的 SNMP 请求进入主代理。主代理将发送给 Messaging Server 的所有请求转发给 Messaging Server 子代理进程。Messaging Server 子代理进程将处理请求，并通过主代理将响应转发回客户端。图 A–1 显示了此过程。

图 A–1 SNMP 信息流

A.2 在 Solaris 9 中为 Messaging Server 配置 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 进程。

请注意，为使 Messaging Server SNMP 子代理能够操作，必须运行 Solaris 本机 SNMP 主代理。Solaris 本机 SNMP 主代理是 snmpdx 守护进程，通常作为 Solaris 引导过程的一部分启动。

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 文件中指定端口号。如果指定了端口号，则将使用该端口号，除非您还使用 configutil 实用程序设置了另一个端口号。在这种情况下，使用 configutil 设置的端口号就是子代理将要使用的端口号。如果编辑了文件，则需要使用以下命令停止并重新启动 SNMP 子代理才能使更改生效：

# stop-msg snmp
# start-msg snmp

注 –

在 Messaging Server 中启用 SNMP 支持时，通过 SNMP 在 Solaris 10 操作系统上进行的所有查询都必须连接到默认端口 16161。例如，如果使用开放源代码 SNMP 工具 snmpwalk 来查询 Messaging Server 的网络/邮件统计信息，应使用选项 -p 16161。

A.3 为 Solaris 10 操作系统配置 SNMP 支持

默认情况下，SNMP 监视在 Messaging Server 中是禁用的。试图最小化默认 Messaging Server 配置表示的服务数时选择默认设置。不要将此默认设置理解为使用 SNMP 监视会引起性能损耗。实际上，Messaging Server 的 SNMP 支持消耗非常少的资源，对 Messaging Server 的影响很小。当然，必须要注意的一点是，使用 Messaging Server 的 SNMP 支持之前需要一次性配置步骤。此外，平台 Net-SNMP 主代理的默认配置（snmpd）通常需要更改，以便运行子代理，如 Messaging Server。该更改是下一节讨论的主题。

A.3.1 Net-SNMP 配置

Messaging Server 基于 Net-SNMP 的 SNMP 子代理使用 AgentX 协议与平台 SNMP 主代理进行通信 (RFC 2741)。Net-SNMP 主代理 snmpd 必须配置为允许使用 AgentX 协议。要完成此操作，请确保平台的 snmpd.conf 文件包含下行

master agentx

如果该行不存在，则添加该行并重新启动 snmpd 守护程序。请注意，将 SIGHUP 信号发送给守护程序是不够的。重新启动了 snmpd 守护程序之后，请查找 UNIX 域套接字，该套接字是 snmpd 为 AgentX 通信创建的。在 Solaris 和 Linux 系统中，该套接字默认情况下显示为特殊文件 /var/agentx/master；但是，其位置和名称可能会通过 snmpd.con 文件进行更改。

Solaris 10 操作系统 snmpd 配置如下所示：

%cp /etc/sma/snmp/snmpd.conf /etc/sma/snmp/snmpd.conf.save
% cat >> /etc/sma/snmp/snmpd.conf
# Messaging Server's subagent requires the AgentX protocol
master agentx
^D
% cat >> /etc/sma/snmp/snmpd.conf
% ls -al /var/agentx/
srwxrwxrwx 1 root root 0 Aug 9 13:58 /var/agentx/master

此外，在 Red Hat Enterprise Linux AS 3 系统中，默认 snmpd.conf 文件限制“公用”SNMP 社区可能会查看的信息。因此有必要删除该限制，或者将其扩展为包含 Messaging Server 子代理实现的 MIB。考虑到初始测试，建议采用后者。实现这一点的方式是，包含名为 "systemview" 的视图中的 OID 子树 mib-2.27 和 mib-2.28（如下所示）。对于实际部署，每个站点必须考虑其总体安全策略。请注意，SNMP 子代理提供的信息是“只读”的。

% cp /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.save
% cat >>/etc/snmp/snmpd.conf
# Messaging Server's subagent requires the AgentX protocol
master agentx
# Messaging Server's subagent exports mib-2.27 and .28
# Add the mib-2.27 and .28 OID subtrees to the systemview
view systemview included .1.3.6.1.2.1.27
view systemview included .1.3.6.1.2.1.28
^D
% /sbin/service snmpd restart
% ls -al /var/agentx/master
srwxr-xr-x 1 root root 0 Aug 8 21:20 /var/agentx/master

如果您将使用 SNMP v3 上下文名称来区分同时运行在同一主机上的不同 Messaging Server 实例的 MIB，则至少还需要配置一个 SNMP v3 以及用于 SNMP v3 查询的用户名和密码。

A.3.2 Messaging Server 子代理配置

至于 Messaging Server 的 SNMP 子代理的基本操作，您只需启用它并发出一个一次性手动启动命令。之后，无论何时启动或停止 Messaging Server，子代理将同样被启动或停止。在 Solaris 和 Linux 上实现此配置所需的命令如下：

% configutil -o local.snmp.enable -v 1
% start-msg snmp

运行后，可以使用 snmpwalk 命令通过命令行测试子代理。请参见示例下面适用于 Solaris 和 Linux 的屏幕截图。请注意，文件 rfc2248.txt 和 rfc2249.txt 是网络服务和 MTA MIB 的副本。在 Solaris 系统中，可以在 NETWORK-SERVICES-MIB.txt 和 MTA-MIB.txt 下的 /etc/sma/snmp/mibs/ 目录中找到这些文件。没有必要将这些文件提供给 snmpwalk 工具，但是，这样做允许 snmpwalk 输出每个 MIB 变量的名称，而不是它们的数字对象标识符 (OID)。

在 Solaris 上的基本测试：

% D=/opt/SUNWmsgsr/examples/mibs /usr/sfw/bin/snmpwalk -v 1 -c public \
    -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.27
NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/SUNWmsgsr MTA on mail.siroe.com
...
% D=/opt/SUNWmsgsr/examples/mibs /usr/sfw/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.28
MTA-MIB::mtaReceivedMessages.1 = Counter32: 1452
MTA-MIB::mtaStoredMessages.1 = Gauge32: 21
...

在 Linux 上的基本测试：

% export D=/opt/sun/messaging/examples/mibs
% /usr/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.27
NETWORK-SERVICES-MIB::applName.1 = STRING: /opt/sun/messaging MTA on mail.siroe.com
...
% /usr/bin/snmpwalk -v 1 -c public \
     -m +$D/rfc2248.txt:$D/rfc2249.txt 127.0.0.1 mib-2.28
MTA-MIB::mtaReceivedMessages.1 = Counter32: 21278
MTA-MIB::mtaStoredMessages.1 = Gauge32: 7
...

A.3.3 作为独立的 SNMP 代理运行

在将 Messaging Server SNMP 子代理配置为独立的 SNMP 代理运行之前，您必须首先决定该代理侦听 SNMP 请求的以太网接口和 UDP 端口。在默认情况下，该代理将使用 UDP 端口 161 来侦听所有可用的以太网接口。在大多数情况下，您需要更改此端口号，以便不影响平台的 SNMP 主代理 snmpd。在某些情况下，例如 HA 故障转移，您还需要将所有可用接口中的以太网接口 (INADDR_ANY) 更改为由其 IP 地址标识的特定接口。以太网接口和 UDP 端口这两个概念由 local.snmp.listenaddr 和 local.snmp.port 选项控制。

对以太网接口和 UDP 端口作出选择之后，应该将 local.snmp.standalone 选项的值设置为 1 并重新启动子代理。重新启动后，它将作为一个与 snmpd 和任何子代理无关的 SNMP 代理运行。

例如，要作为独立代理（侦听 IP 地址为 10.53.1.37 的以太网接口的 UDP 端口 9161）运行，请发出如下所示的命令。

配置为作为独立代理运行：

% configutil -o local.snmp.port -v 9161
% configutil -o local.snmp.listenaddr -v 10.53.1.37
% configutil -o local.snmp.standalone -v 1
% stop-msg snmp
% start-msg snmp
% snmpwalk -v 1 -c public 10.53.1.37:9161 .
SNMPv2-SMI::mib-2.27.1.1.2.1 = STRING: "/opt/SUNWmsgsr MTA on mail.siroe.com"
...

A.3.4 监视 Messaging Server 的多个实例

这里讨论了两种用于监视同一主机上运行的多个 Messaging Server 实例的技术。第一种技术，以独立模式运行子代理，这非常适于高可用性的故障转移 (HA) 配置，其中 Messaging Server 的单个实例可能会在主机之间动态地移动。第二种技术，使用 SNMP v3 上下文名称，其优点体现在 Messaging Server 的多个实例被限制在单个系统上的情况下，该技术需要限制由 SNMP 监视软件轮询的 IP 地址数（例如，当监视软件的许可具有基于 IP 地址的成本组件时）。后一种技术也可用于 HA 故障转移设置，但是需要轮询和独立模式技术一样多的 IP 地址。

A.3.5 将独立的代理用于高可用性故障转移

在需要 Messaging Server 的 SNMP 监视的高可用性故障转移中，建议将 Messaging Server 的 SNMP 子代理作为A.3.3 作为独立的 SNMP 代理运行中所描述的独立子代理运行。子代理运行在独立模式下时，Messaging Server 的每个 HA 实例都应该将其 local.snmp.listenaddr 选项设置为该实例的故障转移 IP 地址的值。要简化管理，每个实例应该使用相同的 UDP 端口，但该端口要与 snmpd 守护程序（运行在每个物理群集主机上）所使用的端口区别开。通常，这些守护程序将使用 UDP 端口 161，因此要使用 local.snmp.port 选项明确指定不同的端口号。

按给出的建议配置好 Messaging Server 的 SNMP 支持后，监视站可以通过其故障转移 IP 地址或主机名来监视每个 Messaging Server 实例，而不管实例运行在哪个物理群集主机上。而且，您可以确保 Messaging Server 的独立 SNMP 代理不会相互冲突，因为每个代理只侦听它自己的虚拟以太网接口，该接口由实例的唯一故障转移 IP 地址标识。（这些虚拟以太网接口由 HA 故障转移框架自动创建。）由于对 UDP 端口进行了仔细选择，因此代理不会与在群集中的系统上运行的 snmpd 守护程序冲突。

A.3.6 通过 SNMP v3 上下文名称区分多个实例

虽然使用A.3.3 作为独立的 SNMP 代理运行中所描述的以独立模式使用 Messaging Server 的 SNMP 支持没有什么不利，但一些站点还是希望使用更传统的子代理模式，同时仍具有监视同时运行在同一系统上的多个 Messaging Server 实例的功能。例如，许可模型限制轮询 IP 地址数的 SNMP 监视系统。要实现此目标，请继续运行 Messaging Server 的 SNMP 子代理，并将 local.snmp.standalone 设置为 0。此外，为 local.snmp.enablecontextname 选项指定一个非零值，从而将每个 Messaging Server 实例配置为使用不同的 SNMP v3 上下文名称。如果需要的上下文名称不同于 service.defaultdomain 的值，则使用 local.snmp.contextname 选项设置所需的名称。重新启动每个 Messaging Server 的 SNMP 子代理实例之后，就可以通过包含正确上下文名称的 SNMP v3 查询来监视这些实例。运行在同一系统上的两个 Messaging Server 实例的 MIB 通过实例的 SNMP v3 上下文名称来区分，因此不会出现 MIB 对象标识符 (OID) 冲突。

A.3.7 Messaging Server 的基于 Net-SNMP 的 SNMP 子代理选项

以下选项只适用于 Messaging Server 的基于 Net-SNMP 的 SNMP 子代理。该子代理在运行 Solaris 10 以及更高版本的 Solaris 平台上使用，也可以在 Linux 平台上使用。以下介绍的选项不适用于为运行 Solaris 9 及更低操作系统的 Solaris 平台而提供的传统 SNMP 子代理。

以下介绍的选项是 configutil 选项。因此，可通过以下形式的命令来查看这些选项的值：

% configutil -o option-name

其中 option-name 是要显示选项值的选项的名称。要设置或更改选项的值，请使用以下形式的命令

% configutil -o option-name -v option-value

其中 option-value 是要设置的值。需要重新启动才能使这些选项的更改生效：

% stop-msg snmp
% start-msg snmp

接下来给出每个选项的说明及其默认值。

表 A–1 SNMP 子代理选项


选项（默认值）	说明
local.snmp.启用 (0)	Messaging Server SNMP 子代理只在该选项值为 `1` 或 `true` 时才运行，在这种情况下，Messaging Server 将自动停止或启动子代理，并将其作为正常启动和关闭过程的一部分。默认情况下，该选项设置为 0，这样会禁用子代理的操作。在启用子代理之前，请确保平台的主代理已按照A.3.3 作为独立的 SNMP 代理运行中所描述的方法正确配置。
local.snmp.standalone (0)	Messaging Server 的 SNMP 支持通常作为 SNMP 子代理运行，并通过平台的 SNMP 主代理 `snmpd` 接收 SNMP 请求。该操作模式是默认设置，通过将该选项的值指定为 0 或 `false` 来选择此默认设置。但是，如A.3.3 作为独立的 SNMP 代理运行中所述，子代理可能会以“独立”模式运行，从而以独立于 `snmpd` 的 SNMP 代理运行。当以独立模式运行时，子代理（现在是 SNMP 代理）直接侦听以太网接口和 UDP 端口上的 SNMP 请求，以太网接口和 UDP 端口分别由 `local.snmp.listenaddr` 和 `local.snmp.port` 选项指定。要在此独立模式下运行，请将该选项的值指定为 1 或 `TRUE`。以独立模式运行并不影响运行在同一系统上的其他 SNMP 主代理或子代理。
local.snmp.listenaddr (INADDR_ANY)	以独立模式运行时侦听 SNMP 请求的主机名或以太网接口的 IP 地址。默认情况下，侦听所有可用的接口。这对应于指定值 `INADDR_ANY`。可以通过指定与接口关联的 IP 地址或主机名来选择特定接口。此接口可以是物理接口，也可以是虚拟接口。 `local.snmp.standalone` 设置为 0 或 `FALSE` 时忽略该选项。
local.snmp.cachettl (30)	缓存监视数据的生存时间 (TTL)（以秒为单位）。该选项控制在使用从 Messaging Server 获得的新信息刷新监视数据之前，子代理报告相同监视数据的时间。除邮件循环信息外，默认情况下，缓存数据的时间不超过 30 秒。循环信息（通过扫描 `.HELD` 文件确定）每 10 分钟才更新一次。这是因为扫描所有盘上邮件队列会消耗资源。请注意，子代理并不持续更新其监视数据：只有在收到 SNMP 请求，并且高速缓存的数据过期时（即，超过其生存时间）才进行更新。如果将生存时间 (TTL) 设置为 30 秒，并且每 5 分钟发出一次 SNMP 请求，则每个 SNMP 请求将导致子代理从 Messaging Server 中获得刷新的数据。即，每 5 分钟就可从 Messaging Server 中获得一次数据。另一方面，如果每 10 秒发出一次 SNMP 请求，则子代理将使用已缓存了 29 秒的数据来响应其中一些请求；Messaging Server 则每 30 秒被轮询一次。
local.snmp.servertimeout (5)	子代理通过实际打开到每个服务的 TCP 连接，以及进行协议转换来确定每个所监视服务的操作状态。该超时值（以秒为单位）控制子代理等待响应协议转换中每个步骤的时间。默认情况下，使用的超时值为 5 秒。
local.snmp.directoryscan (1)	使用该选项控制子代理是否为 `.HELD` 邮件文件和最早的邮件文件执行盘上邮件队列扫描。该信息对应于 `mtaGroupLoopsDetected`、`mtaGroupOldestMessageStored` 和 `mtaGroupOldestMessageId` MIB 变量。当该选项的值为 1 或 `true` 时，将根据需要维护和更新此信息的缓存。具有大量排队邮件并且不需要这些特定 MIB 变量的站点应该考虑将该选项的值设置为 0 或 `false`。
local.snmp.enablecontextname (0)	子代理可以在 SNMP v3 上下文名称下注册其 MIB。完成此操作后，可以仅通过 SNMP v3 客户端请求 MIB，该客户端在其 SNMP 请求中指定上下文名称。使用上下文名称允许多个独立的子代理在同一 OID 树下（即，同一 SNMP 主代理下）注册网络服务和 MTA MIB。有关详细信息，请参见A.3.4 监视 Messaging Server 的多个实例。要启用 SNMP v3 上下文名称，请将该选项的值指定为 1 或 `true`。当完成此操作后，子代理将默认使用其上下文名称的 `service.defaultdomain` 选项的值。要对上下文名称使用别的值，请使用 `local.snmp.contextname` 选项。
local.snmp.contextname (service.defaultdomain)	使用 `local.snmp.enablecontextname` 启用 SNMP v3 上下文名称时，该选项可用来明确设置子代理用于其 MIB 的上下文名称。为该选项提供的值是字符串值，必须适合用作 SNMP v3 上下文名称。当 `local.snmp.enablecontextname` 的值为 0 或 `false` 时忽略该选项。

A.4 通过 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，并将其作为“公用”社区访问。

如果要将 MIB 副本装入 SNMP 客户端，您可以在 msg-svr-base/lib/config-templates 目录的 rfc2788.mib 和 rfc2789.mib 文件名下找到 MIB 的 ASCII 副本。有关在 SNMP 客户端软件中装入 MIB 的指导信息，请参见 SNMP 客户端软件文档。某些较旧的 SNMP 客户端可能无法识别这些 MIB 中使用的 SnmpAdminString 数据类型。在这种情况下，请使用位于同一目录中的等效文件 rfc2248.mib 和 rfc2249.mib。

A.5 来自 Messaging Server 的 SNMP 信息

本节概述了通过 SNMP 提供的 Messaging Server 信息。其中包含以下各小节：

有关更多信息，请参阅 RFC 2788 和 RFC 2789 中的单个 MIB 表。请注意，RFC/MIB 术语中将邮件传送服务（MTA、HTTP 等）称为应用程序 (appl)，将 Messaging Server 网络连接称为关联 (assoc)，将 MTA 通道称为 MTA 组 (mtaGroups)。

请注意，在可同时监视多个 Messaging Server 实例的平台上，applTable 中可能会包含多组 MTA 和服务器，其他表中可能会包含多个 MTA。

注 –

重新引导后将把 MIB 中报告的累积值（例如，被传送邮件的总数、IMAP 连接总数等）重置为零。

每个站点都有不同的阈值和重要的监视值。好的 SNMP 客户端允许进行趋势分析，并在突然出现背离历史趋势的情况时发送警告。

A.5.1 applTable

applTable 提供服务器信息。它是一维表格，一行用于 MTA，其他每一行用于以下一个服务器（如果已启用）：WebMail HTTP、IMAP、POP、SMTP 和 SMTP Submit。该表提供版本信息、正常运行时间、当前操作状态（up、down、congested）、当前连接数量、累积连接总数和其他相关数据。

以下是 applTable (mib-2.27.1.1) 中的数据的示例。

            
applTable:

    applName.1  = mailsrv-1  MTA on mailsrv-1.west.sesta.com      (1)
    applVersion.1 = 5.1
    applUptime.1 = 7322                         (2)
    applOperStatus.1 = up                       (3)
    applLastChange.1 = 7422                     (2)
    applInboundAssociations.1 =                 (5)
    applOutboundAssociations.1 =                (2)
    applAccumulatedInboundAssociations.1 = 873
    applAccumulatedOutboundAssociations.1 = 234
    applLastInboundActivity.1 = 1054822          (2)
    applLastOutboundActivity.1 = 1054222         (2)
    applRejectedInboundAssociations.1 = 0        (4)
    applFailedOutboundAssociations.1 = 17
    applDescription.1 = Sun Java System Messaging Server 6.1
    applName.2 1 = mailsrv-1 HTTP WebMail svr. mailsrv-1.sesta.com (1)
    ...
    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
    ...

注释：

应用程序 (.appl*) 后缀（.1、.2 等）为行编号 applIndex。applIndex 的值 1 代表 MTA，值 2 代表 HTTP 服务器，等等。因此，在此示例中，表格的第一行提供 MTA 中的数据，第二行提供 POP 服务器中的数据，等等。

等号后边的名称是受监视的 Messaging Server 实例的名称。在此示例中，实例名称是 mailsrv-1。
这些是 SNMP 时间戳值，也是事件发生时的 sysUpTime 的值。sysUpTime 是 SNMP 主代理启动后以百分之一秒为单位的计数。
通过已配置的 TCP 端口实际连接到 HTTP、IMAP、POP、SMTP 和 SMTP Submit 服务器，并使用相应协议（例如，用于 HTTP 的 HEAD 请求和响应，用于 SMTP 的 HELO 命令和响应等）执行简单操作可以确定这些服务器的运行状态。通过此连接尝试，可以确定每个服务器的状态—up (1)、down (2) 或 congested (4)。

请注意，这些探测将显示为服务器的正常入站连接，并会影响每台服务器的 applAccumulatedInboundAssociations MIB 变量的值。

对于 MTA，操作状态即作业控制器的操作状态。如果 MTA 显示为“up”，则作业控制器也为“up”。如果 MTA 显示为“down”，则作业控制器也为“down”。该 MTA 操作状态独立于 MTA 的服务分发程序的状态。MTA 的操作状态只有 up 值或 down 值。尽管作业控制器中包含 "congested" 这一概念，但 MTA 状态中没有此概念。
对于 HTTP、IMAP 和 POP 服务器，applRejectedInboundAssociations MIB 变量表示失败的登录尝试的数量，而不是被拒绝的入站连接尝试的数量。

A.5.1.1 applTable 的用法

监视列出的每个应用程序的服务器状态 (applOperStatus) 对于监视每台服务器至关重要。

如果自最后一次 MTA 入站活动（如 applLastInboundActivity 所示）至今已有很长一段时间，则可能出现了故障，从而无法连接。如果 applOperStatus=2 (down)，则受监视服务已关闭。如果 applOperStatus=1 (up)，则问题可能出现在其他地方。

A.5.2 assocTable

该表提供 MTA 的网络连接信息。这是二维表格，提供有关每个活动的网络连接的信息。不提供其他服务器的连接信息。

以下是 applTable (mib-2.27.2.1) 数据的示例。

assocTable:

    assocRemoteApplication.1.1  = 129.146.198.167        (1)
    assocApplicationProtocol.1.1 = applTCPProtoID.25     (2)
    assocApplicationType.1.1 = peerinitiator(3)          (3)
    assocDuration.1.1 = 400                              (4)
...

注释：

在后缀 .x.y (1.1) 中，x 为应用程序索引 applIndex，表示报告的是 applTable 中的哪个应用程序。在此示例中为 MTA。y 用于枚举所报告的应用程序的每个连接。

远程 SMTP 客户端的源 IP 地址。
这是一个 OID，表示网络连接所使用的协议。aplTCPProtoID 表示 TCP 协议。后缀 .n 表示使用的 TCP 端口，.25 表示基于 TCP 端口 25 使用的 SMTP 协议。
无法判断远程 SMTP 客户端是用户代理 (UA) 还是其他 MTA。因此，子代理始终报告 peer-initiator，而不报告 ua-initiator。
这是 SNMP TimeInterval，单位为百分之一秒。在此示例中，连接已打开 4 秒钟。

A.5.2.1 assocTable 的用法

该表用来诊断活动问题。例如，如果突然有 200,000 个入站连接，查看此表可以知道它们的来源。

A.5.3 mtaTable

这是一维表格，其中一行用于 applTable 中的一个 MTA。每一行为 mtaGroupTable 中的选定变量提供了该 MTA 中所有通道（称为组）的总数。

以下是 applTable (mib-2.28.1.1) 中的数据的示例。

mtaTable:

    mtaReceivedMessages.1 = 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 = 0 (1)
    mtaFailedConvertedMessages.1 = 0
    mtaLoopsDetected.1 = 0               (2)

注释：

后缀 .x (.1) 提供此应用程序在 applTable 中的行编号。在此示例中，.1 表示此数据用于 applTable 中第一个应用程序。因此，这是 MTA 中的数据。

对于转换通道，仅使用非零值。
对当前存储在 MTA 邮件队列中的 .HELD 邮件文件进行计数。

A.5.3.1 mtaTable 的用法

如果 mtaLoopsDetected 不为零，则存在循环邮件问题。请查找并诊断 MTA 队列中的 .HELD 文件以解决问题。

如果系统对转换通道进行病毒扫描并拒绝被感染邮件，则除了其他转换失败外，mtaSuccessfulConvertedMessages 还将给出被感染邮件的计数。

A.5.4 mtaGroupTable

此二维表格提供 applTable 中每个 MTA 的通道信息。此信息包括诸如已存储（即已入队）邮件消息计数和已传送邮件消息计数等数据。监视每个通道的已存储邮件的计数 (mtaGroupStoredMessages) 很重要：当该值变得异常庞大时，邮件正在队列中备份。

以下是 mtaGroupTable (mib-2.28.2.1) 中的数据的示例。

mtaGroupTable:

mtaGroupName.1.1 = tcp_intranet                1
        ...
mtaGroupName.1.2 = ims-ms
        ...
mtaGroupName.1.3 = 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     2
    mtaGroupFailedConvertedMessages.1.3 = 0
    mtaGroupCreationTime.1.3 = 0
    mtaGroupHierarchy.1.3 = 0
    mtaGroupOldestMessageId.1.3 = <01IFBV8AT8HYB4T6UA@red.iplanet.com>
    mtaGroupLoopsDetected.1.3 = 0                    3
    mtaGroupLastOutboundAssociationAttempt.1.3 = 1054222

注释：

在后缀 .x.y（例如：1.1、1.2、1.3）中，x 为应用程序索引 applIndex，表示报告的是 applTable 中的哪个应用程序。在此示例中为 MTA。y 用于枚举 MTA 中的每个通道。枚举索引 mtaGroupIndex 也用于 mtaGroupAssociationTable 和 mtaGroupErrorTable 表。

所报告的通道的名称。在此示例中为 tcp_intranet 通道。
对于转换通道，仅使用非零值。
对当前存储在此通道的邮件队列中的 .HELD 邮件文件进行计数。

A.5.4.1 mtaGroupTable 的用法

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

mtaGroupStoredVolume 对 mtaGroupStoredMessages 的比率突然增高可能意味着队列附近正退回一个巨大的垃圾邮件。

mtaGroupStoredMessages 突然增高可能表示正在发送非请求的批量电子邮件或由于某种原因导致传送失败。

如果 mtaGroupOldestMessageStored 的值大于无法传送的邮件通知次数（notices 通道关键字）的值，则可能表示即使采用退回处理也无法处理该邮件。请注意，退回在每晚进行，因此您需要使用 mtaGroupOldestMessageStored >（最长存在时间 + 24 小时）进行测试。

如果 mtaGroupLoopsDetected 大于 0，则检测到邮件循环。

A.5.5 mtaGroupAssociationTable

这是三维表格，其条目是 assocTable 的索引。对于 applTable 中的每个 MTA，都有一个二维子表格。此二维子表中的每一行用于相应 MTA 中的一个通道。对于每个通道，通道当前正在使用的每个活动网络连接都有一个条目。该条目的值是 assocTable 的索引（由条目的值以及正在查看的 MTA 的 applIndex 索引进行索引）。这表示 assocTable 中的条目是通道所拥有的网络连接。

简而言之，mtaGroupAssociationTable 表将 assocTable 中所示的网络连接与 mtaGroupTable 中的相关通道关联起来。

以下是 mtaGroupAssociationTable (mib-2.28.3.1) 中的数据的示例。

mtaGroupAssociationTable:

    mtaGroupAssociationIndex.1.3.1 = 1 1
    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

注释：

在后缀 .x.y.z 中，x 为应用程序索引 applIndex，表示报告的是 applTable 中的哪个应用程序。在此示例中为 MTA。y 表示报告的是 mtaGroupTable 中的哪个通道。在此示例中，3 表示 tcp_local 通道。z 用于枚举向通道打开的或来自通道的关联。

此处的值是 assocTable 的索引。特别是，x 和该值将分别成为 applIndex 和 assocIndex 在 assocTable 中的索引值。或者，换言之（忽略 applIndex），assocTable 中的第一行说明了由 tcp_local 通道所控制的网络连接。

A.5.6 mtaGroupErrorTable

这又是一个三维表格，它给出在尝试邮件传送时每个 MTA 的每个通道遇到的临时错误和永久性错误的计数。索引值为 4000000 的条目是临时错误，索引值为 5000000 的条目是永久性错误。临时错误导致将邮件重新入队，以后再尝试传送；永久性错误导致邮件被拒绝或作为无法传送的邮件被返回。

以下是 mtaGroupErrorTable (mib-2.28.5.1) 中的数据的示例。

mtaGroupErrorTable:

    mtaGroupInboundErrorCount.1.1.4000000 1 = 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.4000000 1 = 0
    ...

    mtaGroupInboundErrorCount.1.3.4000000 1 = 0
    ...

注释：

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

A.5.6.1 mtaGroupErrorTable 的用法

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