从 Nginx 日志中分析问题

通常 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')

这个脚本做了三件事情：

1. 将当前目录下的 .gz 压缩文件全部解压
2. 将全部 access.log* 前缀的文件合并为新的 merged_access.log 文件
3. 将全部 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 的真实原因有两个：

1. Nginx代理服务 从上游 读取响应标头时 超时
2. Nginx代理服务 读取上游数据时 超时

因为我的 Nginx 和应用服务是部署在同一台服务器上的, 首先可以排除网络问题, 那就只剩下一个可能, 就是应用服务中的请求获取的数据比较多, 或者后端处理该请求花费的时间较长。

这样问题就找到了, 那现在有两个解决方案：

1. 对该接口的处理逻辑代码进行优化, 或者减少请求响应中的数据包大小, 这里根据实际情况来判断
2. 通过调整 Nginx 的配置将超时时间设置长些

第一个方案不可行, 因为我这个接口是调用第三方 OpenAI 的实时流数据, 这个接口本质上就是个中间商, 所以就只能用第二个方案, 即调整 Nginx 的配置。

具体是 Nginx 的 proxy_read_timeout 参数, 这个参数值指的是从上游服务器两次成功 (响应标头、响应内容) 的读操作耗时的超时时间, 也就意味着从上游服务器成功读操作后, 过了多长时间没有再从上游服务器成功读操作的话, 就会关闭该连接。默认值是 60s, 我们可以设置为 240s 或者更长, 来应对上游服务器处理请求慢的问题。