摘要：你有没有遇到过这样的困扰？在互联网大厂的后端开发工作中，突然发现系统出现异常操作，却不知道从何查起。面对海量的 NGINX 的 access 日志，就像面对一片信息的海洋，想要快速定位操作来源，简直无从下手！别着急，今天这篇文章就来帮你解决这个难题！

你有没有遇到过这样的困扰？在互联网大厂的后端开发工作中，突然发现系统出现异常操作，却不知道从何查起。面对海量的 NGINX 的 access 日志，就像面对一片信息的海洋，想要快速定位操作来源，简直无从下手！别着急，今天这篇文章就来帮你解决这个难题！

NGINX 作为互联网大厂中广泛使用的高性能 Web 服务器和反向代理服务器，它的 access 日志记录着每一次客户端请求的详细信息。这些信息对于后端开发人员来说，是排查问题、分析系统运行状况的重要依据。然而，随着业务的不断增长，日志数据量也在呈指数级增长，如何从这些海量的日志中提取出有用的信息，准确分析操作来源，成为了后端开发人员必须掌握的一项技能。

时间范围筛选

在实际工作中，异常操作发生的时间可能并不是一个精确的点，而是一个时间段。除了简单的日期筛选，我们还可以使用正则表达式结合 grep 命令进行更复杂的时间范围筛选。例如，想要筛选出 2024 年 10 月 1 日 8 点到 12 点之间的日志，可以使用命令 grep -E "2024/10/01:0[8-9]:|2024/10/01:1[0-2]:" access.log。当需要筛选多个不连续的时间段时，比如 2024 年 10 月 1 日 8 - 9 点和 11 - 12 点的日志，可使用命令 grep -E "2024/10/01:08:|2024/10/01:09:|2024/10/01:11:|2024/10/01:12:" access.log 。

此外，我们还可以结合 awk 命令，按照时间进行更细致的统计分析。例如，统计每个小时的请求数量，使用命令 awk '{print $4}' access.log | cut -d: -f2 | sort | uniq -c，该命令会先提取日志中的时间字段，再截取小时部分，最后统计每个小时出现的次数 。

请求 URL 筛选：

如果异常操作涉及特定功能模块，通过请求 URL 筛选能快速锁定相关日志。当 URL 中包含特殊字符时，需要进行转义处理。比如，要筛选 URL 中包含 “/user?id=123” 的日志，使用命令 grep "/user\?id=123" access.log 。若想要同时筛选多个相关 URL，可以使用扩展正则表达式，如筛选包含 “/user” 或 “/order” 的 URL 日志，命令为 grep -E "/user|/order" access.log 。

同时，我们还可以利用 sed 命令对筛选后的 URL 进行进一步处理，例如去除 URL 中的参数部分，只保留路径，命令为 grep "/user" access.log | sed 's/\?.*//'，这样便于对同一类型功能的请求进行聚合分析 。

客户端 IP 地址

获取到客户端 IP 地址后，查询 IP 归属地可以使用在线工具，如IPIP.NET、纯真 IP 数据库等。在互联网大厂内部，通常会有自己的 IP 地址管理系统，通过内部系统可以快速确定 IP 是否属于内部网络。如果发现异常 IP 地址，还可以进一步在防火墙或网络访问控制列表中查询该 IP 的访问权限和历史访问记录。

另外，当出现大量来自同一 IP 的高频请求时，有可能是恶意攻击行为。此时可以使用命令 grep -oE '\b([0 - 9]{1,3}\.){3}[0 - 9]{1,3}\b' access.log | sort | uniq -c | sort -nr ，统计每个 IP 的请求次数，并按降序排列，快速找出高频请求的 IP 。

请求时间

将请求时间与系统监控数据（如 CPU 使用率、内存占用、数据库连接数等）结合分析时，可以使用时序数据库工具，如 InfluxDB。将日志中的请求时间和对应的系统指标数据导入 InfluxDB，通过可视化工具 Grafana 绘制折线图，直观地观察在异常操作发生时，系统各项指标的变化趋势，从而判断异常操作是否对系统性能产生了影响 。

HTTP 状态码

