Previous Contents Index Next
Sun ONE Web Server 6.1 Administrator's Guide

> ## Chapter 11
> Monitoring Servers

> This chapter contains information on ways to monitor your server, including the built-in monitoring tool, the quality of service features, and Simple Network Management Protocol (SNMP).

> You can use SNMP together with Sun ONE management information bases (MIB) and network management software such as HP OpenView to monitor your servers in real-time just as you monitor other devices in your network.

> Note | On Windows, before installing Sun ONE Web Server 6.1, ensure that Windows SNMP components are already installed on your machine.

> You can view the server’s status in real time by using the statistics feature or the SNMP. If you’re using UNIX or Linux, you must configure your Sun ONE server for SNMP if you plan to use it. This chapter provides the information you need to use SNMP on UNIX or Linux with your Sun ONE server.

> The following topics are included in this chapter:

> - Monitoring the Server Using Statistics
> - Using Quality of Service
> - SNMP Basics
> - The Sun ONE Web Server MIB
> - Setting Up SNMP
> - Using a Proxy SNMP Agent (UNIX/Linux)
> - Reconfiguring the SNMP Native Agent
> - Installing the SNMP Master Agent
> - Enabling and Starting the SNMP Master Agent
> - Configuring the SNMP Master Agent
> - Enabling the Subagent
> - Understanding SNMP Messages

> ##

> Monitoring the Server Using Statistics

> You can use the statistics feature to monitor your server’s current activity. The statistics show you how many requests your server is handling and how well it is handling these requests. You can view some statistics for individual virtual servers, and others for the entire server instance. If the interactive 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 to accommodate the requests. For more information, see the online Sun ONE Web Server 6.1 Performance Tuning, Sizing and Scaling Guide.

> Once you enable statistics, you can view statistics in the following areas:

> - connections
> - DNS
> - KeepAlive
> - cache
> - virtual servers

> For a description of the various server statistics for which the interactive server monitor reports the totals, see the Monitor Current Activity page in the online help.

> Caution | When you enable statistics/profiling, statistics information will be available to any user of your server. See the description of stats-xml in the Sun ONE Web Server 6.1 NSAPI Programmer’s Guide for more information.

> ### Enabling Statistics

> To enable statistics, follow these steps:

> 1. From the Server Manager, click the Monitor tab.
> 2. Click Monitor Current Activity
> 3. Click Yes to enable statistics.
> 4. Click OK.
> 5. Click Apply to apply your changes. You do not need to restart the server.

> For more information on enabling statistics, see the online help.

> ### Using Statistics

> Once you’ve enabled statistics, you can get a variety of information on how your server instance and your virtual servers are running. The statistics are broken up into functional areas.

> To access statistics, follow these steps:

> 1. From the Server Manager, click the Monitor tab.
> 2. Click Monitor Current Activity.
> 3. From the drop-down list, choose the poll interval.

> The poll interval is the number of seconds between updates of the statistics information displayed.

> 4. From the drop-down list, choose the kind of statistics you want displayed.
> 5. Click Submit.

> If your server instance is running, and you have enabled statistics/profiling, you see a page displaying the kind of statistics you selected. The page is updated every 5-15 seconds, depending upon what you chose for the poll interval.

> You can use the data you see in statistics to tune your server. For more information, see the online Sun ONE Web Server 6.1 Performance Tuning, Sizing, and Scaling Guide.

> ##

> Using Quality of Service

> 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 ISP, you might want to charge different amounts of money for virtual servers depending on how much bandwidth you allow them. You can limit two areas: the amount of bandwidth and the number of connections.

> You can enable these settings for the entire server or for a class of virtual servers in the Server Manager from the Monitor tab. However, you can override these server or class-level settings for an individual virtual server. For more information on setting quality of service limits for an individual server, see "Configuring Virtual Server Quality of Service Settings".

> Two settings govern how traffic is counted and how often the bandwidth is recomputed: the recompute interval and the metric interval. The recompute is how often (in milliseconds) the bandwidth is computed. The metric interval is the period of time for which data is used in traffic calculations.

> This section includes the following topics:

