通常 Nginx 的访问日志和错误日志在 /var/log/nginx/ 目录下：
cd /var/log/nginx/
同时 Nginx 支持自动切割并压缩日志, 访问日志以 access.log.[数字].gz 格式命名, 错误日志以 error.log.[数字].gz 格式命名, 默认是每天都会产生访问日志和错误日志的 .gz 文件。
通过 ls -l 命令查看 /var/log/nginx/ 目录下的文件创建时间：
Nov 2 22:18 access.log
Nov 1 23:59 access.log.1
Oct 23 23:36 access.log.10.gz
Oct 22 23:48 access.log.11.gz
Oct 21 23:50 access.log.12.gz
Oct 20 23:55 access.log.13.gz
Oct 19 23:35 access.log.14.gz
Oct 31 23:59 access.log.2.gz
Oct 30 23:51 access.log.3.gz
Oct 29 23:59 access.log.4.gz
Oct 28 23:47 access.log.5.gz
Oct 27 23:38 access.log.6.gz
Oct 26 23:41 access.log.7.gz
Oct 25 23:45 access.log.8.gz
Oct 24 23:46 access.log.9.gz
Nov 2 22:11 error.log
Nov 1 21:16 error.log.1
Oct 23 22:50 error.log.10.gz
Oct 22 10:37 error.log.11.gz
Oct 21 12:21 error.log.12.gz
Oct 20 22:52 error.log.13.gz
Oct 19 17:03 error.log.14.gz
Oct 31 10:48 error.log.2.gz
Oct 30 23:43 error.log.3.gz
Oct 29 16:50 error.log.4.gz
Oct 28 21:02 error.log.5.gz
Oct 27 18:05 error.log.6.gz
Oct 26 17:35 error.log.7.gz
Oct 25 20:11 error.log.8.gz
Oct 24 23:30 error.log.9.gz
可以看到 access.log 是当天的访问日志, 可以看到 error.log 是当天的错误日志。然后 .log.[数字] 中的数字表示倒退几天, 比如 error.log.1 是昨天 (1天前) 的日志、error.log.2.gz 是前天 (2天前) 的日志、error.log.3.gz 是大前天 (3天前) 的日志, 以此类推。可以得知 Nginx 最多可以保存 15 天的日志。
下载日志目录
为了能把日志文件下载到本地查看, 我们可以将 /var/log/nginx 设置权限为所有人都可以操作：
sudo chmod 644 /var/log/nginx
ls -l /var/log
确认 /var/log/nginx 的权限变成 drwxrwxrwx 后, 我们就可以通过 SFTP 等工具将 /var/log/nginx 目录打包下载到本地，并进行后续的分析。
汇总日志目录
然后本地的 /nginx 目录下, 创建一个 nginx_log.py 文件, 文件的代码如下：
import os
import gzip
def decompress_files(directory: str = '.'):
"""
解压目录下的.gz压缩文件为原始文件
:param directory: 目录路径
"""
# 遍历目录下所有文件
for filename in os.listdir(directory):
filepath = os.path.join(directory, filename)
# 判断文件是否为.gz压缩包
if filepath.endswith('.gz'):
# 解压缩.gz压缩包
with gzip.open(filepath, 'rb') as f_in:
uncompressed_filepath = filepath[:-3] # 去掉.gz后缀
with open(uncompressed_filepath, 'wb') as f_out:
f_out.write(f_in.read())
def merge_nginx_log_files(filter_condition, merged_file_path, directory: str = '.'):
"""
合并访问日志文件
:param filter_condition: 筛选日志文件的文件名前缀
:param merged_file_path: 存储合并后文件的路径
:param directory: 存储日志文件的目录
"""
# 获取目录下所有以 filter_condition 开头的文件
files = [f for f in os.listdir(directory) if f.startswith(filter_condition) and not f.endswith('.gz')]
# 打开一个新文件，用于存储合并后的内容
merged_file = open(merged_file_path, 'w')
# 遍历每个文件，将内容写入合并后的文件
for file in files:
with open(os.path.join(directory, file), 'r', encoding='utf-8') as f:
merged_file.write(f.read())
# 关闭合并后的文件
merged_file.close()
if __name__ == '__main__':
decompress_files()
merge_nginx_log_files('access.log', 'merged_access.log')
merge_nginx_log_files('error.log', 'merged_error.log')
这个脚本做了三件事情：
- 将当前目录下的
.gz压缩文件全部解压 - 将全部
access.log*前缀的文件合并为新的merged_access.log文件 - 将全部
error.log*前缀的文件合并为新的merged_error.log文件
这样我们只需通过 merged_access.log 文件就可以查看最近15天的全部访问日志, 通过 merged_error.log 文件就可以查看最近15天的全部错误日志。
分析问题
以我遇到的服务频繁出现 504 Gateway Time-out 问题的排除为例, 从 merged_error.log 文件看到错误日志里有下面两种异常：
upstream timed out (110: Unknown error) while reading response header from upstream
upstream timed out (110: Unknown error) while reading upstream
然后就知道 504 Gateway Time-out 的真实原因有两个：
- Nginx代理服务 从上游 读取响应标头时 超时
- Nginx代理服务 读取上游数据时 超时
因为我的 Nginx 和应用服务是部署在同一台服务器上的, 首先可以排除网络问题, 那就只剩下一个可能, 就是应用服务中的请求获取的数据比较多, 或者后端处理该请求花费的时间较长。
这样问题就找到了, 那现在有两个解决方案：
- 对该接口的处理逻辑代码进行优化, 或者减少请求响应中的数据包大小, 这里根据实际情况来判断
- 通过调整 Nginx 的配置将超时时间设置长些
第一个方案不可行, 因为我这个接口是调用第三方 OpenAI 的实时流数据, 这个接口本质上就是个中间商, 所以就只能用第二个方案, 即调整 Nginx 的配置。
具体是 Nginx 的 proxy_read_timeout 参数, 这个参数值指的是从上游服务器两次成功 (响应标头、响应内容) 的读操作耗时的超时时间, 也就意味着从上游服务器成功读操作后, 过了多长时间没有再从上游服务器成功读操作的话, 就会关闭该连接。默认值是 60s, 我们可以设置为 240s 或者更长, 来应对上游服务器处理请求慢的问题。
