if ($time_iso8601 ~ “^(\d{4})-(\d{2})”) {
set $year $1;
set $month $2;
}
access_log …/access-$year-$month.log combined;
However, with nginx/1.4.6 (Ubuntu) I see that for invalid HTTP requests
$year and $month are not set. For example, with the above config after
issuing from a shell:
~> printf foo | nc host 80
I see in the error log for nginx:
2014/11/29 21:28:57 [warn] 8#0: *18 using uninitialized “year” variable
while logging request, client: 172.17.42.1, server: localhost, request:
“foo”
2014/11/29 21:28:57 [warn] 8#0: *18 using uninitialized “month” variable
while logging request, client: 172.17.42.1, server: localhost, request:
“foo”
That leads for the log file named .access–.log
Is it because $time_iso8601 is only set for valid request? If so, is
this
just a bug or a feature?
Or, better, avoid using such “timestamped log names” at all as
this approach implies unneeded overhead on opening/closing files
for each request. It is much more efficient to use normal log
rotation instead, see here:
avoid using such “timestamped log names” at all as this approach implies
unneeded overhead on opening/closing files for each request.
I use open_log_file_cache to mitigate this. Are there still problems
with
that? I would prefer to keep things simple and avoid explicit log
rotation.
The latter requires in my case more setup over a simple Docker container
with just nginx and extra log processing to extract monthly logs to feed
those to webalizer.
that? I would prefer to keep things simple and avoid explicit log rotation.
The latter requires in my case more setup over a simple Docker container
with just nginx and extra log processing to extract monthly logs to feed
those to webalizer.
If you’re using Docker, use the Docker log collector, use the syslog
patch for nginx and have it log externally, or create a volume for the
logs and a helper container in which you run the log tools. It really
should not be nginx’s or its container’s job to manage/rotate logs.
On Mon, Dec 01, 2014 at 08:23:53AM -0500, igorb wrote:
avoid using such “timestamped log names” at all as this approach implies
unneeded overhead on opening/closing files for each request.
I use open_log_file_cache to mitigate this. Are there still problems with
that? I would prefer to keep things simple and avoid explicit log rotation.
While open_log_file_cache mitigates most of the overhead involved,
this still implies constructing a log file name for each request,
looking up this name in the cache and so on. It’s still better to
use explicitly specified log file names.
If you’re using Docker, use the Docker log collector, use the syslog patch for
nginx and have it log externally, or create a volume for the logs and a helper
container in which you run the log tools. It really should not be nginx’s or
its container’s job to manage/rotate logs.
