Oracle Communications Messaging Server supports system monitoring through the Simple Network Management Protocol (SNMP). Using an SNMP client (sometimes called a network manager) such as Sun Net Manager or HP OpenView (not provided with the this product), you can monitor certain parts of the Messaging Server. For more information on monitoring the Messaging Server refer to "Monitoring Messaging Server."
This information describes how to enable SNMP support for the Messaging Server. It also gives an overview of the type of information provided by SNMP. Note that it does not describe how to view this information from an SNMP client. Refer to your SNMP client documentation for details on how to use it to view SNMP-based information.
This information also describes some of the data available from the Messaging Server SNMP implementation, but complete MIB details are available from RFC 2788 (
http://www.faqs.org/rfcs/rfc2788.html) and RFC 2789 (
Messaging Server implements two standardized MIBs, the Network Services Monitoring MIB (RFC 2788) and the Mail Monitoring MIB (RFC 2789). The Network Services Monitoring MIB provides for the monitoring of network services such as POP, IMAP, HTTP, and SMTP servers. The Mail Monitoring MIB provides for the monitoring of MTAs. The Mail Monitoring MIB allows for monitoring both the active and historical state of each MTA channel. The active information focuses on currently queued messages and open network connections (for example, counts of queued messages, source IP addresses of open network connections), while the historical information provides cumulative totals (for example, total messages processed, total inbound connections).
Note:For a complete listing of Messaging Server SNMP monitoring information, refer to RFC 2788 and RFC 2789.
SNMP is supported on platforms running Oracle Solaris and Linux. Messaging Server on the Oracle Solaris 9 Operating System uses Solstice Enterprise Agents (SEA). Starting with the Oracle Solaris 10 Operating System, Messaging Server supports the open source Net-SNMP monitoring framework, relegating the Oracle Solaris 9 Solstice Enterprise Agents (SEA) technology to legacy (end of support life) status. Additionally, Net-SNMP is widely used on Linux platforms. Messaging Server uses its Net-SNMP-based SNMP subagent on Oracle Solaris 10 and later as well as Linux platforms.
With the adoption of the Net-SNMP framework, Messaging Server's SNMP subagent provides new functionality:
Support for SNMP versions 2c and 3. This support is provided by the Net-SNMP framework. The former SNMP technology, Solstice Enterprise Agents, only provided support for SNMP version 1. Enhanced security features and access controls are the primary benefit of these two versions of SNMP.
The subagent may be configured to run as a "standalone" SNMP agent. This provides sites with additional means of isolating their various SNMP agents running on the same system.
Multiple "instances" of Messaging Server running on the same system may concurrently be monitored. This support is provided through either the second item in this list, or through the use of SNMP version 3 "context names". This allows for SNMP monitoring of Messaging Server in failover clusters.
Limitations of the Messaging Server SNMP support are as follows:
Only one instance of Messaging Server per host computer can be monitored via SNMP on Oracle Solaris 9.
The SNMP support is for monitoring only. No SNMP management is supported.
No SNMP traps are implemented. (RFC 2788 provides similar functionality without using traps.)
The Messaging Server SNMP process is an SNMP subagent which, upon startup, registers itself with the platform's native SNMP master agent. SNMP requests from clients go to the master agent. The master agent then forwards any requests destined for the Messaging Server to the Messaging Server subagent process. The Messaging Server subagent process then processes the request and relays the response back to the client via the master agent. This process is shown in the following figure.
Note:SNMP is not supported on Solaris 11. For a workaround, contact support.
By default, SNMP monitoring is disabled within Messaging Server. This default is chosen in an attempt to minimize the number of services presented by a default Messaging Server configuration. Do not interpret this default as meaning that there is a performance penalty incurred by using SNMP monitoring. Indeed, Messaging Server's SNMP support consumes very little resources and is intended to have minimal impact upon Messaging Server. The upshot of all of this is, of course, that one time configuration steps are required before using Messaging Server's SNMP support. Additionally, the default configuration of the platform's Net-SNMP master agent, snmpd, typically needs to be changed to run subagents such as Messaging Server's. This change is the topic of the next section.
Messaging Server's Net-SNMP based SNMP subagent uses the AgentX protocol to communicate with the platform's SNMP master agent (RFC 2741). The Net-SNMP master agent, snmpd, must be configured to permit the use of the AgentX protocol. To do this, ensure that the platform's snmpd.conf file contains the following line:
If that line is not present, then add it and then restart the snmpd daemon. Sending a SIGHUP signal to the daemon is not sufficient. Once the snmpd daemon has been restarted, look for the UNIX domain socket which snmpd creates for AgentX communications. On Oracle Solaris and Linux systems, this socket by default appears as the special file /var/agentx/master. However, its location and name may be changed in the snmpd.con file.
The Oracle Solaris 10 snmpd configuration is as follows:
% 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
Additionally, on Red Hat Enterprise Linux AS 3 systems, the default snmpd.conf file restricts the information which may be viewed by the "public" SNMP community. It is therefore necessary to either remove that restriction or to extend it to include the MIBs served out by Messaging Server's subagent. For initial testing, perform the later. This is accomplished by including the OID subtrees mib-2.27 and mib-2.28 in a view named "systemview" as shown in the following example. For actual deployment, each site must take their overall security policy into consideration. Note that the information provided by the SNMP subagent is "read only".
% 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 .184.108.40.206.2.1.27 view systemview included .220.127.116.11.2.1.28 ^D % /bin/service snmpd restart % ls -al /var/agentx/master srwxr-xr-x 1 root root 0 Aug 8 21:20 /var/agentx/master
If you are using SNMP v3 context names to distinguish between the MIBs of different instances of Messaging Server concurrently running on the same host computer, then you also need to configure at least one SNMP v3 username and password for use with your SNMP v3 queries.
For basic operation of Messaging Server's SNMP subagent, you need only enable it and issue a one time manual start command. Henceforth, whenever Messaging Server is started or stopped, the subagent will likewise be started or stopped. The necessary commands to effect this configuration on both Oracle Solaris and Linux systems are as follows:
% ./msconfig set snmp.enable 1 % ./start-msg snmp
Once SNMP is running, you can test the subagent from the command line with the snmpwalk command. See the screen shots below for an example appropriate to Oracle Solaris and Linux. Note that the files rfc2248.txt and rfc2249.txt are copies of the Network Services and MTA MIBs. On Oracle Solaris systems, these files may also be found in the /etc/sma/snmp/mibs/ directory under the names NETWORK-SERVICES-MIB.txt and MTA-MIB.txt. It is not necessary provide these files to the snmpwalk tool. However, doing so permits snmpwalk to print names for each of the MIB variables rather than their numeric object identifiers (OIDs).
Basic testing on Oracle Solaris:
% d=/opt/sun/comms/messaging64/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.example.com ... % D=/opt/sun/comms/messaging64/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 ...
Basic testing on 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.example.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 ...
Before configuring Messaging Server's SNMP subagent to run as a standalone SNMP agent, you must first decide which Ethernet interface and UDP port to use to listen for SNMP requests. By default, it listens on all available Ethernet interfaces by using UDP port 161. In most cases, you should change the port number so as to not interfere with the platform's SNMP master agent, snmpd. In some circumstances such as HA failover, you should change the Ethernet interface from all available interfaces - INADDR_ANY - to a specific interface identified by its IP address. These two concepts, Ethernet interface and UDP port, are controlled by the snmp.listenaddr and snmp.port options.
Once you have made choices for the Ethernet interface and UPD port, set the value of the snmp.standalone option to one and restart the subagent. Once restarted, it operates as an SNMP agent independent of snmpd and any subagents.
For example, to run as a standalone agent listening on UDP port 9161 of the Ethernet interface with IP address 10.53.1.37, issue the commands shown below.
Configuring to run as a standalone agent:
% ./msconfig set snmp.port 9161 % ./msconfig set snmp.listenaddr 10.53.1.37 % ./msconfig set snmp.standalone 1 % ./stop-msg snmp % ./start-msg snmp % ./snmpwalk -v 1 -c public 10.53.1.37:9161 . SNMPv2-SMI::mib-18.104.22.168.2.1 = STRING: "/opt/sun/comms/messaging64 MTA on mail.example.com" ...
Two techniques for monitoring multiple instances of Messaging Server running on the same host computer are herein discussed. The first technique, running the subagent in standalone mode, is well suited to high-availability failover (HA) configurations in which the individual instances of Messaging Server may dynamically move between host computers. The second technique, the use of SNMP v3 context names, has some limited benefit in situations where multiple instances of Messaging Server are confined to a single system and it is desirable to limit the number of IP addresses polled by SNMP monitoring software (for example, when licensing of the monitoring software has a per IP address cost component). This latter technique may also be used in HA failover settings but would require polling just as many IP addresses as the standalone mode technique.
In a high-availability failover setting where SNMP monitoring of Messaging Server is desired, it is recommended that you run Messaging Server's SNMP subagent as a standalone agent as described in "Running as a Standalone SNMP Agent." When the subagents are run in standalone mode, each HA instance of Messaging Server should have its snmp.listenaddr option set to the value of that instance's failover IP address. To simplify management, each instance should use the same UDP port, but that port should be distinct from those used by the snmpd daemons running on each of the physical cluster hosts. Typically those daemons will be using UDP port 161 so explicitly specify a different port number with the snmp.port option.
When Messaging Server's SNMP support is configured as recommended here, a monitoring station can monitor each instance of Messaging Server through its failover IP address or hostname regardless of which physical cluster host the instance is running on. Moreover, you are assured that Messaging Server's standalone SNMP agents do not conflict with one another as each listens only on its own virtual Ethernet interface identified by that instance's unique failover IP address. (These virtual Ethernet interfaces are automatically created by the HA failover framework.) Owing to the careful selection of a UDP port, the agents do not conflict with the snmpd daemons running on systems within the cluster.
While there is no downside to using Messaging Server's SNMP support in standalone mode as described in "Running as a Standalone SNMP Agent," it is recognized that some sites may prefer to use a more traditional subagent mode while still maintaining the capability of monitoring multiple instances of Messaging Server running concurrently on the same system. For instance, an SNMP monitoring system whose licensing model limits the number of IP addresses which may be polled. To achieve this goal, continue to run Messaging Server's SNMP subagent with snmp.standalone set to zero. Additionally, configure each instance of Messaging Server to use a distinct SNMP v3 context name by specifying a non-zero value for the snmp.enablecontextname option. If a context name different than the value of base.defaultdomain is desired, then set the desired name with the snmp.contextname option. Once each instance of Messaging Server's SNMP subagent is restarted, they can then be monitored with SNMP v3 queries that include the proper context names. The MIBs of two instances of Messaging Server running on the same system are distinguished by the instance's SNMP v3 context name and so no MIB object identifier (OID) conflicts will arise.
The following options apply only to Messaging Server's Net-SNMP based SNMP subagent. That subagent is used on Oracle Solaris platforms running Oracle Solaris 10 and later as well as Linux platforms. The options described in this section do not apply to the legacy SNMP subagent supplied for Oracle Solaris platforms running Oracle Solaris 9 and earlier operating systems.
The Messaging Server SNMP subagent only runs when this option is given a value of 1, in which case Messaging Server automatically stops and starts the subagent as part of its normal startup and shutdown procedures. By default this option is set to zero, which disables operation of the subagent. Before enabling the subagent, ensure that the platform's master agent has been properly configured as described in "Running as a Standalone SNMP Agent."
Messaging Server's SNMP support normally runs as a SNMP subagent, receiving SNMP requests through the platform's SNMP master agent, snmpd. This operational mode is the default and is selected by giving this option a value of 0. However, as described in "Running as a Standalone SNMP Agent," the subagent may run in a "standalone" mode whereby it operates as a SNMP agent independent of snmpd. When run in standalone mode, the subagent, now an SNMP agent, listens directly for SNMP requests on the Ethernet interface and UDP port specified by, respectively, the snmp.listenaddr and snmp.port options. To run in this standalone mode, specify a value of 1 for this option. Running in standalone mode does not interfere with other SNMP master or subagents running on the system.
Hostname or IP address of the Ethernet interface to listen for SNMP requests on when running in standalone mode. By default, all available interfaces are listened on. This corresponds to specifying the value INADDR_ANY. A specific interface may be selected by specifying either the IP address or hostname associated with that interface. The interface may be either a physical interface or a virtual interface. This option is ignored when snmp.standalone is set to 0.
Time to live (TTL) in seconds for cached monitoring data. This option controls how long the subagent will report the same monitoring data before refreshing that data with new information obtained from Messaging Server. With the exception of message loop information, data is cached for no longer than 30 seconds by default. Loop information, as determined by scanning for .HELD files, is updated only once every 10 minutes. That because of the resource cost of scanning all the on-disk message queues. Note that the subagent does not continually update its monitoring data: it is only updated upon receipt of an SNMP request and the cached data has expired (that is, outlived its TTL). If the TTL is set to 30 seconds and SNMP requests are made only every five minutes, then each SNMP request causes the subagent to obtain fresh data from Messaging Server. That is, data from Messaging Server is obtained only once every five minutes. If, on the other hand, SNMP requests are made every 10 seconds, then the subagent responds to some of those requests with cached data as old as 29 seconds. Messaging Server is polled only once every 30 seconds.
The subagent determines the operational status of each monitored service by actually opening TCP connections to each service and undergoing a protocol exchange. This timeout value, measured in seconds, controls how long the subagent waits for a response to each step in the protocol exchange. By default, a timeout value of five seconds is used.
Use this option to control whether or not the subagent performs scans of the on-disk message queues for .HELD message files and the oldest message files. That information corresponds to the mtaGroupLoopsDetected, mtaGroupOldestMessageStored, and mtaGroupOldestMessageId MIB variables. When this option has the value 1, then a cache of this information is maintained and updated as needed. Sites with thousands of queued messages, that are not interested in these particular MIB variables should consider setting this option's value to 0.
The subagent has the ability to register its MIBs under an SNMP v3 context name. When this is done, the MIBs may only be requested by a SNMP v3 client that specifies the context name in its SNMP request. Use of context names allows multiple, independent subagents to register Network Services and MTA MIBs under the same OID tree (that is, under the same SNMP master agent). See "Monitoring Multiple Instances of Messaging Server" for further information. To enable the use of SNMP v3 context names, specify a value of 1 for this option. When that is done, the subagent defaults to using the value of the base.defaultdomain option for its context name. To use a different value for the context name, use the snmp.contextname option.
When the use of SNMP v3 context names has been enabled with snmp.enablecontextname, this option can be used to explicitly set the context name used by the subagent for its MIBs. The values supplied for this option are string values and must be appropriate for use as a SNMP v3 context name. This option is ignored when snmp.enablecontextname has the value 0.
mib-2.27 = 22.214.171.124.2.1.27
mib-2.28 = 126.96.36.199.2.1.28
Point your SNMP client at those two OIDs and access as the "public" SNMP community.
To load copies of the MIBs into your SNMP client, ASCII copies of the MIBs are located in the MessagingServer_home/lib/config-templates directory under the file names rfc2788.mib and rfc2789.mib. For directions on loading those MIBs into your SNMP client software, consult the SNMP client software documentation. The SnmpAdminString data type used in those MIBs may not be recognized by some older SNMP clients. In that case, use the equivalent files rfc2248.mib and rfc2249.mib also found in the same directory.
This section summarizes the Messaging Server information provided via SNMP.
Topics in this section:
For detailed information refer to the individual MIB tables in RFC 2788 (
http://www.faqs.org/rfcs/rfc2788.html) and RFC 2789 (
http://www.faqs.org/rfcs/rfc2789.html). Note that the RFC/MIB terminology refers to the messaging services (MTA, HTTP, and so on) as applications (appl), Messaging Server network connections as associations (assoc), and MTA channels as MTAgroups (mtaGroups).
On platforms where more than one instance of Messaging Server may be concurrently monitored, there may then be multiple sets of MTAs and servers in the applTable, and multiple MTAs in the other tables.
Note:The cumulative values reported in the MIBs (for example, total messages delivered, total IMAP connections, and so on) are reset to zero after a reboot.
Each site has different thresholds and significant monitoring values. A good SNMP client allows you to do trend analysis and then send alerts when sudden deviations from historical trends occur.
The applTable provides server information. It is a one-dimensional table with one row for the MTA and an additional row for each of the following servers, if enabled: WebMail HTTP, IMAP, POP, SMTP, and SMTP Submit. This table provides version information, uptime, current operational status (up, down, congested), number of current connections, total accumulated connections, and other related data.
Here is an example of data from applTable (mib-188.8.131.52).
applTable: applName.1 = mailsrv-1 MTA on mailsrv-1.west.example.org (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.example.org (1) ... applName.3 = mailsrv-1 IMAP server on mailsrv-1.west.example.org ... applName.4 = mailsrv-1 POP server on mailsrv-1.west.example.org ... applName.5 = mailsrv-1 SMTP server on mailsrv-1.west.example.org ... applName.6 = mailsrv-1 SMTP Submit server on mailsrv-1.west.example.org ...
The application (.appl*) suffixes (.1, .2, and so on) are the row numbers, applIndex. applIndex has the value 1 for the MTA, value 2 for the HTTP server, and so on. Thus, in this example, the first row of the table provides data on the MTA, the second on the POP server, and so on. The name after the equal sign is the name of the Messaging Server instance being monitored. In this example, the instance name is mailsrv-1.
These are SNMP TimeStamp values and are the value of sysUpTime at the time of the event. sysUpTime, in turn, is the count of hundredths of seconds since the SNMP master agent was started.
The operational status of the HTTP, IMAP, POP, SMTP, and SMTP Submit servers is determined by actually connecting to them by their configured TCP ports and performing a simple operation using the appropriate protocol (for example, a HEAD request and response for HTTP, a HELO command and response for SMTP, and so on). From this connection attempt, the status-up (1), down (2), or congested (4)-of each server is determined. Note that these probes appear as normal inbound connections to the servers and contribute to the value of the applAccumulatedInboundAssociations MIB variable for each server. For the MTA, the operational status is taken to be that of the Job Controller. If the MTA is shown to be up, then the Job Controller is up. If the MTA is shown to be down, then the Job Controller is down. This MTA operational status is independent of the status of the MTA's Service Dispatcher. The operational status for the MTA only takes on the value of up or down. Although the Job Controller does have a concept of "congested," it is not indicated in the MTA status.
For the HTTP, IMAP, and POP servers the applRejectedInboundAssociations MIB variable indicates the number of failed login attempts and not the number of rejected inbound connection attempts.
Monitoring server status (applOperStatus) for each of the listed applications is key to monitoring each server.
If it has been a long time since the MTA last inbound activity as indicated by applLastInboundActivity, then something may be broken preventing connections. If applOperStatus=2 (down), then the monitored service is down. If applOperStatus=1 (up), then the problem may be elsewhere.
This table provides network connection information to the MTA. It is a two-dimensional table providing information about each active network connection. Connection information is not provided for other servers. Here is an example of data from applTable (mib-184.108.40.206).
assocTable: assocRemoteApplication.1.1 = 220.127.116.11 (1) assocApplicationProtocol.1.1 = applTCPProtoID.25 (2) assocApplicationType.1.1 = peerinitiator(3) (3) assocDuration.1.1 = 400 (4) ...
Notes: In the .x.y suffix (1.1), x is the application index, applIndex, and indicates which application in the applTable is being reported on. In this case, the MTA. The y serves to enumerate each of the connections for the application being reported on.
The source IP address of the remote SMTP client.
This is an OID indicating the protocol being used over the network connection. aplTCPProtoID indicates the TCP protocol. The .n suffix indicates the TCP port in use and .25 indicates SMTP which is the protocol spoken over TCP port 25.
It is not possible to know if the remote SMTP client is a user agent (UA) or another MTA. As such, the subagent always reports peer-initiator; ua-initiator is never reported.
This is an SNMP TimeInterval and has units of hundredths of seconds. In this example, the connection has been open for 4 seconds.
This table is used to diagnose active problems. For example, if you suddenly have 200,000 inbound connections, this table can let you know where they are coming from.
This is a one-dimensional table with one row for each MTA in the applTable. Each row gives totals across all channels (referred to as groups) in that MTA for select variables from the mtaGroupTable. Here is an example of data from applTable (mib-18.104.22.168).
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)
Notes: The .x suffix (.1) provides the row number for this application in the applTable. In this example, .1 indicates this data is for the first application in the applTable. Thus, this is data on the MTA.
Only takes on non-zero values for the conversion channel.
Counts the number of .HELD message files currently stored in the MTA's message queues.
If mtaLoopsDetected is not zero, then there is a looping mail problem. Locate and diagnose the .HELD files in the MTA queue to resolve the problem.
If the system does virus scanning with a conversion channel and rejects infected messages, then mtaSuccessfulConvertedMessages gives a count of infected messages in addition to other conversion failures.
This two-dimensional table provides channel information for each MTA in the applTable. This information includes such data as counts of stored (that is, queued) and delivered mail messages. Monitoring the count of stored messages, mtaGroupStoredMessages, for each channel is critical. When the value becomes abnormally large, mail is backing up in your queues.
Here is an example of data from mtaGroupTable (mib-22.214.171.124).
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
Notes: In the .x.y suffix (example: 1.1, 1.2. 1.3), x is the application index, applIndex, and indicates which application in the applTable is being reported on. In this case, the MTA. The y serves to enumerate each of the channels in the MTA. This enumeration index, mtaGroupIndex, is also used in the mtaGroupAssociationTable and mtaGroupErrorTable tables.
The name of the channel being reported on. In this case, the tcp_intranet channel.
Only takes on non-zero values for the conversion channel.
Counts the number of .HELD message files currently stored in this channel's message queue.
Trend analysis on Rejected and Failed might be useful in determining potential channel problems.
A sudden jump in the ratio of mtaGroupStoredVolume to mtaGroupStoredMessages could mean that a large junk mail is bouncing around the queues.
A large jump in mtaGroupStoredMessages could indicate unsolicited bulk email is being sent or that delivery is failing for some reason.
If the value of mtaGroupOldestMessageStored is greater than the value used for the undeliverable message notification times (notices channel option) this may indicate a message which cannot be processed even by bounce processing. Note that bounces are done nightly so you want to use mtaGroupOldestMessageStored > (maximum age + 24 hours) as the test.
If mtaGroupLoopsDetected is greater than 0, a mail loop has been detected.
This is a three-dimensional table whose entries are indices into the assocTable. For each MTA in the applTable, there is a two-dimensional sub-table. This two-dimensional sub-table has a row for each channel in the corresponding MTA. For each channel, there is an entry for each active network connection which that channel has currently underway. The value of the entry is the index into the assocTable (as indexed by the entry's value and the applIndex index of the MTA being looked at). This indicated entry in the assocTable is a network connection held by the channel.
In simple terms, the mtaGroupAssociationTable table correlates the network connections shown in the assocTable with the responsible channels in the mtaGroupTable.
Here is an example of data from mtaGroupAssociationTable (mib-126.96.36.199).
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
Notes: In the .x.y.z suffix, x is the application index, applIndex, and indicates which application in the applTable is being reported on. In this case, the MTA. The y indicates which channel of the mtaGroupTable is being reported on. In this example, 3 indicates the tcp_local channel. The z serves to enumerate the associations open to or from the channel.
The value here is an index into the assocTable. Specifically, x and this value become, respectively, the values of the applIndex and assocIndex indices into the assocTable. Or, put differently, this is saying that (ignoring the applIndex) the first row of the assocTable describes a network connection controlled by the tcp_local channel.
This is another three-dimensional table which gives the counts of temporary and permanent errors encountered by each channel of each MTA while attempting delivery of messages. Entries with index values of 4000000 are temporary errors while those with indices of 5000000 are permanent errors. Temporary errors result in the message being re-queued for later delivery attempts. Permanent errors result in either the message being rejected or otherwise returned as undeliverable.
Here is an example of data from mtaGroupErrorTable (mib-188.8.131.52).
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 ...
In the .x.y.z suffix, x is the application index, applIndex, and indicates which application in the applTable is being reported on. In this case, the MTA. The y indicates which channel of the mtaGroupTable is being reported on. In this example, 1 specifies the tcp_intranet channel, 2 the ims-ms channel, and 3 the tcp_local channel. Finally, the z is either 4000000 or 5000000 and indicates, respectively, counts of temporary and permanent errors encountered while attempting message deliveries for that channel.
A large jump in error count may likely indicate an abnormal delivery problem. For instance, a large jump for a tcp_ channel may indicate a DNS or network problem. A large jump for the ims-ms channel may indicate a delivery problem to the message store (for example, a partition is full, stored problem, and so on).