Where is apache web server log file

During testing, it is often useful to continuously monitor the error log for any problems. On Unix systems, you can accomplish this using:. The LogLevel directive allows you to specify a log severity level on a per-module basis.

In this way, if you are troubleshooting a problem with just one particular module, you can turn up its logging volume without also getting the details of other modules that you're not interested in.

Do this by specifying the name of the module in your LogLevel directive:. The server access log records all requests processed by the server. The location and content of the access log are controlled by the CustomLog directive.

The LogFormat directive can be used to simplify the selection of the contents of the logs. This section describes how to configure the server to record information in the access log. Of course, storing the information in the access log is only the start of log management. The next step is to analyze this information to produce useful statistics.

Log analysis in general is beyond the scope of this document, and not really part of the job of the web server itself. For more information about this topic, and for applications which perform log analysis, check the Open Directory.

The CustomLog directive now subsumes the functionality of all the older directives. The format of the access log is highly configurable.

The format is specified using a format string that looks much like a C-style printf 1 format string. Some examples are presented in the next sections. This defines the nickname common and associates it with a particular log format string. The format string consists of percent directives, each of which tell the server to log a particular piece of information. Literal characters may also be placed in the format string and will be copied directly into the log output. The quote character " must be escaped by placing a backslash before it to prevent it from being interpreted as the end of the format string.

The CustomLog directive sets up a new log file using the defined nickname. The filename for the access log is relative to the ServerRoot unless it begins with a slash. This standard format can be produced by many different web servers and read by many log analysis programs.

The log file entries produced in CLF will look something like this:. Another commonly used format string is called the Combined Log Format. It can be used as follows. This format is exactly the same as the Common Log Format, with the addition of two more fields. The access log under this format will look like:. Multiple access logs can be created simply by specifying multiple CustomLog directives in the configuration file. For example, the following directives will create three access logs.

The first contains the basic CLF information, while the second and third contain referer and browser information. This example also shows that it is not necessary to define a nickname with the LogFormat directive.

Instead, the log format can be specified directly in the CustomLog directive. There are times when it is convenient to exclude certain entries from the access logs based on characteristics of the client request. This is easily accomplished with the help of environment variables. First, an environment variable must be set to indicate that the request meets certain conditions.

This is usually accomplished with SetEnvIf. Some examples:. As another example, consider logging requests from english-speakers to one log file, and non-english speakers to a different log file. In a caching scenario one would want to know about the efficiency of the cache. A very simple method to find this out would be:. In that case a cache hit will log - , while a cache miss will log 1.

In other cases, a literal "-" will be logged instead. Likewise, in the second example, the Referer will be logged if the HTTP status code is not , , or Some examples:.

As another example, consider logging requests from english-speakers to one log file, and non-english speakers to a different log file. Although we have just shown that conditional logging is very powerful and flexibly, it is not the only way to control the contents of the logs. Log files are more useful when they contain a complete record of server activity.

It is often easier to simply post-process the log files to remove requests that you do not want to consider. On even a moderately busy server, the quantity of information stored in the log files is very large. The access log file typically grows 1 MB or more per 10, requests. It will consequently be necessary to periodically rotate the log files by moving or deleting the existing logs.

This cannot be done while the server is running, because Apache will continue writing to the old log file as long as it holds the file open. Instead, the server must be restarted after the log files are moved or deleted so that it will open new log files. By using a graceful restart, the server can be instructed to open new log files without losing any existing or pending connections from clients. However, in order to accomplish this, the server must continue to write to the old log files while it finishes serving old requests.

It is therefore necessary to wait for some time after the restart before doing any processing on the log files. A typical scenario that simply rotates the logs and compresses the old logs to save space is:.

Another way to perform log rotation is using piped logs as discussed in the next section. Apache httpd is capable of writing error and access log files through a pipe to another process, rather than directly to a file.

This capability dramatically increases the flexibility of logging, without adding code to the main server. In order to write logs to a pipe, simply replace the filename with the pipe character " ", followed by the name of the executable which should accept log entries on its standard input.

Apache will start the piped-log process when the server starts, and will restart it if it crashes while the server is running. This last feature is why we can refer to this technique as "reliable piped logging".

Piped log processes are spawned by the parent Apache httpd process, and inherit the userid of that process. This means that piped log programs usually run as root. It is therefore very important to keep the programs simple and secure. Notice that quotes are used to enclose the entire command that will be called for the pipe. Although these examples are for the access log, the same technique can be used for the error log.

One important use of piped logs is to allow log rotation without having to restart the server. For example, to rotate the logs every 24 hours, you can use:. A similar, but much more flexible log rotation program called cronolog is available at an external site. As with conditional logging, piped logs are a very powerful tool, but they should not be used where a simpler solution like off-line post-processing is available.

When running a server with many virtual hosts , there are several options for dealing with log files. First, it is possible to use logs exactly as in a single-host server. This technique does not allow for easy collection of statistics on individual virtual hosts. Any virtual host which does not have logging directives will still have its requests sent to the main server logs. This technique is very useful for a small number of virtual hosts, but if the number of hosts is very large, it can be complicated to manage.

In addition, it can often create problems with insufficient file descriptors. For the access log, there is a very good compromise.

Since the real power of log data comes from comprehending the meaning of the data through analysis, I will also discuss the benefits of working with a log management and analytics platform such as Sumo Logic to derive valuable insights from access log data.

This particular log file is responsible for recording data for all requests processed by the Apache server. So if an individual visits a webpage on your site, the access log file will contain details regarding this event. This information is valuable in a variety of situations: for example, if a common request is failing for each individual trying to get to a particular web page, the link may be pointing to a page that no longer exists; if a certain page on the site is taking longer than it should to load, log entries could indicate SQL queries that could be refactored to improve performance; if one particular page on the site is very popular, aggregating data from access logs could shine a light on commonly requested resources, thus enabling businesses to increase their popularity by providing more related content.

So, for the purposes of this article, we will stick to detailing where the Apache access logs can be found on a Linux machine. On the Ubuntu Linux distribution, for example, access log records will be written to the following location by default:. The default location may vary slightly on other Linux distributions, but you will not have to look very far in most cases. Ultimately, the location and format more on this later of the access logs are defined by a CustomLog directive which can be viewed and modified within your Apache HTTP server configuration.

Now that you know what Apache access logs are and where they can be found, we can explain how to interpret the entries so that your development team and other IT personnel can make good use of them. Making sense of the Apache access logs requires that the analyst understand the format in which the access logs are being recorded. As mentioned above, the format for the access logs is defined in the CustomLog directive along with the location.

We will take a look at two popular log formats that are often utilized with Apache access logs below. The Common Log Format is a standardized text file format used by various web servers in generating server log files. With an Apache HTTP server, the Common Log Format can be used to produce access logs that are straightforward enough for developers and administrators to read.

In addition, as it is a standardized format in use by multiple web servers, CLF-formatted log files can be easily used by many log analysis platforms. Another format that is often used with Apache access logs is the Combined Log Format. This format is very similar to the Common Log Format but contains a few extra fields to provide more information for use in analysis and debugging operations. An access log record that is recorded in the Combined Log Format looks something like this:.

As you can see, the first seven fields are identical to those in Common Log Format. The remaining fields represent two additional properties:.

Here, we defined the combined log format via the LogFormat directive, and we followed that up by defining the location and format combined for the access log using the CustomLog directive. As you can see, modifying the location or format of the access log is a straightforward process. In addition, the use of the CustomLog directive affords us several other capabilities that we will describe below.