You've probably read (or heard) the fairy tale in which Hansel and Gretel left breadcrumbs to find their way back home. But, what on earth does this bedtime story have to do with the topic that I am currently discussing - the Apache log files?
Frankly, not much!
To be honest, it was an attempt to highlight the similar purpose of two diverse actions: the breadcrumbs dropped by the two characters in the fairy tale and the log files generated by the Apache Web server. The former ensures that the children (in the story) were able to return home safely after their escape and the latter allows a webmaster to learn more about the visitors based on the data (i.e. breadcrumbs) left behind after every visit to the website. And if thatís not enough, the error log files can help developers resolve nasty errors that occur on the server.
Generally speaking, Apache can be configured to generate two types of log files. The first records every request made to the Web server and the second logs all the errors encountered by the Web server such as the infamous "404 - File Not Found" error or the notorious "500 - Internal Server Error" and many more!
By default, the Apache Web server is configured to generate several versions of these log files, but only two are active when you start it for the first time. In order to give you a better picture, allow me to explain the first log-related configuration directive from the "http.conf" file:
As the name suggests, the "ErrorLog" directive allows you to specify the name of the "error" log file. This path can either be relative to the server root (as above) or represent the absolute path to the file on your system. Note that the default name (of the log file) will vary with the OS platform that you use; you can always modify it here.
Now, let us take a peek at the contents of the error log file generated by my local Apache instance:
[Sat Dec 18 15:11:54 2004] [error] [client 127.0.0.1] request failed: error reading the headers [Sat Dec 18 15:15:34 2004] [error] [client 127.0.0.1] File does not exist: /usr/local/apache/htdocs/library/styles.css
Now let's decipher these entries. The first value represents the date and time the error occurred, the second indicates the "error level" of the current entry (more on this later), the third column is the IP address of the client machine and finally, we have a message that attempts to describe the nature of the error. Note that the system location of the file, instead of its web path, is written into the log file.
The next directive de-mystifies the "error level" term used above. Aptly named "LogLevel," it can be assigned any one value from a pre-defined list and allows you to control the errors (based on their severity) that you wish to record in your "error" log file. Take a look:
# # LogLevel: Control the number of messages logged to the # error.log. # Possible values include: debug, info, notice, warn, # error, crit, alert, emerg. # LogLevel warn
I have deliberately copied the comments that precede this directive in the configuration file - you'll notice that they list the different values that you assign to the "LogLevel" directive. There is no doubt that the names of different error levels give a good indication of the nature of errors to be recorded for each level. It is generally recommended that you set this value to "debug" on development servers and to "error" on production ones.
Here's a little tip (excerpted from the official documentation) before we move to the next section: you can use the following command on most *NIX systems to monitor your error log file on a continuous basis: