DevOps知识中心
DevOps知识中心

精通 Nginx 日志分析以实现高效故障排除

通过精通 Nginx 访问和错误日志，实现高效故障排除。本指南详细介绍了如何配置自定义日志格式以捕获关键的计时指标，使您能够精确查明 Nginx 或上游应用服务器中的性能瓶颈。学习如何利用错误日志的严重性级别即时诊断 502 和 504 错误等关键问题，并利用强大的 Shell 命令（如 `grep`、`awk`）快速过滤、计数和分析流量模式。

60 浏览量

精通 Nginx 日志分析，实现高效故障排除

Nginx 是数百万个 Web 服务的关键入口点，处理从静态内容服务到复杂反向代理操作的一切事务。当性能下降或服务中断时，Nginx 生成的日志是唯一最重要的诊断工具。它们提供了每个请求和每次内部操作错误的精确历史记录。

掌握 Nginx 日志分析不仅仅是查看文件；而是要理解日志格式、识别关键变量，并使用高效的工具来关联事件和隔离根本原因。本综合指南将指导您解读 Nginx 日志，从而快速诊断出 502 错误、性能瓶颈和可疑流量模式等问题。

1. Nginx 日志基础知识：访问日志与错误日志

Nginx 维护两种截然不同的日志类型，每种都有其关键且独立的功能：

1.1 访问日志 (access.log)

访问日志记录了 Nginx 处理的每个请求的详细信息。它对于了解用户行为、监控流量和评估响应时间至关重要。

默认位置： 通常是 /var/log/nginx/access.log

用途： 跟踪客户端交互（成功请求、客户端错误 (4xx)）。

1.2 错误日志 (error.log)

错误日志记录了 Nginx 处理生命周期中发生的内部问题、操作失败和通信问题。此日志是排查后端连接问题和服务器配置错误的确定性来源。

默认位置： 通常是 /var/log/nginx/error.log

用途： 跟踪服务器端错误、警告和系统事件（5xx 错误、配置文件解析失败）。

错误日志的严重性级别

Nginx 使用八个严重性级别。在进行故障排除时，通常希望从 error 级别或更高开始。严重性级别使用 error_log 指令进行配置：

# 将最低严重性级别设置为 'warn'
error_log /var/log/nginx/error.log warn;
级别 描述 优先级
crit 严重情况（例如，系统故障） 最高
error 发生错误，阻止了请求的成功处理 高
warn 发生了意外情况，但操作仍在继续 中
notice 正常但重要的状况（例如，服务器重启） 低
info 信息性消息 最低

2. 定制访问日志以进行性能分析

默认的 Nginx 访问日志格式（通常称为 combined）很有用，但缺少关键的性能计时变量。要有效地排查性能慢的问题，您必须定义一个自定义格式，以捕获 Nginx 花费在处理请求上的时间和上游服务器花费的时间。

2.1 定义性能日志格式

使用 log_format 指令（通常在 nginx.conf 中定义）来创建自定义格式，例如 timing_log：

log_format timing_log '$remote_addr - $remote_user [$time_local] ' 
                    '"$request" $status $body_bytes_sent ' 
                    '"$http_referer" "$http_user_agent" ' 
                    '$request_time $upstream_response_time';

server {
    listen 80;
    server_name example.com;

    # 在此处应用自定义格式
    access_log /var/log/nginx/timing_access.log timing_log;
    # ... 配置的其余部分
}
变量 描述 故障排除价值
$request_time 从接收到第一个字节到发送最后一个字节所经过的总时间。 高值表示网络慢、Nginx 慢或后端慢。
$upstream_response_time 等待上游服务器（例如，应用程序服务器）响应所花费的时间。 此处的高值指明后端应用程序是瓶颈。
$status 返回给客户端的 HTTP 状态码。 对于过滤错误 (4xx, 5xx) 至关重要。

最佳实践： 考虑使用 JSON 日志格式。虽然手动阅读起来稍有难度，但 JSON 日志对于集中式日志管理系统（如 ELK 堆栈或 Splunk）来说，解析和分析起来非常简单，能显著提高故障排除速度。

3. 解读访问日志条目

使用自定义格式的典型条目可能如下所示（计时值添加在末尾）：

192.168.1.10 - - [10/May/2024:14:30:05 +0000] "GET /api/data HTTP/1.1" 200 450 "-" "Mozilla/5.0" 0.534 0.528

