Monitoring the server

ou can monitor your server in realtime by using the Hypertext Transfer Protocol (HTTP) or the Simple Network Management Protocol (SNMP). SNMP is an Internet network management protocol used to monitor network devices. You can also monitor your server by recording and viewing log files.

Monitoring the server using HTTP

Monitor your server's process usage by using the interactive server monitor. You can see how your server is handling its traffic and whether the threads currently assigned are sufficient. If traffic increases and the server becomes sluggish, you'll need to adjust the server configuration or the system's network kernel.

To monitor your server from the Server Manager,

  1. Choose Server Status|Monitor Current Activity.
  2. Click Monitor.
On the page that appears, you can see the server usage, a breakdown of server activity, and some server totals.

Server usage

You can monitor the following server usage areas:

Activity breakdown

You can see the number of threads (in terms of percentages) currently being used in the following server activity tasks:

Totals

You can see the following server totals:

Working with log files

Server log files record your server's activity. You can use these logs to monitor your server and help you when troubleshooting. The error log file, located in https-[servername]/logs in the server root directory, lists all the errors the server has encountered. The access log, located in https-[servername]/logs in the server root directory, records information about requests to the server and the responses from the server. You can specify what is included in the access log file from the Server Manager. Use the log analyzer to generate server statistics. You can back up server error and access log files by archiving them.

Viewing the error log file

The error log file contains errors the server has encountered since the log file was created; it also contains informational messages about the server, such as when the server was started. Incorrect user authentication is also recorded in the error log. Use the error log to find broken URL paths or missing files.

To view the error log file from the Server Manager,

  1. Choose Server Status|View Error Log.
  2. If you want to see more or fewer lines of the error log, type the number of lines you'd like to see. (The default is 25 lines.)
  3. If you'd like to filter the error messages for a particular word, type the word in the Only show entries with field. Case is important; make sure the case for your entry matches the case of the word you're searching for. (For example, if you only want to see error messages that contain "warning," type warning.)
The following is an example of an error log:

[13/Feb/1996:16:56:51] info: successful server startup
[20/Mar/1996 19:08:52] warning: for host wiley.a.com trying to GET /report.html, append-trailer reports: error opening /usr/ns-home/docs/report.html (No such file or directory)
[30/Mar/1996 15:05:43] security: for host arrow.a.com trying to GET /, basic-ncsa     reports: user jane password did not match database /usr/ns-home/authdb/mktgdb
In the previous example, the first line is an informational message--the server started up successfully. The second log entry shows that the client wiley.a.com requested the file report.html, but the file wasn't in the primary document directory on the server. The third log entry shows that the password entered for the user jane was incorrect.

Setting log preferences

During installation, an access log file named access was created for the server. You can customize access logging for any resource by specifying whether to log accesses, who not to record accesses from, and whether the server should spend time looking up the domain names of clients when they access a resource.

Server access logs can be in Common Logfile Format, flexible log format, or your own customizable format. The Common Logfile Format is a commonly supported format, but provides a fixed amount of information about the server. The flexible log format allows you to choose (from the Server Manager) what to log. A customizable format uses parameter blocks that you specify to control what gets logged. Once an access log for a resource has been created, you can't change its format unless you archive it or create a new access log file for the resource.

To set access logging preferences,

  1. From the Server Manager, choose Server Status|Log Preferences.
  2. Use the Resource Picker to choose the resource you'd like to apply custom logging to.
  3. Select whether to log client accesses.
  4. Type the full path for the log file. As a default, the log files are kept in the logs directory in the server root directory. If you specify a partial path name, the server assumes the path is the logs directory in the server root.
  5. Choose whether to record domain names or IP addresses in the access log.
  6. Choose which format the log file should be: Common Logfile Format, or flexible log format (Only log radio button), or custom format. If you click Only log, the following flexible log format items are available: If you choose a custom format; type your custom format in the Custom format field. For more information about the parameters you should use, see the Programmer's Guide.
  7. If you don't want to log client access from certain host names or IP addresses, type them in the Hostnames and IP Addresses fields. Type a wildcard pattern of hosts the server should not record accesses from; for example, *.netscape.com doesn't log accesses from people whose domain is netscape.com. You can type wildcard patterns for host names, IP addresses, or both.
  8. Click OK.