> - Quality of Service Example
> - Setting Up Quality of Service
> - Required Changes to obj.conf
> - Known Limitations to Quality of Service

> ### 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 time 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 gets recomputed periodically every 100 milliseconds. The calculation is based on the amount of traffic as well as the metric interval.

> At time 0 seconds, the bandwidth is calculated for the first time. The total traffic is zero, divided by the metric interval of 30 seconds, gives 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, gives a bandwidth of 0 bytes/second.

> ### Setting Up Quality of Service

> To configure the quality of service settings for a server instance or a class of virtual servers, you need to configure the settings in through the user interface. To actually enforce your quality of service settings, you must also set up Server Application Functions (SAFs) in your obj.conf file.

> To configure quality of service, follow these steps:

> 1. From the Server Manager, click the Monitor tab.
> 2. Click Quality of Service.

> A page appears listing general settings for quality of service, followed by a list containing the server instance as a whole and each class of virtual servers.

> 3. To enable quality of service as a whole, click Enable.

> By default quality of service is enabled. Enabling quality of service increases server overhead slightly.

> 4. Choose the Recompute Interval.

> The recompute interval is the number of milliseconds between each computation of the bandwidth for all servers, classes, and virtual servers. The default is 100 milliseconds.

> 5. Choose the Metric Interval.

> The metric interval is the interval in seconds during which the traffic is measured. The default is 30 seconds. All bandwidth measured during this time is averaged to give the bytes per second.

> If your site has a lot of large file transfers, use a large value (several minutes or more) or 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.

> Please note that if you have large static file transfers and a bandwidth limit that is much lower than available bandwidth, you have to decide which situation to tune for, since the problems require opposite solutions.

> 6. Enable quality of service for the server instance and/or the virtual server classes.

> The lower portion of the screen lists the server instance and server classes. Choose Enable as the action next to the items for which you want to enable quality of service.

> 7. Set the maximum bandwidth, in bytes per second.
> 8. Choose whether or not to enforce the maximum bandwidth setting.

> If you choose to enforce the maximum bandwidth, once 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 error log.

> 9. Choose the maximum number of connections allowed.

> This number is the number of concurrent requests processed.

> 10. Choose whether or not to enforce the maximum connections setting.

> If you choose to enforce the maximum connections, once the server reaches its limit additional connections are refused.

> 11. If you do not enforce the maximum connections, when the maximum is exceeded the server logs a message to the error log.
> 12. Click OK.

> ### Required Changes to obj.conf

> To enable quality of service, you must include directives in your obj.conf to invoke two Server Application Functions (SAFs): an AuthTrans qos-handler and an Error qos-error.

> The qos-handler AuthTrans directive must be the first AuthTrans configured in the default object in order to work properly. 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 enforce the limits by returning an error.

> Sun ONE Web Server includes a built-in sample quality of service handler SAF, called qos-handler. This SAF logs when limits are reached, and returns 503 "Server busy" to the server so that it can be processed by NSAPI.

> Sun ONE Web 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. You may want to alter the sample code to provide different error information.

> These samples are available at server_root/plugins/nsapi/examples/qos.c. You can use these samples, or you can write your own SAFs.

> For more information on these SAFs and how to use them, see the Sun ONE Web Server 6.1 NSAPI Programmer’s Guide.

> ### Known Limitations to Quality of Service

> When you use the quality of service features, keep in mind the following limitations:

> - The connection or bandwidth statistics are not shared across server processes because of performance. In other words, the setting of MaxProc is not accounted for. So all the limits apply individually to a server process, not to the aggregate of all processes. For more information on MaxProcs and multiple processes, see the online Sun ONE Web Server 6.1 Performance Tuning, Sizing, and Scaling Guide.
> - 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:
> - If SSL is enabled, handshakes and client certificate exchanges add to the traffic but are not measured.
> - If chunked encoding is enabled in either or both directions, the chunking layer removes the chunk headers and they are not counted in the traffic. Other headers or protocol items are counted.
> - 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, such 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 go up 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 has a lot of very long static file downloads, the 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 server dynamic 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), and the virtual server class and server instance values are not quite as accurate, since they’re only computed at intervals.

