Monitoring the Oracle HTTP Server

In this third part of a five-part article, you’ll learn how to manage the Oracle HTTP Server (OHS) from the command line, how to monitor the OHS, and more. It is excerpted from chapter five of the book Oracle 10g Application Server Exam Guide, written by Sam Alapati (McGraw-Hill, 2006; ISBN: 0072262710).

CERTIFICATION OBJECTIVE 5.02: Managing the Oracle HTTP Server

You can manage the Oracle HTTP Server through the Application Server Control, or with the help of command-line tools.

Managing from the Command Line

The two command-line tools you use to manage OHS are opmnctl and dcmtl. You can start, restart, and stop the Oracle HTTP Server along with the rest of the OracleAS components using the opmnctl utility, or just the Oracle HTTP Server by itself. Here’s how you start and stop the OHS server using the opmnctl command-line utility, which is located in the $ORACLE_HOME/opmn/bin directory:

  $opmnctl startproc ias-component=HTTP_Server
  $opmnctl stopproc ias-component=HTTP_Server
  $opmnctl restartproc ias-component=HTTP_Server

You can also use the dcmtl utility to configure the Oracle HTTP Server instance.

exam watch:   Always use the opmnctl command-line tool to start, stop, and restart the Oracle HTTP Server to avoid potential problems caused by the inability of the configuration infrastructure to communicate with server processes. You shouldn’t use the apachectl utility to manage the OHS.

Using the Application Server Control to Manage OHS

You can view the status and a brief performance report of the Oracle HTTP Server in the Application Server home page, shown in Figure 5-2. To get to the home page of the Oracle HTTP Server, go to the System Components table of the relevant OracleAS instance and click the HTTP_Server link. From the HTTP Server home page, you can click links to view the status metrics, module metrics, and the response/load metrics. You can also view the error log for the HTTP Server by clicking the Error Log link.

Go to the System Components table section of the Application Server Control to find where you can start, stop, and restart the OHS server. You can also stop and start the OHS using the Stop All and Start All buttons on the Application Server Control home page.

You can use the Application Server Control to conveniently manage the OHS and modify the default configuration settings. You’ve already seen how you can start, stop, and restart the OHS Server using the Application Server Control. Let’s briefly examine the various OHS management features in the Application Server Control.

Figure 5-2.   The Oracle HTTP Server Home Page

Editing the httpd.conf File

You can edit the httpd.conf file by following these steps:

  1. On the Application Server home page, select Oracle HTTP Server from the System Components table and click the HTTP_Server link.
  2. On the HTTP Server home page, click the Administration tab.
  3. Click the Advanced Server Properties link in the HTTP_Server Administration page.
  4. In the Advanced Properties page, click the httpd.conf link, to edit that file.

Figure 5-3 shows the Advanced Server Properties page. You can view and modify several OHS
configuration files from this page, including the httpd.conf file and the oracle_apache.conf file, which helps configure the Oracle-specific HTTP parameters.

Although you can modify the httpd.conf file manually, the advantage in editing the file using Application Server Control is that the configuration changes are effected immediately, because the OHS server is automatically bounced when you

Figure 5-3.   The Advanced Server Properties Page

modify the configuration. Also remember that if you do decide to manually edit the httpd.conf file, be sure to issue the following dcmtl command at the command line:

  $ dcmtl updateconfig -v

When you issue this command, the Metadata Repository is updated with the configuration changes you make by manually editing the httpd.conf file. The– v option gives you detailed information (verbose) about the results of executing the command. Make sure that you execute the dcmtl command in the appropriate OracleAS instance home directory. You can’t guarantee that you’re issuing the command in the right environment by merely setting the ORACLE_HOME environment variable. You must be in the correct ORACLE_HOME location to make sure you’re running the command for the appropriate instance.  

{mospagebreak title=How to Monitor the Oracle HTTP Server}

You can view the following types of Oracle HTTP Server metrics using the Application Server Control.

Status Metrics    The OHS Status metrics show you a summary of the memory usage, CPU usage, connection rates, and error rates for the server.

exam watch:   Oracle recommends that you use the Application Server Control page to modify the Oracle HTTP Server configuration, rather than directly edit the httpd.conf file.  

Response and Load Metrics   Response and Load Metrics provide an overall picture of server performance. The Response metrics show the average number of requests submitted and the length of time the server took to respond to the user’s requests. The Load metrics show the average number of bytes of data processed with the requests. Of course, large loads will result in a slower response time.

Module Metrics    The module metrics for the HTTP Server show the current response times for the various HTTP modules.

Server Properties Page