Viewing an access log file

You can view the server's active and archived access log files from the Server Manager.

To view an access log,

  1. Choose Server Status|View Access Log.
  2. Choose the access log file you want to see. Active log files for resources and archived log files appear in the list.
  3. To limit how much of the access log you'll see, type the number of lines you want to see in the Number of entries field.
  4. If you'd like to filter the access log entries for a particular word, type the word in the Only show entries with field. Case is important; make sure the case for your entry matches the case of the word you're searching for. (For example, if you only want to see access log entries that contain "POST," type POST.)
The following is a sample of an access log in the common logfile format:

wiley.a.com - - [16/Feb/1996:21:18:26 -0800] "GET / HTTP/1.0" 200 751
wiley.a.com - - [17/Feb/1996:1:04:38 -0800] "GET /docs/grafx/icon.gif HTTP/1.0" 204 342
wiley.a.com - - [20/Feb/1996:4:36:53 -0800] "GET /help HTTP/1.0" 401 571
arrow.a.com - john [29/Mar/1996:4:36:53 -0800] "GET /help HTTP/1.0" 401 571
The following table describes the last line of the sample access log.
Access Log Field

Example

Hostname or IP address of client

arrow.a.com. In this case, the hostname is shown because DNS is enabled; if DNS were disabled, the client's IP address would appear.

RFC 931 information

- (RFC 931 identity--not implemented)

User name

john (user name entered by the client for authentication)

Date/time of request

29/Mar/1996:4:36:53 -0800

Request

GET /help

Protocol

HTTP/1.0

Status code

401

Bytes transferred

571

The following is a sample of an access log using the flexible logging format:

wiley.a.com - - [25/Mar/1996:12:55:26 -0800] "GET /index.htm HTTP/1.0" "GET" "/?-" "HTTP/
1.0" 304 0 - Mozilla/2.0 (WinNT; I)
wiley.a.com - - [25/Mar/1996:12:55:26 -0800] "GET / HTTP/1.0" "GET" "/?-" "HTTP/1.0" 304 0 
- Mozilla/2.0 (WinNT; I) 
wiley.a.com - - [25/Mar/1996:12:55:26 -0800] "GET / HTTP/1.0" "GET" "/?-" "HTTP/1.0" 304 0 
- Mozilla/2.0 (X11; I; IRIX 5.3 IP22) 
The access log using the flexible logging format looks similar to the access log using the Common Logfile Format.

Working with the log analyzer

Use the log analyzer to generate statistics about your server, such as a summary of activity, most commonly accessed URLs, times during the day when the server is accessed most frequently, and so on. You can run the log analyzer from the Server Manager, as described in the following section; if you want to run the log analyzer from the command line, go to the "Running the log analyzer from the command line" section.

Note
Before running the log analyzer, you should archive the server logs. For more information about archiving server logs, see "Archiving log files" on page 153.

Running the log analyzer from the Server Manager

To run the log analyzer from the Server Manager,

  1. Choose Server Status|Generate Report.
  2. Type the name of your server; this name appears in the generated report.
  3. Choose whether the report will appear in HTML or ASCII format.
  4. Select the log file you want to analyze.
  5. If you want to save the results in a file, type an output file name in the Output file field. If you leave the field blank, the report results print to the screen. For large log files, you should save the results to a file because printing the output to the screen might take a long time.
  6. Select whether to generate totals for certain server statistics. The following totals can be generated:
  7. Select whether to generate general statistics. The following general statistics can be generated:
  8. Select whether to generate a list of server access statistics. You can generate a list of the following:
  9. Specify the order in which you want to see the results.
  10. Click OK.

Running the log analyzer from the command line

To analyze access log files from the command line, run flexanlg, which is in extras/flexanlg in your server root directory.

To run flexanlg, type the following command and options at the command prompt:

% flexanlg [ -P ] [-n name] [-x] [-r] [-p order] [-i file]* [ -m 
metafile ]* [-o file][-c opts] [-t opts] [-l opts]
The following describes the syntax. (You can get this information online by typing flexanlg -h.)