> ##

> SNMP Basics

> SNMP is a protocol used to exchange data about network activity. 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 web server, and other servers on your network. The NMS is a machine used to remotely manage that 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 web 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 a Sun ONE 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 and passes the information to the server’s master agent. Every Sun ONE server, except for the Administration Server, has as subagent.

> Note | After making any SNMP configuration changes, you must click the Apply button, then restart SNMP subagent.

> The master agent communicates with the NMS. The master agent is installed with the Administration Server.

> You can have multiple subagents installed on a host computer, but only one master agent. For example, if you had Directory Server, Sun ONE Web Server, and the Messaging Server installed on the same host, the subagents for each of the servers would communicate with the same master agent, as shown below:

> The Network Management Station and SNMP Agents

> ##

> The Sun ONE Web Server MIB

> Sun ONE Web Server stores variables pertaining to network management. 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 web server’s network configuration, status, and statistics. Using SNMP, you can view this information from the network management workstation (NMS).

> A server's MIB contains variable definitions pertaining to network management for that particular server. The top level of the MIB tree is shown in the figure below:

> Top level of the MIB tree

> The top level of the MIB tree shows that the internet object identifier has four subtrees: directory (1), mgmt (2), experimental (3), and private (4). 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. The Sun ONE MIBs are located under the enterprises (1) node.

> Each Sun ONE server subagent provides a MIB for use in SNMP communication. The server reports significant events to the network management station (NMS) by sending messages or traps containing these variables. The NMS can also query the server’s MIB for data, or can remotely change variables in the MIB.

> Each Sun ONE server has its own management information base (MIB). All Sun ONE MIBs are located at:

> server_root/plugins/snmp

> The Sun ONE Web Server’s MIB is a file called webserv61.mib. This MIB contains the definitions for various variables pertaining to network management for Sun ONE Web Server.

> The Sun ONE Web Server 6.1 MIB has an object identifier of
> http 60 (iws60 OBJECT IDENTIFIER ::= {http 60 }) and is located in the server_root/plugins/snmp directory.

> You can see administrative information about your web server and monitor the server in real time using the Sun ONE Web Server MIB. Table 11-1 lists and describes the managed objects stored in the webserv61.mib.

> Table 11-1 webserv61.mib managed objects and descriptions