You can view and modify basic OHS settings from the Server Properties page, which can be reached in the following way:

  1. Navigate to the relevant Application Server Control HTTP Server home page. 
  2. Click the Administration tab, which will take you to the Administration page. 
  3. On the Administration page, click Server Properties.


Here’s a brief summary of the Oracle HTTP Server settings you can view and modify from the Server Properties page:

General Settings

In the General section of the Server Properties page, you can view general OHSsettings. You can also modify the following settings from here:

  • Document root location    You can specify a relative path or an absolute path for the document root location, with the relative path being relative to the ServerRoot directory specified in the configuration file. 
  • Administrator E-Mail   All error messages to users contain the Administrator E-mail address to be used by the HTTP Server. 
  • User and group settings   You can modify the initially chosen values for the user and group directives in the httpd.conf configuration file.
  • Listener addresses and ports   Using this section, you can do the following:

    • Change the default port setting for the HTTP Server. 
    • Add, remove, or change a current listening address or port.

Note that the Listening Addresses/Ports table contents are the same as the contents of the Listen directive in the OHS Server configuration file ( httpd.conf ).

Error Log and Access Log Settings

You can view the error logs and the access logs and change their settings from the Logging section of the Server Properties page. You can perform the following tasks from here:

  • Change an error log or access log filename or location. 
  • Set the logging level for the error logs.
  • Set the IP Address Translation type. 
  • Add and remove an access log file. 
  • Change the log format of an access log file.

Client Request Handling Settings

The Client Request Handling Settings section shows information about various client request settings, such as the following:

  1. Maximum Requests Processed Simultaneously   You use this to limit the number of simultaneous user requests, and the value seen here is the same as the settings specified for the MaxClients directive (UNIX) and the ThreadsPerChild directive (Windows).
  2. Request Timeout    This value is the same as the Timeout directive setting.
  3. Limit Requests Handled by Each Child Server Process    This value is the same as the setting of the configuration directive MaxRequestsPerChild on UNIX hosts and is unavailable on Windows hosts.

Client Connection Settings

The Client Connection Settings section shows you various client connection settings such as the following:

  • Allow Multiple Requests per Connection   This value is equivalent to the setting for the KeepAlive directive.
  • Connection Timeout    This specifies the number of seconds an idle connection will remain open, and its value is equivalent to the KeepAliveTimeout directive setting.
  • Limit Requests per Connection    This specifies the maximum simultaneous requests per connection, and its value is equivalent to the setting of the MaxKeepAliveRequests directive.

{mospagebreak title=Using Oracle HTTP Server Log Files}

As mentioned previously, all OHS Server log files are stored in the $ORACLE_ HOME/Apache/Apache/logs directory. Here’s a summary of the different types of log files in this directory: 

  • file   There is a single file, in which the OHS Server stores the process ID (PID) of the parent server process. The PID is usually a four-digit number, and you may need it for restarting or terminating the parent process on a UNIX system. You can change the name of this file using the PidFile directive described previously. 
  • error_log   The error log contains OHS Server errors, and you can change the name of this file with the ErrorLog configuration directive. The error log is a critical file, because it’s the first place you look when you have OHS Server performance problems. Here’s a typical line in the error_log file on a Windows server:

[Mon Jul 18 16:24:13 2005] [error] [client]
 [ecid: 1121721846:,0] mod_plsql: /pls/orasso/htp.p HTTP-503 ORA-12154 Proxy log On failed.
Please verify that you have specified correct connectivity information
 i.e. username, password & connect-string in the DAD

on the job:   You can access the error logs and the access logs using Application Server Control by going to the Server Properties page from the Oracle HTTP Server home page.

  • access_log   This file contains a detailed account of all accesses to the OHS Server, including items such as the remote host name, remote user, time, request, bytes transferred, and so forth. You can change the name of this file using the TransferLog server level configuration or the virtual host directive. You use the same arguments for TransferLog as for Custom Log. However, you can’t specify the log format explicitly. You also can’t specify conditional logging of client requests. OHS simply determines the log format by using the last used LogFormat directive settings that didn’t define a nickname. If no other format is specified, the Common Log Format (CLF) is used.

The access log information is vital in generating server usage reports. Here’s a sample line from an error_log
file: – - [10/Nov/2005:11:51:24 -0500]
  "GET /ohs_images/figure1.gif HTTP/1.1" 200 18752

For every 10,000 requests, the access log grows by about 1MB. If your access log gets very big, you shouldn’t try to remove it or move it. You should, instead, reset the log files by first moving the log file and then telling the OHS Server to reopen the log file, as shown here:

  $ mv access_log access_log.old
  $ kill -1 ‘cat

