Nginx的日志功能
1. Nginx日志功能介绍
通常,在生产环境中使用 Nginx 进行反向代理和负载均衡或者各种其他处理时,良好的日志记录是非常关键的一环。通过精心配置的 Nginx 日志,我们可以获取用户的真实 ip、浏览器信息,请求处理时间,请求URL等,这样方便我们排查和回溯错误。具体要记录哪些信息,可以通过 Nginx 中的 log_format 指令定义,由它定义日志的格式。而对于使用哪种日志格式和设置日志的保存路径则由 access_log 指令指定的。另外在 Nginx 中还有一个配置服务器和请求处理过程中的错误信息的指令,那就是 error_log指令。最后,如果在配置的日志文件路径中使用了变量,我们可以通过open_log_file_cache指令来设置缓存,提升性能。对于大型的网站而言,大量的 http 请求意味着大量的日志记录,及时按天或按大小进行 Nginx 日志备份也至关重要的。
在 Nginx 的日志模块主要有2个, ngx_stream_log_module 和 ngx_http_log_module,分别表示四层的日志模块和七层的日志模块,其指令和用法都是一致的,接下来我们只针对 http 请求的日志进行说明和使用。
2. 日志相关指令说明
在 ngx_http_log_module 模块中,只3个指令,分别是 access_log、log_format 和 open_log_file_cache。这些指令具体的格式如下:
Syntax: access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
access_log off;
Default: access_log logs/access.log combined;
Context: http, server, location, if in location, limit_except
Syntax: log_format name [escape=default|json|none] string ...;
Default: log_format combined "...";
Context: http
Syntax: open_log_file_cache max=N [inactive=time] [min_uses=N] [valid=time];
open_log_file_cache off;
Default: open_log_file_cache off;
Context: http, server, location
ngx_http_log_module 模块用来按某个格式来记录请求的日志。模块中的 log_format 指令就是用来设置打印日志的格式,该指令中可以使用 Nginx 中的各种变量,比如保存远端ip地址的变量$remote_addr等。一个简单的示例如下:
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
接下来是 access_log 指令。参考前面的指令格式。关闭日志记录,直接是写access_log off
,如果打开 access 日志,它的写法是:
access_log path [format [buffer=size] [gzip[=level]] [flush=time] [if=condition]];
- path 是指定日志的写入路径,默认写入 logs/access.log 文件中。注意日志路径可以包变量,但是会一些限制。
- format 就是指定打的日志格式,也就是前面 log_format 指令定义好的格式。每个格式会设置一个格式名,这里取对应的格式名称,默认使用预定义的combined。
- buffer 用来指定日志写入时的缓存大小。默认是64k。
- gzip 日志写入前先进行压缩。压缩率可以指定,从1到9数值越大压缩比越高,同时压缩的速度也越慢。默认是1。
- flush 设置缓存的有效时间。如果超过flush指定的时间,缓存中的内容将被清空。
- if 条件判断。如果指定的条件计算为0或空字符串,那么该请求不会写入日志。
access_log 指令示例:
# 确保 Nginx 源码编译时安装了zlib库
access_log /path/to/log.gz combined gzip flush=5m;
map $status $loggable {
~^[23] 0;
default 1;
}
# if条件判断, 如果请求的相应码是2xx或者3xx,那么$loggable变量为0,这样请求日志不会被打印
access_log /path/to/access.log main if=$loggable;
每一条日志记录的写入都是先打开文件再写入记录,然后关闭日志文件。如果你的日志文件路径中使用了变量,如access_log /var/logs/$host/access.log
,为提高性能,可以使用 open_log_file_cache 指令设置日志文件描述符的缓存。可以通过open_log_file_cache off
关闭该缓存。该指令的几个参数选项说明如下:
- max: 设置缓存中最多容纳的文件描述符数量,如果被占满,采用LRU算法将描述符关闭。
- inactive: 设置缓存存活时间,默认是10s。
- min_uses: 在inactive时间段内,日志文件最少使用几次,该日志文件描述符记入缓存,默认是1次。
-
valid: 设置多久对日志文件名进行检查,看是否发生变化,默认是60s。
open_log_file_cache max=100 inactive=15s valid=1m min_uses=2;
最后 error_log 是 错误日志配置指令,主要记录客户端访问 Nginx 出错时的日志,它不不支持自定义日志格式。通过检查错误日志,可以快速定位线上问题,所以也是很重要的。关闭错误日志的方式和 access_log不一样,没有error_log off
这样关错误日志的用法,反而会将错误日志打到名为 off 的文件中。常用的关闭方式是:
error_log /dev/null;
就像在 Linux 系统中,输出到 /dev/null 的内容实际上等价于丢弃一样。
3. Nginx 日志切割
Nginx 的日志切割实现的核心是使用 nginx 命令的 reopen 参数实现,该参数的含义是重新开始记录日志文件。人工切的做法就是凌晨将日志备份,然后执行带reopen参数的命令:
# 备份相关的日志
[root@server sbin] mv ../logs/access.log ../logs/bak/access-2020-02-04.log
[root@server sbin] mv ../logs/error.log ../logs/bak/error-2020-02-04.log
[root@server sbin] ./nginx -s reopen
执行后会重新生成 access.log 和 error.log,这就是手工切割的方式。通常我们会用 shell 脚本和定时任务来帮我我们完成自动切割。首先准备如下的 shell 脚本,它完成日志的备份以及给 nginx 进程发生 reopen 信号。
#!/binbash
NGX_DIR=/root/nginx
NGX_LOG_PATH=$NGX_DIR/logs
NGX_LGO_BAK_PATH=/var/log/ngx_log_bak
YESTERDAY=$(date -d "yesterday" +%Y-%m-%d)
mv ${NGX_LOG_PATH}/access.log ${NGX_LGO_BAK_PATH}/access-${YESTERDAY}.log
mv ${NGX_LOG_PATH}/error.log ${NGX_LGO_BAK_PATH}/error-${YESTERDAY}.log
# 想 Nginx 主进程发生 USR1 信号,等价于 -s reopen 选项,重新打开日志文件
kill -USR1 ${NGX_DIR}/log/nginx.pid
接下来,只要将这个脚本加入到 crontab 中即可,如下操作:
$ crontab -e
# 上面打开的页面中输入如下行:
0 0 * * * /root/nginx/nginx_log_rotate.sh
# 查看定时任务
$ crontab -l
0 0 * * * /root/nginx/nginx_log_rotate.sh
4. 案例演示
我们在 nginx.conf 中添加如下的日志配置:
...
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
map $status $loggable {
~^[34] 0;
default 1;
}
access_log logs/access.log main if=$loggable;
server {
listen 8000;
return 200 '8000, server\n';
}
server {
listen 8001;
return 300 '8001, server\n';
}
server {
listen 8002;
return 401 '8002, server\n';
}
...
}
...
这里我们综合了前面涉及的知识,这里只简单测试日志配置中 if 功能。我们设置请求的相应码为 3xx 和 4xx 时,日志不会记录。接下来,启动或者热加载 Nginx, 然后分别对应三个端口发送 http 请求并观察 access.log 日志:
[shen@shen ~]$ curl http://180.76.152.113:8000 -I
HTTP/1.1 200 OK
Server: nginx/1.17.6
Date: Tue, 04 Feb 2020 13:31:03 GMT
Content-Type: application/octet-stream
Content-Length: 13
Connection: keep-alive
[shen@shen ~]$ curl http://180.76.152.113:8001 -I
HTTP/1.1 300
Server: nginx/1.17.6
Date: Tue, 04 Feb 2020 13:31:06 GMT
Content-Type: application/octet-stream
Content-Length: 13
Connection: keep-alive
[shen@shen ~]$ curl http://180.76.152.113:8002 -I
HTTP/1.1 401 Unauthorized
Server: nginx/1.17.6
Date: Tue, 04 Feb 2020 13:31:08 GMT
Content-Type: application/octet-stream
Content-Length: 13
Connection: keep-alive
# 到 Nginx 主机上观察 access.log 日志,发现只有响应码为200的请求记录了日志
[root@server nginx]# tail -f logs/access.log
171.82.186.225 - - [04/Feb/2020:21:33:24 +0800] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.29.0" "-"
5. 小结
本小节我们介绍了 log 相关的指令,包括访问日志和错误日志的指令。此外还介绍了 Nginx 中对日志切割的常用处理方法,这也是生产环境上使用日志备份的手段。
最新评论
Spring Cloud Alibaba 微服务架构实战 https://pan.baidu.com/s/1jF5voFRoeF0lYAzAPBWSbw?pwd=chqk
命令: nload
真是个良心站点哇,大公无私,爱了爱了
还可以直接搞一张映射表,存 uid | time | source_index, 第一次直接查对应的 time 选出前100, 第二次直接用 CompleteFuture 去分别用 source_in
干得漂亮,多个朋友堵条路
2021.2.2版本的不适用吧
现在还可以用么
激活码有用,感谢分享