> Managed object | Description
> --- | ---
> iwsInstanceTable | Sun ONE Web Server instances.
> iwsInstanceEntry | Sun ONE Web Server instance.
> iwsInstanceIndex | Server instance index.
> iwsInstanceId | Server instance identifier
> iwsInstanceVersion | String, such as SunONE-WebServer/6.1 BB1-01/24/2001 17:15 (SunOS DOMESTIC)
> iwsInstanceDescription | Description of the server instance.
> iwsInstanceOrganization | Organization responsible for the server instance.
> iwsInstanceContact | Contact information for person(s) responsible for server instance.
> iwsInstanceLocation | Where the server is located.
> iwsInstanceStatus | Status of the server instance.
> iwsInstanceUptime | How long the server has been running.
> iwsInstanceDeathCount | Number of times server instance processes have gone down.
> iwsInstanceRequests | Number of requests processed by the server instance.
> iwsInstanceInOctets | Number of octets received by the server instance. Will show 0 if information is not available.
> iwsInstanceOutOctets | Number of octets transmitted by the server instance. Will show 0 if information is not available.
> iwsInstanceCount2xx | Number of 200-level (Successful) responses issued by the server instance.
> iwsInstanceCount3xx | Number of 300-level (Redirection) responses issued by the server instance.
> iwsInstanceCount4xx | Number of 400-level (Client Error) responses issued by the server instance.
> iwsInstanceCount5xx | Number of 500-level (Server Error) responses issued by the server instance.
> iwsInstanceCountOther | Number of other (neither 2xx, 3xx, 4xx, nor 5xx) responses issued by the server instance.
> iwsInstanceCount200 | Number of 200 (Request Fulfilled) responses issued by the server instance.
> iwsInstanceCount302 | Number of 302 (Moved Temporarily) responses issued by the server instance.
> iwsInstanceCount304 | Number of 304 (Not Modified) responses issued by the server instance.
> iwsInstanceCount400 | Number of 400 (Bad Request) responses issued by the server instance.
> iwsInstanceCount401 | Number of 401 (Unauthorized) responses issued by the server instance.
> iwsInstanceCount403 | Number of 403 (Forbidden) responses issued by the server instance.
> iwsInstanceCount404 | Number of 404 (Not Found) responses issued by the server instance.
> iwsInstanceCount503 | Number of 503 (Unavailable) responses issued.
> iwsVsTable | Sun ONE Web Server virtual servers.
> iwsVsEntry | Sun ONE Web Server virtual server.
> iwsVsIndex | Virtual server index.
> iwsVsId | Virtual server identifier.
> iwsVsRequests | Number of requests processed by the virtual server.
> iwsVsInOctets | Number of octets received by the virtual server.
> iwsVsOutOctets | Number of octets transmitted by the virtual server.
> iwsVsCount2xx | Number of 200-level (Successful) responses issued by the virtual server.
> iwsVsCount3xx | Number of 300-level (Redirection) responses issued by the virtual server.
> iwsVsCount4xx | Number of 400-level (Client Error) responses issued by the virtual server.
> iwsVsCount5xx | Number of 500-level (Server Error) responses issued by the virtual server.
> iwsVsCountOther | Number of other (neither 2xx, 3xx, 4xx, nor 5xx) responses issued by the virtual server.
> iwsVsCount200 | Number of 200 (Request Fulfilled) responses issued by the virtual server.
> iwsVsCount302 | Number of 302 (Moved Temporarily) responses issued by the virtual server.
> iwsVsCount304 | Number of 304 (Not Modified) responses issued by the virtual server.
> iwsVsCount400 | Number of 400 (Bad Request) responses issued by the virtual server.
> iwsVsCount401 | Number of 401 (Unauthorized) responses issued by the virtual server.
> iwsVsCount403 | Number of 403 (Forbidden) responses issued by the virtual server.
> iwsVsCount404 | Number of 404 (Not Found) responses issued by the virtual server.
> iwsVsCount503 | Number of 503 (Unavailable) responses issued.
> iwsProcessTable | Sun ONE Web Server processes.
> iwsProcessEntry | Sun ONE Web Server process.
> iwsProcessIndex | Process index.
> iwsProcessId | Operating system process identifier.
> iwsProcessThreadCount | Number of request processing threads.
> iwsProcessThreadIdle | Number of request processing threads currently idle.
> iwsProcessConnectionQueueCount | Number of connections currently in connection queue.
> iwsProcessConnectionQueuePeak | Largest number of connections that have been queued simultaneously.
> iwsProcessConnectionQueueMax | Maximum number of connections allowed in connection queue.
> iwsProcessConnectionQueueTotal | Number of connections that have been accepted.
> iwsProcessConnectionQueueOverflows | Number of connections rejected due to connection queue overflow.
> iwsProcessKeepaliveCount | Number of connections currently in keepalive queue.
> iwsProcessKeepaliveMax | Maximum number of connections allowed in keepalive queue.
> iwsProcessSizeResident | Process resident size in kbytes.
> iwsProcessSizeVirtual | Process size in kbytes.
> iwsProcessFractionSystemMemoryUsage | Fraction of process memory in system memory.
> iwsListenTable | Sun ONE Web Server listen sockets.
> iwsListenEntry | Sun ONE Web Server listen socket.
> iwsListenIndex | Listen socket index.
> iwsListenId | Listen socket identifier.
> iwsListenAddress | Address where socket listens.
> iwsListenPort | Port where socket listens.
> iwsListenSecurity | Encryption support.
> iwsThreadPoolTable | Sun ONE Web Server thread pools.
> iwsThreadPoolEntry | Sun ONE Web Server thread pool.
> iwsThreadPoolIndex | Thread pool index.
> iwsThreadPoolID | Thread pool identifier.
> iwsThreadPoolCount | Number of requests queued.
> iwsThreadPoolPeak | Largest number of requests that have been queued simultaneously.
> iwsThreadPoolMax | Maximum number of requests allowed in queue.
> iwsInstanceStatusChange | An iwsInstanceStatusChange trap signifies that iwsInstanceStatus has changed.
> iwsInstanceLoad1MinuteAverage | System load average for one minute.
> iwsInstanceLoad5MinuteAverage | System load average for five minutes.
> iwsInstanceLoad15MinuteAverage | System load average for fifteen minutes.
> iwsInstanceNetworkInOctets | Number of octets transmitted on the network per second.
> iwsInstanceNetworkOutOctets | Number of octets received on the network per second.
> iwsCpuIndex | The CPU index.
> iwsCpuId | The CPU id.
> iwsCpuIdleTime | The CPU idle time.
> iwsCpuUserTime | The CPU user time.
> iwsCpuKernelTime | The CPU kernel time.