This two-step procedure will keep the access log size under control, and it backs up the access files at the same time.

  • ssl_engine_log and ssl_request_log   These error logs contain messages from the SSL connection requests. The files are created when you start OHS in the SSL mode, and the SSLLog directive is enabled in the server or virtual host

By default, all log files are in the standard Common Log Format (CLF), but you can change the format using the LogFormat and CustomLog directives, and you can control both the content of the log file and its format. The CLF format is:

  LogFormat "%h %l %u %t "%r" %>s %b" common

The preceding CLF format corresponds to the following:

  host ident authuser date request status bytes

The LogLevel Directive

The LogLevel directive in the httpd.conf configuration
file determines the verbosity of the error messages in the various error logs you saw earlier. By changing the LogLevel directive setting, you control the output in the log files. Here are the possible settings for the LogLevel directive:

  1. Emerg refers to a system emergency, where immediate action is needed.
  2. Crit refers to a critical condition.
  3. Error is an error condition.
  4. Warn is a warning condition.
  5. Notice is a normal but noteworthy event.
  6. Info refers to an informational message.
  7. Debug is a debugging message.

Note that setting the error logging level to Notice, Informational, or Debug typically produces numerous trivial informational messages.

{mospagebreak title=CERTIFICATION OBJECTIVE 5.03: OHS Configuration Directives}

As was mentioned previously in this chapter, you can classify OHS directives into classes or groups based on the context in which they can be used. A context indicates where in the server’s configuration files a directive is considered legal. You can have directives that have either a server configuration, a virtual host, a directory, or an htaccess context. Remember that all directives are legal only in their specified contexts–if you use them in the wrong contexts, you’ll get errors or the HTTP Server may even fail to start. You’ve learned about the key administrative and other OHS configuration directives earlier. Let’s delve a little deeper into the application of the OHS configuration directives in various contexts and see how the OHS merges the directives when necessary.

The Server Configuration Context

The server configuration context applies to all directives inside the httpd.conf file unless they are part of any type of a container. Containers are arbitrary sections of the OHS that limit the scope of the OHS configuration directives–for example, to only a certain directory, file, or URL. This means that the scope of server context directives that fall within a container will be limited to the containers’ sphere of influence.

If you place any OHS directive in the httpd.conf file, it will automatically apply to the entire OHS Web server. However, there may be cases in which you want certain directives to apply only to part of the server. You use OHS containers to limit the scope of the
configuration directives. The most important of these containers are the <VirtualHost>, <Directory>, <DirectoryMatch>, <Files>, <FilesMatch>, <Location>, and <LocationMatch>. For example, a directive placed within the container tags <Files> and </Files> within the httpd.conf file will apply only to a certain file system. Similarly, you can limit the scope of a directive to a certain URL, by enclosing the directive within the container tags <Location> and </Location>.  Containers thus help you to configure the OHS server at a decentralized level. Virtual hosting is a feature by which the OHS Web server serves multiple Web sites simultaneously. By using the <VirtualHost> container, you can limit the scope of a configuration directive to a certain Web site only.

Here are the various OHS containers, which are denoted by opening and closing tags before and after their names within the httpd.conf file. Remember that any directives that don’t fall into one of these containers will apply to the entire server.

  • <VirtualHost>    You can use the <VirtualHost> directives to serve multiple Web sites from a single server. This Virtual Host context specifies that a directive can appear inside <VirtualHost> containers in the server configuration files. The virtual host sections directives apply only to specific virtual hosts identified by a specific IP address–IP port pair. I’ll explain the <VirtualHost> container in the section titled Virtual Host Context, later in this chapter.
  • <Directory> and <DirectoryMatch>   These containers or sections contain directives applicable to particular directories.
  • <File> and <FileMatch>    These containers or sections contain directives applicable only to certain files.
  • <Location> or <LocationMatch>    These containers or sections contain directives applicable to particular URLs.

The various OHS container directives are examined in more detail in the following subsections. Note that the container directives always have HTML-type opening and closing tags surrounding the directives they enclose, as, for example, in <Directory>, </Directory>.

Virtual Host Context

OHS can serve multiple Web sites simultaneously, using a feature known as Virtual Hosting. If you place directives inside a <VirtualHost> container, they will apply only to requests from specific Web sites.The virtual host context specifies that a directive can appear inside <VirtualHost> containers in the server configuration files. The virtual host sections directives apply only to specific virtual hosts identified by a specific IP address–IP port pair. Virtual hosts and the use of the <VirtualHost> container are explained in more detail later in this chapter, in the section on virtual hosting.

Please check back next week for the continuation of this article.

Google+ Comments

Google+ Comments