-P: proxy log format                                  Default: no
-n servername: The name of the server
-x : Output in HTML                                   Default: no
-r : Resolve IP addresses to hostnames                Default: no
-p [c,t,l]: Output order (counts, time stats, lists)  Default: ctl
-i filename: Input log file(s)                        Default: none
-o filename: Output log file                          Default: stdout
-m filename: Meta file(s)                             Default: none
-c [h,n,r,f,e,u,o,k,c,z]: Count these item(s) -       Default: hnreuokc
    h: total hits
    n: 304 Not Modified status codes (Use Local Copy)
    r: 302 Found status codes (Redirects)
    f: 404 Not Found status codes (Document Not Found)
    e: 500 Server Error status codes (Misconfiguration)
    u: total unique URL's
    o: total unique hosts
    k: total kilobytes transferred
    c: total kilobytes saved by caches
    z: Do not count any items.
-t [sx,mx,hx, xx,z]: Find general stats - Default:s5m5h24x10
    s(number): Find top (number) seconds of log
    m(number): Find top (number) minutes of log
    h(number): Find top (number) hours of log
    u(number): Find top (number) users of log
    a(number): Find top (number) user agents of log
    r(number): Find top (number) referers of log
    x(number): Find top (number) for miscellaneous keywords
    z: Do not find any general stats.
-l [cx,hx]: Make a list of -                          Default: c+3h5
    c(x,+x): Most commonly accessed URLs
             (x: Only list x entries)>
             (+x: Only list if accessed more than x times)
    h(x,+x): Hosts (or IP addresses) most often accessing your server
             (x: Only list x entries)
             (+x: Only list if accessed more than x times)
    z: Do not make any lists

Archiving log files

You can archive the access and error log files and have the server create new ones.

When you archive log files, the server renames the current log files and then creates new log files with the original names. You can back up or archive (or delete) the old log files, which are saved with the original file name appended with the date the file was archived. For example, access becomes access.24-Apr.

You can archive log files immediately, or have the server archive log files at a specific time on specific days. The information about when to archive log files is stored in the cron.conf file in the admserv directory in the server root directory; the server's cron configuration options are stored in ns-cron.conf in the admserv directory.

Note
Before running the log analyzer, you should archive the server logs.

To archive log files,

  1. From the Server Manager, choose Server Status|Archive Log.
  2. Click Archive if you want to archive the log files immediately. or

    If you want archiving to occur at a specific time on specific days, click the Rotate log at button, choose times from the list, and select the days for archiving to occur.

  3. Click OK.
  4. Shut down the administration server by clicking the "shut down" link on the page that appears.
  5. Restart the administration server.
    Note
    If you chose to archive your server logs at specific times on specific days, steps 4 and 5 are necessary in order for archiving to take place.

Monitoring the server using SNMP

SNMP is used to exchange management information between a network management station (NMS) and a managed device.

An NMS is usually a powerful workstation with one or more network management applications installed. A network management application graphically shows information about the managed devices (which device is up or down, number of particular error messages received, and so on).

A managed device is anything that runs SNMP (for example, hosts, routers, and so on). Each managed device contains an SNMP agent, which runs the network management software in the device. Values for various variables that can be queried are kept on the managed device and reported to the NMS as necessary. Each variable is known as a managed object, which is anything the agent can access and send to the NMS. All managed objects are defined in a Management Information Base (MIB), which is a database with a tree-like hierarchy. The top level of the MIB tree is shown in Figure 9.1.

Figure 9-1 Top level of the MIB tree

A network management application might ask the agent for specific information ("How much TCP traffic is there for your device?"), or the agent tells the network management application that something unusual has happened ("The Ethernet0 interface is down.").

As seen in Figure 9.1, 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 Netscape MIB is located under the enterprises (1) node.

The Netscape MIB

The Netscape MIB has an object identifier of 1.3.6.1.4.1.1450. Using the Netscape MIB, you can monitor your server like any other device on your network by using network management software, such as HP OpenView. A basic diagram of information being passed from the server through the SNMP master agent to the NMS is shown in the following diagram.

Interaction between the web server, SNMP agent, and NMS

The Netscape MIB (netscape.mib) is located in the plugins/snmp subdirectory in your server root directory.

You can see administrative information about your server and monitor the server in realtime using the Netscape MIB. Table 9.1 lists the Netscape MIB variables and briefly describes them.
Netscape MIB variable

Description

httpEntityDescr

A description of the server (includes operating system information).

httpEntityId