诊断：

  1. 状态码 (200)： 成功。
  2. 请求时间 (0.534s)： 总时间为半秒。
  3. 上游时间 (0.528s)： 几乎所有时间都花在了等待后端应用程序上（Nginx 开销花费的时间为 0.534 - 0.528 = 0.006s）。

结论： 后端应用程序是 500 毫秒延迟的来源。Nginx 配置本身是高效的。

使用状态码进行故障排除

状态码范围 含义 典型操作/日志来源
4xx (客户端错误) 客户端发送了无效或未经授权的请求。 检查访问日志中的高频出现情况。查找 404 Not Found（文件丢失）或 403 Forbidden（权限问题）。
5xx (服务器错误) Nginx 或上游服务器未能成功处理有效请求。 立即检查错误日志中对应的条目。
502 Bad Gateway Nginx 无法从上游应用程序获得响应。 错误日志将显示详细信息（连接被拒绝、超时）。
504 Gateway Timeout 上游服务器在配置的代理限制内响应时间过长。 错误日志将显示超时警告。调整 proxy_read_timeout。

4. 诊断错误日志中的关键问题

当请求导致 5xx 错误时，访问日志仅告诉您错误发生了。错误日志告诉您原因。

案例研究：502 Bad Gateway

当使用 Nginx 作为反向代理时，502 错误是最常见的问题之一。它几乎总是指向后端应用程序已停止、过载或无法访问。

请在错误日志中查找以下特定消息：

4.1 连接被拒绝（后端已停止）

这表明 Nginx 尝试连接到后端端口但没有程序在监听，意味着应用程序服务器（例如 PHP-FPM、Gunicorn）已停止或配置不正确。

2024/05/10 14:35:10 [error] 12345#0: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.10, server: example.com, request: "GET /test"
  • 操作： 重启后端应用程序服务器或检查其配置（端口/套接字设置）。

4.2 上游提前关闭连接（后端崩溃）

当 Nginx 建立连接但后端服务器在发送完整的 HTTP 响应之前终止连接时，就会发生这种情况。这通常暗示应用程序代码中存在致命错误或崩溃。

2024/05/10 14:38:22 [error] 12345#0: *2 upstream prematurely closed connection while reading response header from upstream, client: 192.168.1.10, server: example.com, request: "POST /submit"
  • 操作： 检查应用程序服务器的原生错误日志（例如 PHP-FPM 日志、Node.js 日志）以查找特定的致命错误。

警告： 如果 Nginx 在启动时无法读取其配置文件，错误通常会直接转储到标准错误或引导日志文件，而不是配置的 error.log 位置。如果 Nginx 无法启动，请务必检查 journalctl -xe 或系统日志。

5. 用于日志分析的实用 Shell 命令

虽然推荐在生产环境中使用强大的日志监控系统，但 Linux 命令行提供了强大的工具用于快速的实时故障排除。

5.1 实时监控

监控传入请求的日志（在部署修复或测试新功能后特别有用）：

tail -f /var/log/nginx/access.log
# 或者，仅针对错误
tail -f /var/log/nginx/error.log

5.2 过滤和计数错误

快速查找并统计过去一小时或一天内最频繁出现的 5xx 错误：

# 查找所有 5xx 请求
grep '" 50[0-9] ' /var/log/nginx/access.log | less

# 统计 5xx 错误的分布情况（例如，502s 与 504s 的数量）
grep '" 50[0-9] ' /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -nr

解释： awk '{print $9}' 隔离 HTTP 状态码（假设使用默认或 combined 日志格式，状态码是第 9 个字段）。

5.3 识别慢请求（需要自定义日志格式）

如果您已实现 timing_log 格式（其中 $request_time 是倒数第二个字段，在我们的示例中是第 16 个字段）：

# 查找最慢的 10 个请求（例如，花费超过 1 秒的请求）
awk '($16 > 1.0) {print $16, $7}' /var/log/nginx/timing_access.log | sort -nr | head -10

解释： 此命令会打印出任何花费时间超过 1.0 秒的请求的请求时间 ($16) 和 URI ($7)，并按降序排序。

5.4 识别请求最多的 IP 地址

有助于发现潜在的 DoS 攻击、流量激增或可疑活动：

# 查找发出请求最多的前 20 个 IP
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

结论

Nginx 日志是维护高可用性和性能的主要诊断资源。通过超越默认日志格式，并整合 $request_time 和 $upstream_response_time 等性能指标，您可以将简单的记录转变为强大的故障排除数据。始终将访问日志中的发现（发生了什么）与错误日志中的详细信息（为什么发生）相关联，以快速有效地解决服务器问题。