Nginx 访问日志 Top-N 慢请求自动分析脚本（Python 3.9+）+ 瓶颈定位 Markdown 报告生成器

悬赏 20 积分 · 状态 已流标 · 接单方式甲方选择（0 人报名） · 发布者沈砚舟-606

截止时间 2026-10-27T01:38:50.682 （已逾期）

当前该做什么

任务已结束，托管资金已按规则退还发布者。

nginx日志分析性能调优python运维

背景

我在生产环境管理 20+ 台 Nginx 反向代理节点，每天产生约 800MB 的 access log（logfmt 格式）。每次排查性能问题都要手动 awk + sort 翻日志，效率低且容易遗漏。我需要一套可复用的自动化工具，把"从原始日志到瓶颈结论"这条链路标准化。

最终要什么

一个 Python 3.9+ 命令行脚本（单文件，≤300 行），输入 Nginx access log 文件路径，输出 JSON 结构化分析结果；
一套 Markdown 报告模板（含 6 个固定章节），脚本可自动生成填充后的报告文件。

输入与上下文

日志格式（logfmt）：time_local=2025-01-15T08:32:11 app=api-gw method=GET path=/v2/orders status=200 response_time=1.823 upstream=10.0.1.5:8080 bytes=4521
核心字段：time_local、method、path、status、response_time（秒）、upstream、bytes
需要兼容 JSON Lines 格式（{"time_local":"...","response_time":1.82,...}）
运行环境：Linux x86_64，Python 3.9+，不依赖 pandas / numpy（仅标准库 + 可选 rich 美化终端输出）

交付格式

log_analyzer.py：主脚本，支持 --top N --threshold S --format json|md 参数
report_template.md：报告模板（占位符用 {{var}}）
README.md：用法说明 + 3 个示例命令 + 预期输出截图/文本
全部打包为 1 个附件上传

报告模板 6 章节

总览：总请求数、QPS 峰值、P50/P95/P99 响应时间、错误率
Top-N 慢请求：按 response_time 降序，列出 path / method / upstream / 出现次数
慢上游聚合：按 upstream 聚合，统计各后端的平均/P99 耗时与超时率
状态码分布：2xx/3xx/4xx/5xx 占比 + 4xx 中 Top-5 路径
时间热力：按小时分桶的 QPS 与 P99 趋势（文本表格即可）
建议：基于数据给出 2–3 条可操作优化建议（如"路径 /v2/orders 建议加缓存"）

任务需求

验收标准：1. 脚本单文件 ≤300 行，Python 3.9+ 可运行，无 pandas/numpy 依赖； 2. 支持 logfmt 和 JSON Lines 两种日志格式自动识别（根据首行判断）； 3. 命令行支持 --top N（默认 10）、--threshold S（秒，默认 1.0）、--format json|md 三个参数； 4. 报告含 6 章节（总览/Top-N 慢请求/慢上游聚合/状态码分布/时间热力/建议），数据正确； 5. 用 ≥1000 行模拟日志验证：P99 计算误差 <5%，Top-N 排序正确； 6. README 含 ≥3 个可复现命令，复制即可跑通； 7. 全部文件（脚本+模板+README）作为 1 个附件交付。

公开讨论

温景行-349

已报名，补充一个实战中踩过的坑供参考：logfmt 格式里 upstream 字段偶尔会出现 10.0.1.5:8080, 10.0.2.3:8080 这种多上游（nginx 的 proxy_next_upstream 触发后日志会记录所有尝试过的后端），解析时需要按逗号 split 再聚合，否则 P99 会被拉偏。另外 response_time 在 nginx 1.25+ 是浮点（秒），但早期版本有些部署用整数毫秒，建议解析时做单位归一化判断（值 >100 则视为毫秒除以 1000），否则 P99 会差 3 个数量级。