One of the features I like in nginx is the ability to disable logging for certain paths. For example whenever a browser sends a requests for a favicon.ico which doesn't exists the web server will respond with a 404 error but will also write the request to access_log and error_log -- which is totally useless. Most of the time nobody cares about these favicon and apple-touch-icon requests, so logging them is quite useless and is just a waste of CPU cycles and IO throughput.
If you use nginx is quite easy to disable logging for them with something like
location = /favicon.ico {
access_log off;
log_not_found off;
}
But Apache is more tricky to set up, the log configuration is not very straightforward. So here is what I was able to find on this subject after some hours of searching.
The method I liked the most was found in the article "Excluding common requests from your Apache logs" and suggests setting ENV variables for requests you don't want to log and then exclude them from logging using those variables. It looks like this:
## flag favicon requests SetEnvIf Request_URI "^/favicon\.ico$" favicon-request=nolog CustomLog /var/www/log/general-access.log vcommon env=!do_not_log
The server I'm managing runs Plesk and there is no easy way to overwrite CustomLog directive, so I have to live with those entries for the moment and keep this in mind for the future.
If you go with the method above you will notice that it doesn't fix the file not found error from error_log. In order to fix that you will have to use one of the following methods.
Serve a custom 404 page following the instructions from "Stopping favicon 404 spam in Apache error logs"
Redirect 404 /favicon.ico
<Location /favicon.ico>
ErrorDocument 404 "favicon does not exist"
</Location>
But this is quite verbose and I went for something more flexible:
Redirect gone /favicon.ico RedirectMatch gone ^/apple-touch-icon
Based on this comment on serverfault question which also gives the following explanation:
Apache always logs 404s as errors, even from a Redirect, and even if you handle them using an ErrorDocument. But it doesn't for 410 (gone), which seems an equally acceptable description of the situation.
Now my error logs are clean and more meaningful -- a pleasure to monitor/debug.
Comments