> ##

> Setting Up SNMP

> In general, to use SNMP you must have a master agent and at least one subagent installed and running on a your system. You need to install the master agent before you can enable a subagent.

> The procedures for setting up SNMP are different depending upon your system. Table 8.1 provides an overview of procedures you will follow for different situations. The actual procedures are described in detail later in the chapter.

> Before you begin, you should verify two things:

> - Is your system already running an SNMP agent (an agent native to your operating system)?
> - If so, does your native SNMP agent support SMUX communication? (If you’re using the AIX platform, your system supports SMUX.)

> See your system documentation for information on how to verify this information.

> Note | After changing SNMP settings in the Administration Server, installing a new server, or deleting an existing server, you must perform the following steps: (Windows) Restart the Windows SNMP service or reboot the machine. (UNIX) Restart the SNMP master agent using the Administration Server.

> Table 2 Overview of procedures for enabling SNMP master agents and subagents.

> If your server meets these conditions.... | ...follow these procedures. These are discussed in detail in the following sections.
> --- | ---
> No native agent is currently running | 1. Start the master agent. 2. Enable the subagent for each server installed on the system.
> Native agent is currently running No SMUX No need to continue using native agent | 1. Stop the native agent when you install the master agent for your Administration Server. 2. Start the master agent. 3. Enable the subagent for each server installed on the system.
> Native agent is currently running No SMUX Needs to continue using native agent | 1. Install a proxy SNMP agent. 2. Start the master agent. 3. Start the proxy SNMP agent. 4. Restart the native agent using a port number other than the master agent port number. 5. Enable the subagent for each server installed on the system.
> Native agent is currently running SMUX supported | 1. Reconfigure the SNMP native agent. 2. Enable the subagent for each server installed on the system.

> ##

> 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 use continue using it concurrently with an Sun ONE Web Server master agent. Before you start, be sure to stop the native master agent. (See your system documentation for detailed information.)

> Note | To use a proxy agent, you’ll need to install it and then start it. You’ll also have to restart the native SNMP master agent using a port number other than the one the Sun ONE Web Server master agent is running on.

> This section includes the following topics:

> - Installing the Proxy SNMP Agent
> - Starting the Proxy SNMP Agent
> - Restarting the Native SNMP Daemon

> ### 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:

> 1. Install the SNMP master agent. See Installing the SNMP Master Agent.
> 2. Install and start the proxy SNMP agent and restart the native SNMP daemon. See Using a Proxy SNMP Agent (UNIX/Linux).
> 3. Start the SNMP master agent. See Enabling and Starting the SNMP Master Agent.
> 4. 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 plugins/snmp/sagt in the server root directory, so that it includes the port that the SNMP daemon will listen to. It 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, at the command prompt, enter:

> # sagt -c CONFIG&

> ### Restarting the Native SNMP Daemon

> After starting the proxy SNMP agent, you need to restart the native SNMP daemon at the port you specified in the CONFIG file. To restart the native SNMP daemon, at the command prompt, enter

> # snmpd -P port_number

> 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’d enter:

> # snmpd -P 1161

> ##

> Reconfiguring the SNMP Native Agent

> If your SNMP daemon is running on AIX, it supports SMUX. For this reason, you don’t need to install a master agent. However, you do need to change the AIX SNMP daemon configuration.

