Sun Java System Messaging Server 6 2005Q4 管理指南

附录 A SNMP 支持

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

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

本章包含以下几个部分:

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 8 和 9 以及 Java Enterprise System 所支持的所有版本的 Microsoft Windows 平台上均支持 SNMP。以后的版本中会有其他平台的支持。Solaris 中的 SNMP 支持使用本地 Solaris SNMP 技术 Solstice Enterprise Agent (SEA)。用户无需在 Solaris 8 系统中安装 SEA:所需的运行时库都已经存在。

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

Messaging Server 中的 SNMP 操作

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

图 A–1 SNMP 信息流

此图形显示了 SNMP 信息流。

在 Solaris 8 中为 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


通过 SNMP 客户机监视

RFC 2788RFC 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.mibrfc2789.mib 文件名下找到 MIB 的 ASCII 副本。有关在 SNMP 客户机软件中装入 MIB 的指导信息,请参见 SNMP 客户机软件文档。某些较旧的 SNMP 客户机可能无法识别这些 MIB 中使用的 SnmpAdminString 数据类型。在这种情况下,请使用位于同一目录中的等效文件 rfc2248.mibrfc2249.mib

与 Unix 平台上的其他 Sun Java System 产品共存

提供 SNMP 支持的其他 Netscape 或 Sun Java System 产品通过取代平台的本机 SNMP 主代理也可以做到这一点。如果要在 Messaging Server 所在的同一主机上运行此类 Sun Java System 产品,并希望通过 SNMP 监视这二者,请按照 (Managing Servers with iPlanet Console) 的第 11 章中所述配置 Sun Java System Proxy SNMP Agent。这将允许 Messaging Server SNMP 子代理(本机 SNMP 子代理)与其他 Sun Java System 产品中的非本机 Sun Java System SNMP 子代理共存。

来自 Messaging Server 的 SNMP 信息

本节概述了通过 SNMP 提供的 Messaging Server 信息。有关更多信息,请参阅 RFC 2788RFC 2789 中的单个 MIB 表。请注意,RFC/MIB 术语中将邮件服务(MTA、HTTP 等)称为应用程序 (appl),将 Messaging Server 网络连接称为关联 (assoc),将 MTA 通道称为 MTA (mtaGroups)。

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


注 –

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


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

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
    ...

注释:

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

    等号后边的名称是受监视的 Messaging Server 实例的名称。在此示例中,实例名称是 mailsrv-1。

  2. 这些是 SNMP 时间戳值,也是事件发生时的 sysUpTime 的值。sysUpTime 是 SNMP 主代理启动后以百分之一秒为单位的计数。

  3. 通过已配置的 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 状态中没有此概念。

  4. 对于 HTTP、IMAP 和 POP 服务器,applRejectedInboundAssociations MIB 变量表示失败的登录尝试的数量,而不是被拒绝的入站连接尝试的数量。

applTable 的用法

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

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

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 用于枚举所报告的应用程序的每个连接。

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

  2. 这是一个 OID,表示网络连接所使用的协议。aplTCPProtoID 表示 TCP 协议。后缀 .n 表示使用的 TCP 端口,.25 表示基于 TCP 端口 25 使用的 SMTP 协议。

  3. 无法判断远程 SMTP 客户机是用户代理 (UA) 还是其他 MTA。因此,子代理始终报告 peer-initiator,而不报告 ua-initiator

  4. 这是 SNMP TimeInterval,单位为百分之一秒。在此示例中,连接已打开 4 秒钟。

assocTable 的用法

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

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 中的数据。

  1. 对于转换通道,仅使用非零值。

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

mtaTable 的用法

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

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

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 也用于 mtaGroupAssociationTablemtaGroupErrorTable 表。

  1. 所报告的通道的名称。在此示例中为 tcp_intranet 通道。

  2. 对于转换通道,仅使用非零值。

  3. 对当前存储在此通道的邮件队列中的 .HELD 邮件文件进行计数。

mtaGroupTable 的用法

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

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

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

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

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

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 用于枚举向通道打开的或来自通道的关联。

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

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
    ...         

注释:

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

mtaGroupErrorTable 的用法

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