政策快报平台上线第一年告警系统几乎不存在。服务器挂了等用户投诉才知道。爬虫停了等用户说“怎么没有新政策”才发现。数据库慢了等用户反馈“页面加载好慢”才去查。那一年有一个深夜爬虫系统因某个网站改版卡死停了6个小时我们毫无察觉。第二天早上有用户发消息问“你们平台这两天更新是不是变慢了”这才发现出问题了。用户成了我们的“告警系统”。这种方式肯定不能再继续了。后来我们用了一年多时间逐步建起了一套完善的告警系统。现在任何异常5分钟内就能收到通知。告警系统的3个层次第一层基础设施告警最早建立第一层也是最早做的。监控服务器CPU、内存、磁盘、网络的基础指标异常时发送告警。这些指标可以解决大部分“系统挂了”的问题。只要服务器资源出了问题能第一时间知道。关键指标和阈值指标告警阈值说明CPU使用率持续5分钟80%可能被爬虫占满或代码死循环内存使用率持续5分钟85%可能内存泄漏磁盘使用率85%日志太多或数据增长过快磁盘IO等待50ms可能磁盘性能瓶颈网络带宽80%峰值可能被攻击或异常流量这套方案非常基础但很实用。大部分“系统不可用”的问题都能从这几个指标里找到根源。第二层应用层告警中期建立基础设施层面的告警能告诉你“系统出问题了”但不一定能告诉你“具体是什么问题”。应用层告警就是来解决这个问题的。关键监控点接口响应时间P99超过3秒告警。接口慢可能是数据库慢查询、依赖服务超时、或者代码效率问题。告警触发后可以快速定位到具体接口。错误率超过1%告警。错误率突增通常意味着代码有bug或者某个依赖服务挂了。结合日志可以定位到具体报错。爬虫采集量单日采集量低于正常值50%告警。这个很关键——爬虫可能还在运行但某个信源改版了数据采不回来。用户访问量比昨日同时段下降30%告警。流量突然下降可能是服务不可用、CDN出问题、或者某个入口失效了。第三层业务告警近期建立这是最高层关注的是“用户体感”层面的异常。首页加载时间超过2秒告警。用户第一印象最重要首页慢用户会直接走。这个指标直接反映用户实际体验。搜索成功率低于95%告警。搜索失败率高说明搜索服务可能出了故障或索引出问题。这是用户最常用的功能之一需要重点保障。用户反馈量负面反馈突增告警。用户说“查不到政策”“页面打不开”这类反馈数量突然增加往往意味着某个环节出了问题。告警系统的3个设计原则原则一告警要“可操作”。每条告警都应该明确告诉接收人“该做什么”。如果收到告警不知道该怎么办这条告警就没有意义。原则二告警要分级。P0级立即处理和P2级工作时间处理要分开。不要半夜把P2告警发给所有人否则真正重要的P0告警会被淹没。原则三告警要“会收敛”。同一个问题不要发100条告警。一个故障发一条就够了说清楚“什么服务、什么问题、什么时间开始”。后续的重复告警自动合并不要反复打扰。结尾最好的告警是用户还没发现问题你已经修复了。告警系统建设需要持续投入但每投入一分都能减少一分“半夜被吵醒”的概率。