Python 统计 Nginx 慢请求,原来高手都在偷偷用这招!

slow_requests.append({ 'line': line_num, 'method': method, 'url': url, 'status': status, 'time': request_time, 'raw_line': line.strip() })

return slow_requests

 是不是比想象中简单？这个脚本就像个忠诚的哨兵，逐行检查日志，一旦发现处理时间超过你设定的“警戒线”，就立刻记录下来。你可以把 `slow_threshold` 设为 1.0（1秒），或者根据你的业务敏感度调整为 0.5 甚至 2.0。  

仅仅把慢请求找出来还不够，我们需要知道更多：哪个接口最慢？慢请求集中在什么时间？哪种HTTP方法问题最多？原始的数据列表看起来太费劲了，我们需要更直观的分析。

我们可以对收集到的慢请求进行简单的统计和排序：

def generate_report(slow_requests):     if not slow_requests:         print("恭喜！没有发现超过阈值的慢请求。")         return          print(f"共发现 {len(slow_requests)} 个慢请求\n")     print("=" * 60)

url_stats = {} for req in slow_requests: url = req['url'] if url in url_stats: url_stats[url]['count'] += 1 url_stats[url]['total_time'] += req['time'] url_stats[url]['max_time'] = max(url_stats[url]['max_time'], req['time']) else: url_stats[url] = { 'count': 1, 'total_time': req['time'], 'max_time': req['time'] }

print("【慢请求TOP 10接口】") sorted_urls = sorted(url_stats.items(), key=lambda x: x[1]['total_time'], reverse=True)[:10]

for url, stats in sorted_urls: avg_time = stats['total_time'] / stats['count'] print(f"接口: {url}") print(f"  出现次数: {stats['count']}次") print(f"  平均耗时: {avg_time:.3f}秒") print(f"  最大耗时: {stats['max_time']:.3f}秒") print(f"  总耗时: {stats['total_time']:.3f}秒") print("-" * 40)

 运行这个报告函数，你会看到类似这样的输出： 

共发现 47 个慢请求

【慢请求TOP 10接口】 接口: /api/report/generate 出现次数: 12次 平均耗时: 3.214秒 最大耗时: 8.932秒 总耗时: 38.568秒

接口: /api/image/process 出现次数: 8次 平均耗时: 2.156秒 最大耗时: 4.221秒 总耗时: 17.248秒

 **看到没有？/api/report/generate 这个接口就是重点嫌疑对象！** 平均超过3秒，最夸张的一次将近9秒。有了这样清晰的“靶子”，优化工作就有的放矢了。

手动运行脚本毕竟麻烦，真正的运维高手会让这一切自动化。这里有几个让分析工作更高效的建议：

定时任务分析：使用 Linux 的 crontab 设置每天凌晨自动分析前一天的日志，并将结果发送到你的邮箱或钉钉/企业微信。

0 2 * * * /usr/bin/python3 /path/to/your/script.py >> /var/log/nginx-slow-analysis.log

 **实时监控告警**：如果某个接口的慢请求突然暴增，能不能立即知道？当然可以！你可以修改脚本，当慢请求数量在短时间内超过某个阈值时，自动触发告警。  **可视化展示**：将分析结果保存到数据库，然后用 Grafana 等工具制作成漂亮的监控图表。看着曲线图上那些“ spikes”（尖峰），你会对系统性能有更直观的把握。  

发现了慢请求只是第一步，更重要的是解决问题。根据分析结果，你可以从这些方向入手：

数据库查询优化：大部分慢请求的罪魁祸首都是数据库。检查慢查询日志，看看是不是缺少索引，或者SQL语句写得有问题。那个 /api/report/generate 接口，很可能就是在生成报表时查询了太多数据。

代码逻辑重构：有些接口的代码可能写了多年，存在重复计算、循环查询等低效操作。用性能分析工具（如 Python 的 cProfile）找到代码中的热点，然后针对性优化。

缓存策略优化：一些不常变化的数据，完全可以放到 Redis 等缓存中。用户第一次请求慢一点可以接受，但每次都慢就说不过去了。

外部依赖检查：你的接口是否调用了其他第三方服务？它们的响应速度如何？有时候问题不在你，而在你依赖的服务商。

硬件和配置调优：如果经过上述优化还是慢，可能需要考虑升级服务器配置，或者调整 Nginx、数据库的相关参数。

记住，优化是一个持续的过程。今天最快的接口，明天可能因为数据量增长而变慢。定期分析慢请求，应该成为每个运维和开发人员的习惯。

我想分享一个更高级的思路：不要等到用户投诉了才去查日志。最好的运维是预防，而不是补救。

你可以在 Nginx 配置中直接定义慢日志：

http {     log_format slow '$remote_addr - $remote_user [$time_local] '                     '"$request" $status $body_bytes_sent '                     '"$http_referer" "$http_user_agent" $request_time';          access_log /var/log/nginx/access.log;     access_log /var/log/nginx/slow.log slow if=$request_time>1; } 

这样，超过1秒的请求会自动记录到单独的 slow.log 文件中，分析起来更加方便。

更进一步的，一些 APM（应用性能监控）工具可以实时追踪每个请求的完整调用链，精确到每个函数、每个SQL语句的耗时。虽然这类工具更重，但对于复杂系统来说，投资是值得的。

无论采用哪种方法，核心思想都是一样的：让数据说话，让问题显形。Python 脚本只是工具，重要的是培养用数据驱动优化的思维习惯。

下次再遇到性能问题，别急着重启服务器。先拿出这个 Python 脚本，让数据告诉你真相。当你能够精准定位并解决慢请求时，你会发现，服务器的性能提升了，用户的抱怨变少了，自己的运维水平也悄悄上了一个台阶。

这，就是技术人的成就感所在。