服务器日志分析，访问量突增时先别急着扩容
📱 Mozilla/5.0 (Linux; Android 7.0;) AppleWebKit/537.36 (HTML, like Gecko) Mobile Safari/537.36 (compatible; PetalBot;+https://webmaster.petalsearch.com/site/petalbot)
🔗 /e8209adf72f0.html
📄
服务器日志分析，访问量突增时先别急着扩容
访问量突增时，日志里同时出现响应变慢、5xx 增多、CPU 升高，看起来像资源不够，但这组现象也可能来自配置错误。区分两者的关键是：把“请求总量变化”和“单位请求成本变化”分开看。如果单请求耗时、错误类型、后端处理时间随总量同步恶化，更像资源压力；如果总量没变多少、特定路径或特定状态码突然集中，或同一请求在部分节点正常、部分节点失败，更像配置错误。先做这一步归因，再决定扩容、改配置还是回滚。
先看单位请求成本，而不是总请求数
总量上升本身不是证据。资源压力的典型特征是单位成本随并发上升：平均响应时间变长、队列等待增加、数据库连接池占用接近上限。配置错误的典型特征是单位成本不变或只在特定条件下跳变，例如只有带查询参数的 URL 返回 500，或只有某个后端节点持续超时。
可执行动作：从日志中按分钟聚合请求数、平均处理时间、错误率，再单独抽出错误请求的路径分布。如果错误集中在少数路径，且这些路径在突增前就有零星的同类错误，优先怀疑配置或代码分支，而不是带宽或 CPU。这个结果会直接改变下一步：路径集中就查规则、路由和参数处理；全局均匀恶化才进入资源排查。
用状态码和错误来源切开两种解释
状态码能提供可核对的证据，但不能单独定案。5xx 增多既可能是后端过载，也可能是上游配置指向了错误的后端。区分方法是看错误由谁产生：如果日志里同一请求在负载均衡层记录为 502，而后端日志根本没有对应记录，说明请求没有到达应用，应优先检查转发规则、健康检查阈值和上游地址；如果后端有记录但处理超时，才更接近资源压力。
- 499、504 集中出现且后端无记录：先查网关超时配置和连接复用。
- 500 集中在特定参数或路径：先查应用配置和输入处理。
- 所有路径错误率同步上升、后端处理时间同步变长：再考虑资源压力。
注意，请求量或抓取量归零、错误率突然下降，都不能单独证明某次处理正确。缓存命中、上游限流、监控采样变化都可能造成同样的曲线，需要交叉核对多个来源。
保留、改写还是退出：三种取舍的适用前提
确认原因后，处理方式不是只有扩容一种。
保留现有配置并扩容，适用于单位请求成本确实随并发上升、错误分布全局均匀、且突增被判断为持续需求的情况。前提是你已经确认瓶颈在资源侧，否则扩容只会把配置错误放大到更多节点。
改写配置或路由规则，适用于错误集中在特定路径、特定后端或特定参数的情况。动作是先在小范围节点上应用改动，再对比改动前后的同类请求错误率。如果错误率下降只出现在改动节点，才说明配置是主因；如果所有节点同步下降，要检查是否有其他同时发生的变更。
退出当前处理路径，例如临时下线出问题的后端、回滚最近的规则变更，适用于错误持续扩大且无法快速定位的情况。退出的前提是你能保留原始日志和配置快照，否则回滚后无法验证原因，下一次突增还会重复同样的判断。
一个注明假设的短例子
假设某站点在促销开始后十分钟内请求数翻倍，监控显示 CPU 到 80%，5xx 从 0.2% 升到 4%。仅凭这些会倾向扩容。进一步看日志：5xx 全部来自 /search 路径，且都带同一个新增参数；其他路径响应时间正常，后端 CPU 升高的时间点晚于错误出现的时间点。这个证据组合更支持配置或参数处理问题，而不是资源压力。此时先回滚该参数相关的规则并观察同类请求，比直接加机器更能验证判断。如果回滚后错误率没有下降，再回到资源侧排查。
把判断变成可复查的步骤
突增期间最容易犯的错，是把相关当因果：CPU 高和错误多同时出现，不等于 CPU 高导致错误。可复查的做法是固定三件事：保留突增前后的原始日志与配置快照；按路径、状态码、后端节点三个维度拆分错误；对每次改动只改变一个变量并记录时间点。这样无论最终是扩容、改配置还是回滚，下一步都有依据，而不是靠现象猜测。
