I was interested in having nginx log 404s to their own file.
Essentially, i hate 404s, so I like to parse access logs find and
report all 404s. However, as-is, parsing large access logs can be quite
inefficient since 404s represent such a small % of the entire file. I
was thinking nginx could filter it out at write-time:
access_log not_found.log combined buffer=16K 404;
Apologies for the lameness of the code, but this is what I came up
with:
I certainly don’t recommend anyone uses it, I’m mostly just looking for
feedback. Is this better off in its own module? (there’s so much code in
the http_log_module that I want to leverage though). There’s much more
filtering that could go on that perhaps a new directive is a better
approach:
access_log_filter $status /(40\d)/
access_log_filter $method GET
The documentation http://wiki.nginx.org/HttpCoreModule#error_page also
says that if you don’t want to redirect to another page, you can use a
named redirection :
location / {
error_page 404 @404;
}
location @404 {
access_log /path/to/log;
}
The wiki syntax seems to be wrong though, since it is using brackets and
not braces.
On Tue, Jun 12, 2012 at 06:08:28PM -0400, B.R. wrote:
The documentation http://wiki.nginx.org/HttpCoreModule#error_page also
says that if you don’t want to redirect to another page, you can use a
named redirection :
location / {
error_page 404 @404;
}
location @404 {
access_log /path/to/log;
}
This will cause another 404 as written.
Note well that named location are really needed only if you don’t
want internal redirect to happen, i.e. want to preserve original
uri (e.g. for an additional processing as in various fallback
schemes) and/or really can’t touch uri namespace for some reason.
much better!