Log location
Your apache web server log files are accessible at <SITE>/logs on the management server.
Logs available
The logs are read-only, so are safe from accidental editing. They use a log level of 'info', are rotated every day, and kept for 395 days. The latest two logs are uncompressed text, older ones are gzipped, so to view these you need to either extract them to a writeable location, or you can use tools such as zgrep / zcat / zless.
Log format
The error log is in standard apache format. Since the logs record any messages at 'info' level or higher, you may want to narrow down data by grepping for lines which do not contain [info]. Further details are available in the Apache loglevel documentation
The access log has been customised to include extra useful data. This logging format is:
%{%Y-%m-%d %H:%M:%S%z}t %h %V %u \"%r\" %>s %b
Field specifier |
Meaning |
---|
%{%Y-%m-%d %H:%M:%S%z}t |
Date in ISO 8601 format, a space, then the time and UTC offset |
%h |
IP address of the client
|
%V |
Hostname of the server. This is useful if you have more than one virtual host running within a single contract |
%u |
Username that the request has come from. For unauthenticated requests this will display as a hyphen |
\"%r\" |
First line of the request, with added surrounding double quotes |
%>s |
HTTP status code of the request, after any internal redirects have been done |
%b |
Size of the response in bytes, excluding headers |
Further details are available in the Apache mod_log_config documentation, and you may also wish to consult a
list of HTTP status codes. Note that 4xx error codes mean a problem with the site content or .htaccess settings, and should be solvable by you, whilst 5xx error codes could mean there is something wrong with the server.
Diagnostic example
An example of a recent problem that was diagnosed via log files involved a WordPress site that was migrated from a dedicated server to a hosted site running in a subdirectory. In order to maintain existing links, the site owner created a .htaccess file which re-wrote requests to include the new subdirectory. At this point the site started giving 500 errors.
The logs contained the following [error] level entry:
[Tue Feb 30 12:34:56 1970] [error] [client 127.0.0.1] Request exceeded
the limit of 10 internal redirects due to probable configuration error
. Use 'LimitInternalRecursion' to increase the limit if necessary. Use
'LogLevel debug' to get a backtrace
Which was enough information to realise that the .htaccess file was causing a re-write loop, and get it fixed.