| Sun ONE Application Server 7 Administrator's Guide |
Chapter 6
Monitoring the Sun ONE Application ServerThis chapter contains information about the monitoring and Simple Network Management Protocol (SNMP) features and functions available in the Sun ONE Application Server.
This chapter includes the following sections:
About Monitoring the Sun ONE Application ServerYou can monitor the Sun ONE Application Server by collecting activity statistics from strategic data points on your system. The statistics show you how many requests your server is handling and how well it is handling those requests. You can view some statistics for individual virtual servers and others for the entire application server instance. Either the asadmin utility or SNMP can be used to monitor the Sun ONE Application Server.
The following topics are addressed in this section:
Statistics
Statistics collection is always enabled for most of the Sun ONE Application Server application components and subsystems, including the HTTP server; no enabling functions are required. However, there are some statistics that are collected only when monitoring is explicitly enabled on that subsystem, or only when relevant functionality is enabled. These statistics include the following data points:
Monitoring can be enabled for application subsystems or components from the Administration interface, as described in "Application Components and Subsystems Monitoring".
If the server monitor reports that the server is handling a large number of requests, you may need to adjust the server configuration or the system’s network kernel. For more information on adjusting your server’s configuration, see the Sun ONE Application Server Performance Tuning and Sizing Guide.
SNMP
The Sun ONE Application Server provides network management information through its information gathering tools using Simple Network Management Protocol (SNMP), a protocol used to exchange management and monitoring information across a network. Using SNMP, programs called agents monitor various devices on the network (hubs, routers, bridges, and so on). Another program collects the data from the agents. The database created by the monitoring operations is called a management information base (MIB).This data is used to check if all devices on the network are operating properly.
While only the HTTP server can be monitored using SNMP; all components and systems can be monitored using the command-line interface (CLI)
For more information on SNMP, see "About SNMP" and "Setting Up SNMP".
HTTP Server Monitoring
HTTP server monitoring is enabled by default, which means it doesn’t need to be specifically turned on. HTTP server monitoring is based on an XML file and is accessed using the asadmin command as a set of three monitorable attributes. The elements, subelements, and the attributes of this XML file are described in "Monitorable HTTP Server Elements" and "Monitorable HTTP Server Attributes".
For more information about using asadmin, see "Using the Command Line Interface".
Application Components and Subsystems Monitoring
Some of the subsystems or components within the Sun ONE Application Server do not need to have monitoring enabled because the relevant statistics are always collected. For example, monitoring for application components such as containers can be enabled or disabled. When monitoring is enabled, in addition to the statistics that are always collected, additional statistics on all EJB methods are also collected. Monitoring for JDBC connection pools is always enabled. A connection pool is initialized upon first access and relevant statistics can be monitored anytime after that.
For a full list of monitorable data points, see "Monitorable Attribute Names".
You can enable monitoring for selected application components and subsystems from the Administration interface or from the command-line interface (CLI). For example, to enable monitoring from the CLI for the EJB container, type the following command from a terminal window:
where server1 is the instance name.
The equivalent functionality can be accessed on the Administration interface under the Containers node.
The following topics are addressed in this section:
Monitoring for Container Subsystems
In the case of the EJB container, when monitoring is enabled, the statistics related to the methods for all entity beans, stateful session beans, and stateless session beans are collected. These statistics include:
All other statistics for container subsystems are always collected. Some of the monitored data points include statistics relative to:
Monitoring for the ORB Service
For the ORB service, monitored data points include statistics gathered for the ORB connection and the ORB thread pool. ORB statistics are always collected and, therefore, it is not necessary to enable monitoring for the ORB service.
Monitoring for the Transaction Service
For the Java Transaction Service (JTS) service, monitored data points include:
Refer to "Administering the Transaction Service Using the CLI" for further information.
Quality of Service (QOS)
Quality of Service refers to the performance limits you set for a server instance virtual server class or virtual server. For example, if you are an Internet Service Provider (ISP), you might want to charge different fees for virtual servers depending on how much bandwidth is provided. You can limit two areas: the amount of bandwidth and the number of connections.
The Quality of Service information provided by the Sun ONE Application Server is used to determine server efficiency during runtime with respect to:
For more information, see "Administering the Transaction Service Using the CLI".
Extracting Monitoring Data Using the CLIWith the asadmin command, you can extract monitored data through the command-line interface (CLI) using the list and get commands.
Note
The set command is only used to set monitoring for the transaction service as described in "Administering the Transaction Service Using the CLI".
This section addresses the following topics:
The list --monitor Command
The list command provides information about the application components and subsystems currently being monitored for the specified server instance name. Using this command, you can see the monitorable components and sub-components for a server instance.
Example
asadmin> list --monitor server1
returns the following list of application components and subsystems that have monitoring enabled:
iiop-service
transaction-service
application.converter
application.myApp
http-serverYou can also list applications that are currently monitored in the specified server instance. This can be useful when particular monitoring statistics are sought from an application using the get command.
Example
asadmin> list --monitor server1.application
returns:
converter
myAppFor a more comprehensive example, see "Petstore Example".
The get --monitor Command
This command retrieves the following monitored information:
When an attribute is requested that does not exist for a particular component or subsystem, an error is returned. Similarly, when a specific attribute is requested that is not active for a component or subsystem, an error is returned.
Refer to "CLI Name Mapping" for more information on the use of the get command.
Example 1
Attempt to get all attributes from a subsystem for a specific attribute:
asadmin> get --monitor server1.iiop-service.orb.system.orb-connection.*
total-inbound-connections=1
total-outbound-connections=1Example 2
Attempt to get all attributes from a J2EE application:
asadmin> get --monitor server1.application.converter.*
Attribute name(s) not found
There are no monitorable attributes exposed at the J2EE-application level, therefore the command fails.
Example 3
Attempt to get a specific attribute from a subsystem:
asadmin> get --monitor server1.transaction-service.inflight-tx
Attribute name = inflight-tx Value = No active transaction found.
Example 4
Attempt to get an unknown attribute from within a subsystem attribute:
asadmin> get --monitor server1.iiop-service.orb.system.orb-connection.bad-name
Could not get the attribute
Execution failed for the command: get --monitor server1.iiop-service.orb-connection.bad-name
CLI Name Mapping
The Sun ONE Application Server uses a tree structure to track monitorable objects. Every node in the tree has a name and a type. If a type is singleton, only a single node of the type can exist under any parent node. For more information on type of nodes in this tree, see "Monitorable Object Types".
The root object in the tree is represented by the Sun ONE Application Server instance name. For example, the root monitoring object for an instance named server1 is:
All child objects are then addressed using the dot (.) character as separator. If a child node is of singleton type, then only the monitoring object type is needed to address the object, otherwise a name of the form type.name is needed to address the object.
For example, http-server is one of the valid monitorable object types and is singleton. To address a singleton child node representing the http-server of instance server1, the name is:
Another example, application, is a valid monitorable object type and is not a singleton. To address a non-singleton child node representing the application Petstore, the name is:
The CLI names can also address specific attributes in monitorable objects. For example, http-server has a monitorable attribute called summary. The following name addresses the summary attribute:
There is no fixed naming convention for attribute names exposed by monitoring objects.
You are not expected to know the valid names for CLI use. The list command lets you inspect available monitorable objects, while the get command used with a wildcard parameter allows you to inspect all available attributes on any monitorable object.
The following example illustrate some client name mapping scenarios:
Petstore Example
A user wants to inspect the number of calls made to a method in the Petstore application deployed on the Sun ONE Application Server instance named server1. A combination of the list and get commands is used to access desired statistics on a method.
- Invoke the CLI in multi-mode.
- Set some useful environment variables to avoid entering them for every command:
asadmin>export AS_ADMIN_USER=admin AS_ADMIN_PASSWORD=admin123
asadmin>export AS_ADMIN_HOST=localhost AS_ADMIN_PORT=4848
- List monitorable components for instance server1:
asadmin>list --monitor server1
Output is:
iiop-service
transaction-service
application.CometEJB
application.ConverterApp
application.petstore
http-server
resourcesThe list of monitorable components includes iiop-service, http-server, transaction-service, resources, and all deployed (and enabled) applications.
- List the monitorable subcomponents in the Petstore application (-m can be used instead of --monitor):
asadmin>list -m server1.application.petstore
Output is:
ejb-module.signon-ejb_jar
ejb-module.catalog-ejb_jar
ejb-module.uidgen-ejb_jar
ejb-module.customer-ejb_jar
ejb-module.petstore-ejb_jar
ejb-module.AsyncSenderJAR_jar
ejb-module.cart-ejb_jar- List the monitorable subcomponents in the EJB module sigon-ejb_jar of the Petstore application:
asadmin>list -m server1.application.petstore.ejb-module.signon-ejb_jar
Output is:
entity-bean.UserEJB
stateless-session-bean.SignOnEJB- List the monitorable subcomponents in the entity bean UserEJB for the EJB module sigon-ejb_jar of the Petstore application:
asadmin>list -m server1.application.petstore.ejb-module.signon-ejb_jar.entity-bean.UserEJB
Output is:
bean-method.create0
bean-method.findByPrimaryKey1
bean-method.remove2
bean-method.getUserName3
bean-method.setPassword4
bean-method.getPassword5
bean-method.matchPassword6
bean-method.remove7
bean-method.isIdentical8
bean-method.getEJBLocalHome9
bean-method.getPrimaryKey10
bean-pool
bean-cache- List the monitorable subcomponents in the method getUserName3 for the entity bean UserEJB in the EJB module sigon-ejb_jar of the Petstore application:
asadmin>list -m server1.application.petstore.ejb-module.signon-ejb_jar.entity-bean.UserEJB.bean-m ethod.getUserName3
Output is:
No monitorable entities for element
server1.application.petstore.ejb-module.signon-ejb_jar.entity-bean.UserEJB.bean-m ethod.getUserName3- There are no monitorable subcomponents for methods. Get all monitorable statistics for the method getUserName3.
asadmin>get -m server1.application.petstore.ejb-module. signon-ejb_jar.entity-bean.UserEJB.bean-method.getUserName3.*
method-name = public abstract java.lang.String com.sun.j2ee.blueprints.signon.user.ejb.UserLocal.getUserName()
total-num-errors = 0
total-num-success = 2
execution-time-millis = 1
total-num-calls = 2- You can also get a specific statistic, such as execution time.
asadmin>get -m server1.application.petstore.ejb-module. signon-ejb_jar.entity-bean.UserEJB.bean-method.getUserName3.execution-time-millis
execution-time-millis = 1Monitorable Object Types
The tree of objects used for monitoring contains several nodes. A node is a specific entry in the object tree, and is identified uniquely by its type, name, and parent node. Some of the node types are singleton, meaning that only one node of the type can exist under a parent node. A name is not relevant for a singleton node.
A non-singleton type node needs a name. The Instance Name column describes the possible namespace.
The following table describes the tree structure in terms of possible parent-child relationships among various node types and the namespaces for some of the node types.
Monitorable Attribute Names
It is not necessary for every monitorable object to expose monitorable attributes. Some of the objects are used just for grouping other objects. For the Sun ONE Application Server, except for an http-server node, only the leaf nodes of the tree have attributes. The http-server node type has attributes as well as child nodes. The following tables list possible monitorable attribute names for various nodes.
Table 6-2 http-server
Attribute Name
Datatype
Description
summary
String (Formatted)
HTTP server summary. Includes virtual servers and processes.
NOTE: See section "HTTP Server Monitorable Objects" for more information on what data is exposed in the formatted string.
Table 6-3 virtual-server
Attribute Name
Datatype
Description
<vs-id>
String (Formatted)
Virtual server information. For every application server instance there can be one or more virtual servers. The list of virtual server IDs can be obtained from the summary attribute of http-server. You can look up statistics for a specific virtual server using the get command parameter of the form server1.http-server.virtual-server.<vs-id>. You can look up statistics for all virtual servers using the get command parameter of the form server1.http-server.virtual-server.*.
NOTE: See section "HTTP Server Monitorable Objects" for more information on what data is exposed in the formatted string.
Table 6-4 process
Attribute Name
Datatype
Description
<pid>
String (Formatted)
Process information. For every application server instance there is one process. The process ID can be obtained from the summary attribute of http-server. Statistics for a process can be obtained using the parameter of the form server1.http-server.process.<pid> to the get command.
NOTE: See section "HTTP Server Monitorable Objects" for more information on what data is exposed in the formatted string.
HTTP Server Monitorable Objects
The HTTP server monitorable attribute name summary prints the attribute values of the Server element and a summary of its subelements, including the number of each subelement and attribute values for each subelement. The HTTP server virtual-server attribute prints the attribute values of the VirtualServer element and the details of each of its subelements.The process attribute prints the attribute values of the Process element and the details of each of its subelements.
To enable NSAPI performance profiling and obtain statistics on the Profile and ProfileBucket elements, see the Sun ONE Application Server Developer's Guide to NSAPI.
For information on how to use the monitoring statistics for performance tuning, see the Sun ONE Application Server Performance and Tuning Guide.
Monitorable HTTP Server Elements
The following table lists the HTTP server monitorable elements.
Monitorable HTTP Server Attributes
The following tables list the HTTP server monitorable attributes.
Table 6-15 ThreadPool
Attribute Name
Values
Description
Id
The thread pool ID.
Name
The symbolic name of the thread pool.
Administering the Transaction Service Using the CLIYou can use the set command to administer the statistics you want to monitor for the JTS.
Example 1
To add a transaction to a rollback list (which results in rollback or specified transaction), issue the set command as follows:
set --monitor server1.transaction-service.rollback-list=txnid1
Example 2
To freeze the transaction service, issue the set command as follows:
set --monitor server1.transaction-service.freeze=true
The following table describes the attributes that can be monitored to gather statistics for the JTS. These attributes can be set from the command line according to the rules described in "CLI Name Mapping".
For more information on the java transaction service, refer to Chapter 9, "Using Transaction Services."
Using HTTP Quality of ServiceThe following settings govern how traffic is counted and how often the bandwidth is recomputed:
In the Administration interface, you can enable these server or class-level settings for the server instance or for a class of virtual servers. However, you can override them for an individual virtual server.
This section includes the following topics:
Quality of Service Example
The following example shows how the Quality of Service information is collected and computed.
- The server has metric interval of 30 seconds.
- The server starts up at a time of 0 seconds.
- At 1 second, an HTTP connection generates 5000 bytes of traffic to/from the server.
- No more connections are made after that. At 30 seconds, the total traffic for the last 30 seconds is 5000 bytes.
- At 32 seconds, the traffic sample from 1 second is discarded, since it is older than the 30 seconds of the metric interval. The total traffic for the last 30 seconds is now 0.
The recompute interval works similarly. The server’s recompute interval is 100ms.
Continuing with the example, the bandwidth is recomputed periodically every 100 milliseconds. The calculation is based on the amount of traffic as well as the metric interval.
- At 0 seconds, the bandwidth is calculated for the first time. The total traffic is zero, divided by the metric interval of 30 seconds, giving a bandwidth of zero.
- At 1 second, the bandwidth is calculated for the 10th time (1000 milliseconds/ 100 milliseconds). The total traffic is 5000 bytes, which is divided by 30 seconds. The bandwidth is 5000/30 = 166 bytes per second.
- At 30 seconds, the bandwidth is calculated for the 300th time. The total traffic is 5000 bytes, which is divided by 30 seconds. The bandwidth is 5000/30 = 166 bytes per second.
- At 32 seconds, the bandwidth is computed again for the 320th time. The traffic is now 0 (since the one connection that generated traffic is too old to be counted), divided by 30, giving a bandwidth of 0 bytes/second.
Configuring Quality of Service (QOS)
Quality of Service for a server instance or a class of virtual servers is configured through the Administration interface.
Note
To enforce your Quality of Service settings, you must also set up Server Application Functions (SAFs) in the obj.conf file as described in "Required Changes to the obj.conf File".
To configure Quality of Service, follow these steps:
Figure 6-1 Virtual Server Instance QOS Tab
- To enable Quality of Service for this HTTP Server, click QOS Enable.
Note: By default, Quality of Service is disabled. Enabling Quality of Service slightly increases server overhead.
- Specify the QOS Metrics Interval.
The metrics interval is the time period, in seconds, that data is sampled during server traffic calculations. The default value is 30 seconds.
If your site commonly has large file transfers, use a large value (several minutes or more) for this field. A large file transfer might take up all the allowed bandwidth for a short metric interval, and result in connections being denied if you’ve enforced the maximum bandwidth setting. Since the bandwidth is averaged by the metric interval, a longer interval smooths out spikes caused by large files.
If the bandwidth limit is much lower than available bandwidth (for example, 1 MB-per-second bandwidth limit but with a 1 GB-per-second connection to the backbone), the metric interval should be shortened.
Note: If you have large static file transfers and a bandwidth limit that is much lower than the available bandwidth, you must decide which situation to tune for, since the problems require opposite solutions.
- Specify the QOS Recompute Time Interval.
The recompute time interval is the number of milliseconds between each computation of the bandwidth for all servers, classes, and virtual servers. The default is 100 milliseconds.
- Specify the Bandwidth Limit.
This is the maximum bandwidth limit for the server instance in bytes per second. It is interdependent with the QOS Metrics Interval to some extent.
- Choose whether or not to enforce the maximum bandwidth setting.
If you choose to enforce the maximum bandwidth, when the server reaches its bandwidth limit, additional connections are refused.
If you do not enforce the maximum bandwidth, when the maximum is exceeded, the server logs a message to the event log.
- Specify the connection limit.
This is the number of concurrent requests processed.
- Choose whether or not to enforce the connection limit setting.
If you choose to enforce the maximum connections, when the server reaches its limit, additional connections are refused. If you do not enforce the maximum connections, when the maximum is exceeded, the server logs a message to the event log.
- (Optional). If specifying additional name-value pair attributes for Quality of Service, click the Properties button.
For a list of allowed name-value pairs for Quality of Service properties, refer to the online help.
- Click Save to commit the changes to the server instance.
- Access App Server Instances and your server instance in the left pane, then click Apply Changes.
Required Changes to the obj.conf File
To enforce Quality of Service, you must include directives in your obj.conf file to invoke following Server Application Functions (SAFs):
In order to work properly, the qos-handler AuthTrans directive must be the first AuthTrans configured in the default object. The role of the Quality of Service handler is to examine the current statistics for the virtual server, virtual server class, and global server, and to enforce the limits by returning an error. The Sun ONE Application Server includes a built-in sample Quality of Service handler SAF, called qos-handler. This SAF logs when limits are reached, and returns a 503 Server busy error to the server so that it can be processed by the NSAPI.
The Sun ONE Application Server also includes a built-in sample error SAF called qos-error which returns an error page stating which limits caused the 503 error and the value of the statistic that triggered the limit.
For more information on these SAFs and how to use them, see the Sun ONE Application Server Developer’s Guide to NSAPI.
Known Limitations to Quality of Service
When you use the Quality of Service features, keep in mind the following limitations:
- The Quality of Service features only measure the HTTP bandwidth at the application level. The HTTP bandwidth can differ from the actual TCP network bandwidth for a variety of reasons:
- The Quality of Service features cannot accurately measure traffic from PR_TransmitFile calls. For basic I/O operations such as PR_Send()/net_write or PR_Recv()/net_read, the data transferred can be quickly accounted for by the bandwidth manager, since the number of bytes transferred in one system call is usually the size of a buffer and the I/O call returns quickly. This works very well to measure the instantaneous bandwidth of dynamic content applications. However, because the amount of data transferred from PR_TransmitFile is only known at the end of the transfer, it can’t be measured before it completes.
If the PR_TransmitFile is short, then the Quality of Service features will perform adequately. However, If the PR_TransmitFile is long, as in the case of a long file downloaded by a dialup user, the whole amount of data transferred will be counted at completion time. When the bandwidth manager recomputes bandwidth after the next recompute interval period starts, the bandwidth computed will increase significantly because of that recent large PR_TransmitFile. This case could cause the server to deny all requests until the next metric interval, when the bandwidth manager will "expire" the transmit file operation (since it is too old) and thus the bandwidth value will go back down. If your site commonly has very long static file downloads, you should increase the metric interval from the default 30 seconds.
- The bandwidth computed is always an approximation because it is not measured instantaneously, but is recomputed at regular intervals and over a certain period. For example, if the metric interval is the default 30 seconds and the server is idle for 29 seconds, then the next second, a client could potentially use 30 times the bandwidth limit in one second.
- The Quality of Service bandwidth statistics are lost whenever the server is reconfigured dynamically. In addition, the Quality of Service limitations are not enforced in threads that have connections on an older, inactive configuration, because the bandwidth manager thread only computes bandwidth statistics for the active configuration. Potentially, a client that doesn’t close its socket for a long time and remains active so that the server doesn’t time it out would not be subject to the Quality of Service limitations after a dynamic server reconfiguration.
- The concurrent connections are computed with a different granularity for virtual servers than for virtual server classes and the global server instance. The connection counter for an individual virtual server is incremented atomically immediately after the request is parsed and routed to the virtual server. It is also decremented atomically at the end of the response processing for that request. This means that the virtual server connection statistics are always exact at any instant.
However, the connection statistics for the virtual server class and global server instance are not updated instantly. They are updated by the bandwidth manager thread every recompute interval. The connection count for the virtual server class is the sum of the connections on all virtual servers of that class; and the global server instance connection count is the sum of connections on all virtual server classes.
Because of the way these values are computed, the number of connections for a virtual server is always correct, and if you’ve enforced a limit to the number of connections, you can never have more than the limit. The virtual server class and server instance values are not quite as accurate, since they are only computed at intervals.
About SNMPSimple Network Management Protocol (SNMP) is a protocol used to exchange management and monitoring information across a network. With SNMP, data travels between a managed device and a network management station (NMS). A managed device is anything that runs SNMP: hosts, routers, your HTTP server, and other servers on your network.
This section addresses the following topics:
Network Management Station (NMS)
The network management station (NMS) is a machine used to remotely manage a specific network. Usually, the NMS software will provide a graph to display collected data or use that data to make sure the server is operating within a particular tolerance.
The NMS is usually a powerful workstation with one or more network management applications installed. A network management application such as HP OpenView graphically shows information about managed devices, such as your HTTP servers. For example, it might show which servers in your enterprise are up or down, or the number and type of error messages received. When you use SNMP with the Sun ONE Application Server, this information is transferred between the NMS and the server through the use of two types of agents: the subagent and the master agent.
The subagent gathers information about the server instances running in various domains and passes the information to the master agent. There is a master agent and a subagent for every installation of the Sun ONE Application Server.
Note
After making any SNMP configuration changes, you must click the Apply button, then restart the SNMP subagent.
The master agent exchanges information between the various subagents and the NMS. The master agent is installed with the Sun ONE Application Server.
You can have multiple subagents installed on a host computer, but only one master agent. For example, if you had Sun ONE Directory Server, Sun ONE Application Server, and the Sun ONE Messaging Server installed on the same host, the subagents for each of the servers would communicate with the same master agent.
The NMS either requests information from the server or changes the value of a variable store in the server’s MIB. For example:
- The NMS sends a message to the Admin Server master agent. The message might be a request for data (a GET message), or an instruction to set a variable in the MIB (a SET message).
- The master agent forwards the message to the appropriate subagent.
- The subagent retrieves the data or changes the variable in the MIB.
- The subagent reports data or status to the master agent, then the master agent forwards the message back (a GET message) to the NMS.
- The NMS displays the data textually or graphically through its network management application.
Management Information Base (MIB) Objects
The Sun ONE Application Server stores variables pertaining to managing and monitoring information across a network. Variables the master agent can access are called managed objects. These objects are defined in a tree-like structure called the management information base (MIB). The MIB provides access to the HTTP server’s network configuration, status, and statistics. Using SNMP, you can view this information from the network management workstation (NMS).
The top level of the MIB tree shows that the internet object identifier has the following subtrees:
The private (4) subtree contains the enterprises (1) node. Each subtree in the enterprises (1) node is assigned to an individual enterprise, which is an organization that has registered its own specific MIB extensions. An enterprise can then create product-specific subtrees under its subtree. MIBs created by companies are located under the enterprises (1) node.
Each Sun ONE Application Server subagent provides a MIB for use in SNMP communication. The server reports significant events to the NMS by sending messages or traps containing these variables. The NMS can query the server's MIB for data.
Each Sun ONE Application Server has its own MIB located at install_dir/lib
The Sun ONE Application Server’s MIB is a file called appserv.mib. This MIB contains the definitions for various variables pertaining to network management for the Sun ONE Application Server.
The Sun ONE Application Server MIB has an object identifier of
appserver 1 (as appserver7 OBJECT IDENTIFIER ::= {appserver 1 }) and is located in the install_dir/lib directory.
You can see administrative information about your Sun ONE Application Server and monitor the server in real time using the Sun ONE Application Server MIB. The following table lists and describes the managed objects stored in the appserv.mib file.
SNMP Messages
GET and SET are two types of messages defined by SNMP.
Each object is assigned a unique identifier within the MIB. Objects are accessed by the SNMP Manager by issuing GET and GETNEXT commands which specify the object's unique identifier. The Proxy Agent obtains the value of the specified object and transmits it to the SNMP manager. Events added to the log may generate SNMP traps provided they satisfy trap filter conditions. Events that do not generate traps are merely recorded as an entry in the maintenance log table and are accessed by the SNMP Manager through normal GET and GETNEXT commands.
GET and SET messages are sent by a network management station (NMS) to a master agent. You can use one or the other, or both, through the Administration interface.
SNMP exchanges network information in the form of protocol data units (PDUs). These units contain information about variables stored on the managed device, such as the HTTP server. These variables, also known as managed objects, have values and titles that are reported to the NMS as necessary. Protocol data units sent by the server to the NMS are known as traps. The use of GET, SET, and trap messages are explained further in the following sections.
SNMP Trap Destinations
An SNMP trap is a message the SNMP agent sends to a network management station (NMS). For example, an SNMP agent sends a trap when the status of an interface has changed from up to down. The SNMP agent must know the address of the NMS so it knows where to send traps.
You can configure this trap destination for the SNMP master agent from the Sun ONE Application Server Administration interface. You can also view, edit, and remove the trap destinations you have already configured. When you configure trap destinations using the Administration interface, you are actually editing the CONFIG file.
The server subagent sends a message or trap to the NMS when a significant event has occurred. For example:
Refer to "Installing the SNMP Master Agent" for instructions on setting up the SNMP trap port.
SNMP Agent Community
The SNMP agent community consists of a community string and the operations assigned to the specified community. The community string is a text string for a network management station (NMS) name that an SNMP agent uses for authorization. This means that an NMS would send a community string with each message it sends to the agent.
The operations assigned are get and/or set. The SNMP agent can then verify whether the NMS is authorized to perform get, set, or both get and set operations for data exchange. Community strings are not concealed when sent in SNMP packets; strings are sent in ASCII text.
You can configure and manage the community string and the allowed operations for each specified community from the Administration interface. Refer to "Installing the SNMP Master Agent" for instructions on setting up the SNMP Agent Community.
Setting Up SNMPIn general, to use SNMP, a master agent and at least one subagent must be installed and running on your system. The master agent must be installed before you can enable a subagent. Refer to "Installing the SNMP Master Agent".
The procedures for setting up SNMP are different depending upon your system. The following table provides an overview of procedures to follow for different situations. The actual procedures are described in detail later in the chapter.
Before you begin, you should verify two things:
See your system documentation for information on how to verify this information.
Note
After changing SNMP settings in the Admin Server, installing a new server, or deleting an existing server, you must perform the following steps:
The following topics are addressed in this section:
Using a Proxy SNMP Agent (UNIX/Linux)
You need to use a proxy SNMP agent when you already have a native agent running, and you want to continue using it concurrently with a Sun ONE Application Server master agent. Before you start, be sure to stop the native master agent. (See your system documentation for detailed information.)
This section includes the following topics:
Installing the Proxy SNMP Agent
If an SNMP agent is running on your system and you want to continue using the native SNMP daemon, follow the steps in these sections:
- Install the SNMP master agent. See "Installing the SNMP Master Agent".
- Install and start the proxy SNMP agent and restart the native SNMP daemon. See "Using a Proxy SNMP Agent (UNIX/Linux)".
- Start the SNMP master agent. See "Enabling and Starting the SNMP Master Agent".
- Enable the subagent. See "Enabling the Subagent".
To install the SNMP proxy agent, edit the CONFIG file (you can give this file a different name), located in install_dir/lib/snmp/sagt in the server root directory, so that it includes the listening port for the SNMP daemon. The proxy agent also needs to include the MIB trees and traps that the proxy SNMP agent will forward.
Here is an example of a CONFIG file:
AGENT AT PORT 1161 WITH COMMUNITY public
SUBTREES 1.3.6.1.2.1.1,
1.3.6.1.2.1.2,
1.3.6.1.2.1.3,
1.3.6.1.2.1.4,
1.3.6.1.2.1.5,
1.3.6.1.2.1.6,
1.3.6.1.2.1.7,
1.3.6.1.2.1.8
FORWARD ALL TRAPS;
Starting the Proxy SNMP Agent
To start the proxy SNMP agent, enter the following at the command prompt:
Restarting the Native SNMP Daemon
After starting the proxy SNMP agent, restart the native SNMP daemon at the port you specified in the CONFIG file.
To restart the native SNMP daemon, enter the following at the command prompt:
where port_number is the port number specified in the CONFIG file. For example, on the Solaris platform, using the port in the previously mentioned example of a CONFIG file, you would enter:
Installing the SNMP Master Agent
Note
You cannot use the Administration interface to install and start the master SNMP agent unless the server is running as root.
To install the master SNMP agent:
- Log in as root.
- Check whether an SNMP daemon (snmpd) is running on port 161.
If no SNMP daemon is running, go to Step 4.
If an SNMP daemon is running, make sure you know how to restart it and which MIB trees it supports.
- If an SNMP daemon is running, kill its process.
- In the Administration interface, select the Admin Server node from the left pane.
- Select the Monitoring tab to display the SNMP Agent Trap page, as shown in the following figure:
Figure 6-2 SNMP Agent Trap Page
The Manager Entries information is displayed on this page.
- Type the name of the system that is running your network management software.
- Type the trap port number at which your network management system listens for traps. (The well-known port is 162.) For more information on traps, see "SNMP Trap Destinations".
- Type the community string you want to use in the trap. For more information on community strings, see "SNMP Agent Community".
- Click OK.
- Click the SNMP Agent Community link within the Monitoring tab.
The Community Strings information is displayed, as shown in the following figure.
Figure 6-3 SNMP Agent Community Page
- Type the community string for the master agent.
- Choose an operation level for the community.
After you establish a community, you can edit its settings or remove it from the buttons indicated within the Current Communities heading on this page.
- Click OK.
- Access App Server Instances and your server instance in the left pane, then click Apply Changes.
Enabling and Starting the SNMP Master AgentMaster agent operation is defined in an agent configuration file named CONFIG, which you can edit manually. You must install the master SNMP agent before you can enable the SNMP subagent.
This section includes the following topics:
Starting the Master Agent on Another Port
The Administration interface will not start the SNMP master agent on ports other than 161. However, you can manually start the master agent on another port using the following steps:
The master agent will then start on the desired port. However, the Administration interface will be able to detect that the master agent is running.
Manually Configuring the SNMP Master Agent
To configure the master SNMP agent manually:
- Log in as root.
- Check to see if there is an SNMP daemon (snmpd) running on port 161.
If an SNMP daemon is running, make sure you know how to restart it and which MIB trees it supports. Then kill its process.
- Edit the CONFIG file located in lib/snmp/magt in the server root directory.
- (Optional) Define sysContact and sysLocation variables in the CONFIG file as described in "Defining sysContact and sysLocation Variables".
Editing the Master Agent CONFIG File
The CONFIG file defines the community and the manager that will work with the master agent. The manager value should be a valid system name or an IP address.
Here is an example of a basic CONFIG file:
COMMUNITY public
ALLOW ALL OPERATIONS
MANAGER manager_station_name
SEND ALL TRAPS TO PORT 162
WITH COMMUNITY public
Defining sysContact and sysLocation Variables
You can edit the CONFIG file to add initial values for sysContact and sysLocation which specify the sysContact and sysLocation MIB-II variables. The strings for sysContact and sysLocation in this example are enclosed in quotes. Any string that contains spaces, line breaks, tabs, and so on must be in quotes. You can also specify the value in hexadecimal notation.
Here is an example of a CONFIG file with sysContact and sysLocation variables defined:
Configuring the SNMP Subagent
To configure the SNMP subagent, perform the following steps:
Figure 6-4 SNMP Subagent Configuration Page
- (UNIX only) Enter the name and domain of the server in the Master Host field.
- Enter the Description of the server, including operating system information.
- Enter the Organization responsible for the server.
- Enter the location of the server instance.
- Enter the name of the person responsible for the server and the person’s contact information in the Contact field.
- Select On to Enable the SNMP Statistics Collection.
- Click OK.
- Access App Server Instances and your server instance in the left pane, then click Apply Changes.
Starting the SNMP Master Agent
Once you have installed the SNMP master agent, you can start it manually or by using the Admin Server from the Administration interface.
Manually Starting the SNMP Master Agent
To start the master agent manually, enter the following at the command prompt:
The INIT file is a nonvolatile file that contains information from the MIB-II system group, including system location and contact information. If INIT doesn’t already exist, starting the master agent for the first time will create it.
To start a master agent on a non-standard port, use one of two methods:
Method 1: In the CONFIG file, specify a transport mapping for each interface over which the master agent listens for SNMP requests from managers. Transport mappings allow the master agent to accept connections at the standard port and at a non-standard port. The master agent can also accept SNMP traffic at a non-standard port. The maximum number of concurrent SNMP is limited by your target system’s limits on the number of open sockets or file descriptors per process. Here is an example of a transport mapping entry:
TRANSPORT extraordinary SNMP
OVER UDP SOCKET
AT PORT 11161After editing the CONFIG file manually, you should start the master agent manually by typing the following at the command prompt:
Method 2: Edit the /etc/services file to allow the master agent to accept connections at the standard port as well as at a non-standard port.
Starting the SNMP Master Agent Using the Admin Server
To start the SNMP master agent using the Admin Server, perform the following steps:
Figure 6-5 SNMP Agent Control Page
Enabling the Subagent
After you have installed the master agent that comes with the Administration Server, you must enable the subagent for your server instance before you attempt to start it. For information on installing the master agent, see "Installing the SNMP Master Agent".
You can use the subagent to stop the SNMP function on UNIX/Linux platforms. You must stop the subagent first, then the master agent. If you stop the master agent first, you may not be able to stop the subagent. If that happens, restart the master agent, stop the subagent, then stop the master agent.
To enable the SNMP subagent:
Figure 6-6 SNMP Subagent Control Page
From this page, you can start, stop, or restart the SNMP subagent. The status of the subagent is indicated just above the control buttons.
On the Windows platform, the Windows SNMP service is used for monitoring the Sun ONE Application Server; it can be controlled from the Control Panel/Administrative Tools/Services option.
Note
After making any SNMP configuration changes, you must click OK, then restart SNMP subagent from the SNMP Subagent Control page.