> AIX uses several configuration files to screen its communications. One of them, snmpd.conf, needs to be changed so that the SNMP daemon accepts the incoming messages from the SMUX subagent. For more information, see the online manual page for snmpd.conf. You need to add a line to define each subagent.

> For example, you might add this line to the snmpd.conf:

> smux 1.3.6.1.4.1.1.1450.1 ““ IP_address net_mask

> IP_address is the IP address of the host the subagent is running on, and net_mask is the network mask of that host.

> Note | Do not use the loopback address 127.0.0.1; use the real IP address instead.

> ##

> Installing the SNMP Master Agent

> To configure the SNMP master agent you must install the Administration Server instance as the root user. However, even a non-root user can accomplish basic SNMP tasks, such as MIB browsing, on a web server instance by configuring the SNMP sub-agent to work with the master agent.

> To install the master SNMP agent using the Server Manager:

> 1. Log in as root.
> 2. 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.

> 3. If an SNMP daemon is running, kill its process.
> 4. In the Server Manager, choose the SNMP Master Agent Trap page from the Global Settings tab. The Manager Entries page appears.
> 5. Type the name of the system that is running your network management software.
> 6. Type the port number at which your network management system listens for traps. (The well-known port is 162.) For more information on traps, see Configuring Trap Destinations.
> 7. Type the community string you want to use in the trap. For more information on community strings, see Configuring the Community String.
> 8. Click OK.
> 9. In the Server Manager, the SNMP Master Agent Community page from the choose Global Settings tab. The Community Strings page appears.
> 10. Type the community string for the master agent.
> 11. Choose an operation for the community.
> 12. Click OK.

> ##

> Enabling and Starting the SNMP Master Agent

> Master agent operation is defined in an agent configuration file named CONFIG. You can edit the CONFIG file using the Server Manager, or you can edit the file manually. You must install the master SNMP agent before you can enable the SNMP subagent.

> If you get a bind error similar to “System Error: Could not bind to port,” when restarting the master agent, use ps -ef | grep snmp to check if magt is running. If it is running, use the command kill -9 pid to end the process. The CGIs for SNMP will then start working again.

> This section includes the following topics:

> - Starting the Master Agent on Another Port
> - Manually Configuring the SNMP Master Agent
> - Editing the Master Agent CONFIG File
> - Defining sysContact and sysLocation Variables
> - Configuring the SNMP Master Agent
> - Starting the SNMP Master Agent

> ### 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:

> 1. Edit /server_root/plugins/snmp/magt/CONFIG to specify the desired port.
> 2. Run the start script as follows:

> cd /server_root/https-admserv

> ./start -shell /server_root/plugins/snmp/magt/magt

> /server_root/plugins/snmp/magt/CONFIG

> /server_root/plugins/snmp/magt/INIT

> The master agent will then start on the desired port. However, the user 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:

> 1. Log in as superuser.
> 2. 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.

> 3. Edit the CONFIG file located in plugins/snmp/magt in the server root directory.
> 4. (Optional) Define sysContact and sysLocation variables in the CONFIG file.

> ### Editing the Master Agent CONFIG File

> The CONFIG file defines the community and the manager that master agent will work with. 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 sysContract and sysLocation variables defined:

> COMMUNITY public ALLOW ALL OPERATIONS MANAGER nms2 SEND ALL TRAPS TO PORT 162 WITH COMMUNITY public INITIAL sysLocation “Server room 501 East Middlefield Road Mountain View, CA 94043 USA” INITIAL sysContact “John Doe email: jdoe@netscape.com”

> ### Configuring the SNMP Subagent

> You can configure the SNMP subagent to monitor your server.

> To configure the SNMP subagent, perform the following steps:

> 1. From the Administration Server, select the server instance and click Manage.
> 2. Select the Monitor tab.
> 3. Select SNMP Subagent Configuration.
> 4. (UNIX only) Enter the name and domain of the server in the Master Host field.
> 5. Enter the Description of the server, including operating system information.
> 6. Enter the Organization responsible for the server.
> 7. Enter the absolute path for the server in the Location field.
> 8. Enter the name of the person responsible for the server and the person’s contact information in the Contact field.
> 9. Select On to Enable the SNMP Statistics Collection.
> 10. Click OK.
> 11. Click Apply.
> 12. Select Apply Changes to restart your server for changes to take effect.

