Using Oracle HTTP Server Log Files - Oracle

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: 

• httpd.pid file   There is a single httpd.pid 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 172.16.14.15]
 [ecid: 1121721846:172.16.14.15:5940:7412:3,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:

  172.16.14.15 - - [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 httpd.pid '

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
  configuration.

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.