Web 服务监控：5xx 率告警怎么做

线上故障里，用户经常比开发者先发现问题。等有人打电话来说网站打不开，损失已经发生。5xx 率告警就是让机器盯日志，把发现时间从小时级压到分钟级。 ## 一、5xx 为什么单独盯 HTTP 状态码里，5xx 表示服务端出错：500 是代码异常，502 是网关拿不到后端响应，504 是后端超时。4xx 多数是用户侧或路径问题，5xx 基本都是自己服务的问题，而且是用户直接受损的问题，值得一条独立的告警。 ## 二、用日志统计 5xx 率 Nginx 日志里状态码是第九个字段，定时统计一次： ``` tail -n20000 /var/log/nginx/access.log | \ awk '{total++; if($9>=500) bad++} END{if(total>0) printf "%.2f%%\n", bad/total*100}' ``` 把命令放进脚本按分钟执行，超过阈值就通过邮件或 Webhook 发通知。5xx 率升高后，接着用 grep 定位是哪个接口在报错，Nginx 的 error.log 和 PHP-FPM 日志对照着看，定位通常在几分钟内。通知内容里带上统计窗口时间和样本数，值班的人一眼能判断严重程度，不用再自己跑一遍命令。 ## 三、阈值怎么定 阈值太低会被误报淹没，太高会漏掉真事故。经验做法：正常业务 5xx 率一般远低于 1%，就把阈值定在 1%，并加最小样本量条件，比如近五分钟请求超过 1000 次才参与判定。低峰期流量小，一两次失败就能把百分比拉高，样本量条件比百分比本身更重要。阈值上线后先跑两周再微调，这两周里每一次误报和漏报的记录，就是最好的调参依据。 ## 四、误报抑制 三类情况要做豁免。发布窗口期内告警静默半小时，避免每次上线都响一次；个别接口天生不稳定，按 URL 维度单独设阈值；已知的恶意 404 扫描不纳入统计。告警发出去没人理，比没有告警更糟，规则越准，值班的人越信任它。规则调整要有记录，改了什么、为什么改，一个月后回看才不抓瞎。 告警只是起点，收到通知后能在一两分钟内看出是哪个接口、什么错误，才算合格。做不到就先把日志格式补齐，再谈监控。