> ### Starting the SNMP Master Agent

> Once you have installed the SNMP master agent, you can start it manually or by using the Administration Server.

> #### Manually Starting the SNMP Master Agent

> To start the master agent manually, enter the following at the command prompt:

> # magt CONFIG INIT&

> 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. An invalid manager name in the CONFIG file will cause the master agent start-up to fail.

> To start a master agent on a nonstandard port, use one of two methods:

> Method one: 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 nonstandard port. The master agent can also accept SNMP traffic at a nonstandard 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 11161

> After editing the CONFIG file manually, you should start the master agent manually by typing the following at the command prompt:

> # magt CONFIG INIT&

> Method two: Edit the /etc/services file to allow the master agent to accept connections at the standard port as well as a nonstandard port.

> #### Starting the SNMP Master Agent Using the Administration Server

> To start the SNMP master agent using the Administration Server, perform the following steps:

> 1. Log in to the Administration Server.
> 2. In the Server Manager, choose the SNMP Master Agent Control page from the Global Settings tab. The SNMP Master Agent Control page appears.
> 3. Click Start.

> You can also stop and restart the SNMP master agent from the SNMP Master Agent Control page.

> ##

> Configuring the SNMP Master Agent

> Once you’ve enabled the master agent and enabled a subagent on a host computer, you need to configure the host’s Administration Server. This entails specifying community strings and trap destinations.

> ### Configuring the Community String

> A community string is a text string that an SNMP agent uses for authorization. This means that a network management station would send a community string with each message it sends to the agent. The agent can then verify whether the network management station is authorized to get information. Community strings are not concealed when sent in SNMP packets; strings are sent in ASCII text.

> You can configure the community string for the SNMP master agent from the Community Strings page in the Server Manager. You also define which SNMP-related operations a particular community can perform. From the Server Manager, you can also view, edit, and remove the communities you have already configured.

> ### Configuring Trap Destinations

> An SNMP trap is a message the SNMP agent sends to a network management station. For example, an SNMP agent sends a trap when an interface’s status has changed from up to down. The SNMP agent must know the address of the network management station so it knows where to send traps. You can configure this trap destination for the SNMP master agent from Sun ONE Web Server. You can also view, edit, and remove the trap destinations you have already configured. When you configure trap destinations using Sun ONE Web Server, you are actually editing the CONFIG file.

> ##

> 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 more information on installing the master agent, see Installing the SNMP Master Agent. You can use the Server Manager to enable 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, use the SNMP Subagent Configuration page in the Server Manager, and start the subagent from the SNMP Subagent Control page. For more information, see the corresponding sections in the online help.

> Once you have enabled the subagent, you can start, stop or restart it from the SNMP Subagent Control page or the Services Control Panel for Windows.

> Note | After making any SNMP configuration changes, you must click the Apply button, then restart SNMP subagent.

> ##

> Understanding SNMP Messages

> GET and SET are two types of messages defined by SNMP. 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 with the Administration Server.

> 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 web 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 illustrated in the following examples.

> NMS-initiated Communication. The NMS either requests information from the server or changes the value of a variable store in the server’s MIB. For example:

> 1. The NMS sends a message to the Administration 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).
> 2. The master agent forwards the message to the appropriate subagent.
> 3. The subagent retrieves the data or changes the variable in the MIB.
> 4. The subagent reports data or status to the master agent, and then the master agent forwards the message back (a GET message) to the NMS.
> 5. The NMS displays the data textually or graphically through its network management application.

> Server-initiated Communication. The server subagent sends a message or “trap” to the NMS when a significant event has occurred. For example:

> 1. The subagent informs the master agent that the server has stopped.
> 2. The master agent sends a message or “trap” reporting the event to the NMS.
> 3. The NMS displays the information textually or graphically through its network management application.

> Previous Contents Index Next

> Copyright 2004 Sun Microsystems, Inc. All rights reserved.