The enterprise subtree for vendors (for example, Netscape's MIB has an object identifier of 1.3.6.1.4.1.1450).

httpEntityProtocol

The HTTP version number.

httpEntityVersion

The server software version number.

httpEntityOrganization

The organization responsible for the server.

httpEntityLocation

The full path for the server.

httpEntityContact

The person(s) responsible for the server and contact information.

httpEntityAddress

The IP address of the machine the server is running on.

httpEntityPort

The port number on which the server is listening.

httpEntityName

The server's identifier name (for example, server2.a.com).

httpEntityType

The type of server.

httpEntityMethods

The methods supported by the server (for example, GET, POST, PUT)

httpEntityMaxProcess

The maximum number of active processes on the server.

httpEntityMinProcess

The minimum number of active processes on the server.

httpEntityMaxThread

The maximum number of active threads on the server.

httpEntityMinThread

The minimum number of active threads on the server.

httpStatisticsPort

The port number on which this server is listening.

httpStatisticsAddress

The IP address to which this server is bound.

httpStatisticsStatus

The status of the server (up or down).

httpStatisticsUptime

The uptime of the server since it was started.

httpStatisticsNumProcessIdle

The number of server's idle processes.

httpStatisticsNumProcessProc

The number of server's processes that are processing requests.

httpStatisticsNumProcessDns

The number of processes resolving host names.

httpStatisticsRequests

The total number of requests received/generated.

httpStatisticsRequestError

The total number of request errors detected.

httpStatisticsProcessNum

The number of running processes.

httpStatisticsThreadNum

The number of running threads.

Note
You should be a system administrator or have in-depth system knowledge before installing the SNMP agents.

Installing Netscape SNMP agents

Before you can use the Netscape MIB to monitor your web server, you need to first install a master agent (unless your SNMP daemon supports SMUX). If you're not sure whether your SNMP daemon supports SMUX, see its documentation. You then need to enable an SNMP subagent.

If you are already using an SNMP daemon and want to continue using it, you need to install a proxy SNMP agent before restarting the original SNMP daemon. If you are working on the AIX platform, go to the "Installing subagents on AIX" section.

If SNMP is running on your system and you want to continue using the native SNMP daemon, follow the steps in these sections:

If SNMP is not running on your system, or if SNMP is running on your system and you do not want to continue using the native SNMP daemon, follow the steps in these sections:

Installing the SNMP master agent

You need to install the master SNMP agent before you can enable the SNMP subagent. 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.

Manually installing the SNMP master agent
To install 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 there isn't an SNMP daemon 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. Edit the CONFIG file, located in plugins/snmp/magt in the server root directory. The following is an example of a CONFIG file:

    COMMUNITY          public
                       ALLOW ALL OPERATIONS

    MANAGER            <your_manager_station_name>
                       SEND ALL TRAPS TO PORT 162
                       WITH COMMUNITY public

    The CONFIG file defines the community and which manager the master agent will work with. The manager value should be a valid system name or an IP address. You can also define initial values for sysContact and sysLocation, as well as transport mappings for SNMP. For more information about these values, see "A sample CONFIG file" on page 160.

  5. Start the master agent by typing the following at the command prompt:

    # magt CONFIG INIT&

    The INIT file is a non-volatile 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 startup to fail.

    After installing the master agent, if you want to continue using the native SNMP daemon, follow the steps in the "Installing the proxy SNMP agent and restarting the native SNMP daemon" section on page 162.

    After starting the master agent on your system, if you do not want to continue using the native SNMP daemon, go to "Enabling the subagent" section on page 163.

A sample CONFIG file

In addition to setting the community the master agent works with and the managers that receive traps, you can manually add initial values for sysContact and sysLocation, which specify the sysContact and sysLocation MIB-II variables. Note that the string for sysContact and sysLocation in the example CONFIG file is enclosed in quotes. If the string contains spaces, line breaks, tabs, and so on, the string must be in quotes. The value can also be specified in hexadecimal notation.

The following is an example of a CONFIG file:

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>"
You can start a master agent a non-standard port by doing one of the following:

Installing the master SNMP agent using the Server Manager
In order to install and start the master SNMP agent using the Server Manager, the server must be running as root.

To install the master SNMP agent using the Server Manager,

  1. Log in as superuser.
  2. Check to see if there is an SNMP daemon (snmpd) running on port 161. If there isn't an SNMP daemon 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. Choose Server Status|SNMP Master Agent Trap.
  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.)
  7. Type the community string you want to use in the trap.
  8. Click OK.
  9. Choose Server Status|SNMP Master Agent Community.
  10. Type the community string for the master agent.
  11. Choose an operation for the community.
  12. To start the master agent, click the Start master agent button.
  13. Click OK.

