网站监控数据

凌晨三点，网站手机屏幕突然亮了。监控不是数据微信，不是网站短信，是监控网站监控发来的告警：首页响应时间从平均320毫秒跳到了4700毫秒。我翻了个身，数据没理它。网站十分钟后，监控第二条告警来了——HTTP 503，数据服务不可用。网站这下彻底睡不着了。监控

这就是数据网站监控数据最真实的样子。它不会在你清醒的网站时候温柔地提醒你“有点慢哦”，而是监控在你最不想动弹的时刻，用最直接的数据方式告诉你：出事了。

那些数字到底在说什么

很多人看监控面板，眼里只有红绿黄三种颜色。绿的就没事，红的就找人修。但真正有用的信息藏在曲线拐点和分布尾部的那些点里。

举个例子。我们有个电商客户，监控显示平均响应时间一直稳定在200毫秒左右，看着挺健康。但P99——也就是最慢的那1%请求——长期在3秒以上。运营团队觉得“平均还行”，直到有天大促，那1%的慢请求突然变成了15%，整个下单链路堵死。事后复盘发现，数据库连接池在特定查询模式下会排队，平时量小看不出来，量一上来就雪崩。

平均值会骗人。中位数也会。只有当你把P95、P99、P999和错误率放在同一张时间轴上对比，才能看出系统真正的脾气。

告警疲劳比没有告警更可怕

我见过一个团队，监控系统配了四百多条告警规则。结果呢？值班群里每天滚动上百条消息，从“磁盘使用率超过75%”到“某边缘节点丢包率0.3%”，什么都有。两周之后，没人认真看了。真正致命的“支付回调失败率突增”被淹没在噪音里，过了四十分钟才有人发现。

监控数据的第一原则不是“多”，是“准”。每一条告警都应该对应一个明确的动作：要么立刻处理，要么记录观察，要么直接删掉。如果一个告警触发后你只是看一眼然后关掉，那它就不该存在。

日志、指标、链路，缺一不可

指标告诉你“发生了什么”——CPU涨了，延迟高了，错误多了。日志告诉你“具体哪里错了”——某个空指针，某个超时，某个第三方接口返回了奇怪的东西。链路追踪告诉你“这个请求经过了哪些服务，在哪一跳卡住了”。

只靠指标，你会知道系统病了但不知道病在哪。只靠日志，你会在海量文本里捞针。只靠链路，你看到的是抽样后的片段。三个一起用，才能从“网站挂了”快速定位到“订单服务调用库存服务时，因Redis连接超时导致线程池耗尽”。

有个做SaaS的朋友跟我说过一句话：监控数据不是用来“看”的，是用来“问”的。每次故障复盘，你都应该能指着某条曲线说——这里，这个拐点，对应的是我们当时做的那个变更。如果做不到，说明监控数据还不够细，或者你还没学会读它。

数据保留多久才够

很多云监控默认只保留15天原始精度数据。15天够吗？对于排查突发故障，够。但对于容量规划和趋势分析，远远不够。

我的做法是：原始高精度数据保留30天，用于故障排查；5分钟粒度的聚合数据保留13个月，用于看季节性波动；1小时粒度的归档数据保留3年，用于年度对比。存储成本其实没想象中高，但关键时刻能救命——比如去年我们发现某个服务每年双十一前一周都会出现内存缓慢增长，就是因为翻到了前年的归档曲线。

监控数据从来不是冷冰冰的数字。它是系统的心跳、呼吸和体温。你认真对待它，它就在半夜安静睡觉；你忽视它，它就凌晨三点把你叫醒。选哪个，你自己定。