当遇到非 200 状态码时，不同的状态码代表不同的问题类型。例如，404 状态码表示请求的资源未找到，此时需要检查 URL 是否正确，或者资源是否被误删除；500 状态码表示服务器内部错误，需要查看服务器的错误日志，定位代码中的异常点。可以使用命令 grep -E " 404| 500" access.log 快速筛选出包含这两种常见错误状态码的日志 。同时，我们还可以统计不同状态码出现的频率，命令为 awk '{print $9}' access.log | sort | uniq -c | sort -nr，通过分析状态码分布，发现系统中潜在的问题 。

ELK 平台搭建与使用

Logstash 配置：首先需要在服务器上安装 Logstash，安装完成后，创建一个配置文件，例如 nginx_log.conf 。在配置文件中，输入以下内容来读取 NGINX 的 access 日志并发送到 Elasticsearch：

然后在命令行中运行 logstash -f nginx_log.conf 启动 Logstash 服务 。

Kibana 可视化分析：在 Kibana 中，进入 “Discover” 页面，可以通过各种条件对导入的日志数据进行查询。例如，想要查询 HTTP 状态码不为 200 的请求，可以在搜索框中输入 http_status:!=200 。创建仪表盘时，添加 “可视化” 组件，如 “柱状图”，选择 “aggregation” 为 “Terms”，对 “remote_ip” 进行统计，就能直观地看到不同 IP 的请求数量分布；选择 “Date Histogram”，以时间为维度，统计每个时间段的请求数量 。

Grafana 与 Prometheus 结合使用

Prometheus 配置：安装 Prometheus 后，修改其配置文件 prometheus.yml ，添加对 NGINX 日志的监控任务。例如：

这里假设安装了 nginx_exporter，用于将 NGINX 日志数据转换为 Prometheus 可识别的指标。配置完成后，启动 Prometheus 服务 。

Grafana 可视化：在 Grafana 中添加 Prometheus 作为数据源，然后创建仪表盘。可以创建 “折线图” 展示不同时间段的请求数量变化趋势；创建 “饼图” 展示不同 HTTP 状态码的占比情况 。通过设置告警规则，当某些关键指标（如 500 状态码数量突然激增）达到阈值时，及时发出告警通知 。

日志备份与清理

制定详细的日志备份计划，例如每天凌晨 2 点对当天的日志进行压缩备份，备份文件命名规则为 access.log.YYYYMMDD.tar.gz 。使用 crontab 设置定时任务，命令为 0 2 * * * tar -zcvf access.log.$(date +\%Y\%m\%d).tar.gz /var/log/nginx/access.log 。同时，设置日志保留策略，比如只保留最近 30 天的日志，超过 30 天的日志自动删除，使用命令 find /var/log/nginx/ -name "access.log.*.tar.gz" -mtime +30 -delete 。

日志记录格式与标准

统一规定 NGINX 的 access 日志格式，在 NGINX 的配置文件中，将日志格式设置为 log_format main '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

'"$http_user_agent" "$http_x_forwarded_for"'; 。同时，对于自定义的业务日志，明确规定日志字段的含义和取值范围，例如，在日志中记录用户操作时，必须包含用户 ID、操作时间、操作类型等字段，并且对每个字段的格式（如用户 ID 为 11 位数字）进行严格规范 。

异常操作分析流程

当发现异常操作时，首先按照时间范围和请求 URL 进行初步筛选，获取相关日志；然后分析日志字段，确定操作来源的 IP 地址、操作时间、请求状态等信息；接着借助 ELK 或 Grafana + Prometheus 等工具进行深入分析，定位问题根源；最后，将分析过程和结果记录下来，形成文档，以便后续复盘和参考 。

通过以上详细且具体的方法，我们就能够从 NGINX 的 access 日志中精准定位操作来源，解决后端开发工作中的一大难题！在实际工作中，希望大家能够灵活运用这些方法，不断积累经验。如果你在日志分析过程中还有其他问题，或者有更好的分析技巧，欢迎在评论区留言分享，大家一起交流学习，共同提升在互联网大厂后端开发领域的技能

来源：从程序员到架构师一点号