Installing the proxy SNMP agent and restarting the native SNMP daemon

If you already have an SNMP master agent running and want to use the native SNMP daemon, you need to install a proxy SNMP agent and then run the native daemon on a different port other than the one the master agent is running on.

To install the SNMP proxy agent,

  1. Edit the CONFIG file (you can give this file a different name), located in plugins/snmp/sagt in the server root directory to include the port the SNMP daemon will listen to and which MIB trees and traps this proxy SNMP agent will forward. The following is an example 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;

  2. Start the proxy SNMP agent by typing the following:

    # pagt -c CONFIG&

  3. Now restart the SNMP daemon at the port you specified in CONFIG. For example, on the Solaris platform, using the port in the previously mentioned example CONFIG file, you'd type:

    # snmpd -P 1161

  4. Follow the steps in the next section, "Enabling the subagent" to enable the subagent.

Enabling the subagent

After you've installed the master agent, you need to enable the subagent. You can do this using the Server Manager.

To enable the SNMP subagent, do the following:

  1. Choose Server Status|SNMP Subagent Configuration.
  2. Type the name of the system that has the master agent installed on it. (The default is the local system.)
  3. Type a description.
  4. Type your organization name.
  5. Type the web server's location.
  6. Type the contact person for the web server.
  7. Click the On radio button.
  8. Click OK.
  9. Now you must stop and start the administration server by following the steps in the "Stopping and starting the administration server" section.

Stopping and starting the administration server

Before you can monitor your server using SNMP (with a network management software package such as HP OpenView, for example), you must stop and restart the administration server. You can stop the administration server from the command line or from the Server Manager.

To stop the administration server from the command line, log in as the user the administration server runs as and go to the server root directory. Type the following (in this example, the administration server runs as root):

# ./stop-admin

To stop the administration server from the Server Manager,

  1. Go to the Server Selector. (If you're already using the Server Manager, click Choose in the upper left part of the window. Or, you can type the URL for the Server Selector in the Location field in Navigator.)
  2. Click Configure Administration.
  3. Click Shut down your admin server.
  4. Click Shut down the administrative server.
To start the administration server,

  1. Go to your server root directory.
  2. Type the following (as the user the administration server runs as--in this example, root):

    # ./start-admin

Installing subagents on AIX

If your SNMP daemon is running on AIX, it supports SMUX, which means that you don't need to install a master agent. 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 a 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.

If you need more information, see your related system documentation for details.

Configuring trap destinations

An SNMP trap is a message the SNMP agent sends to a network management station. For example, an SNMP agent would sent 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 the Server Manager. You can also view, edit, and remove the trap destinations you have already configured. When you configure trap destinations using the Server Manager, you are actually editing the CONFIG file.

To configure trap destinations,

  1. Choose Server Status|SNMP Master Agent Trap.
  2. Type the name of the system that is running your network management software.
  3. Type the port number at which your network management system listens for traps. (The well-known port is 162.)
  4. Type the community string you want to use in the trap.
  5. Click OK.

Configuring the community string

A community string is a password used by an SNMP agent for authentication, which means that a network management station would have to send the special password with each message it sent to the agent. The agent could then verify that whether the network management station is authorized to get information. Note that community strings are not concealed when sent in SNMP packets; strings are sent in ASCII text. The master agent uses the community string for authentication.

You can configure the community string for the SNMP master agent from 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.

To configure community strings,

  1. Choose Server Status|SNMP Master Agent Community.
  2. Type the community string for the master agent.
  3. Choose an operation for the community.
  4. To also start the master agent, click the Start master agent button. (You can only start the master agent this way if the server is running as root.)
    Note
    The master agent cannot be started this way if there is an SNMP daemon already running. If an SNMP daemon is running, manually kill its process, and then start the master agent using the process discussed in "Installing the SNMP master agent" on page 159.

  5. Click OK.