监控不是安装一套工具

做监控平台时，讨论经常从指标协议、存储、图表和报警语法开始。这些都要解决，不过部署好了工具，数据也采上来了，后面还有谁看、谁处理的问题。

有指标不等于有人看

很多项目接入监控以后，确实能够看到接口耗时、错误量、线程池和垃圾回收等指标。但只有出现问题时，大家才临时打开页面寻找线索。

这样的监控更接近排查工具。它能帮助解释故障，却不能提前发现故障。

要让指标进入日常运行，还需要明确什么变化属于异常，报警发送给谁，收到以后怎样判断是否需要处理。否则，图表再完整，也只是被动保存系统状态。

如果每个项目都从头理解指标、编写规则和配置接收人，接入成本会长期存在。

我们后来为常见问题提供默认报警，例如异常增长、线程池耗尽和频繁 Full GC，并把报警接收人与项目责任关系连接起来。业务团队仍然可以配置更具体的规则，但基础风险不必每次重新建设。

这种默认能力并不复杂，却比增加更多图表更直接地改变了问题发现方式。

平台的作用不只是提供灵活性，也应该把已经验证过的经验变成默认设置。

大型组织通常不只有一套监控。前端、客户端、服务端、日志和链路追踪可能来自不同平台。

每套工具分别看都合理，真正排查问题时却需要在多个入口之间切换。项目名称、时间范围和责任关系如果不统一，使用者需要先完成一轮信息对齐。

因此，我们曾经尝试收拢入口，让不同监控能力能够围绕同一个项目被找到。统一入口没有消除底层系统差异，只是减少“应该去哪里看”的成本。

CPU、内存和接口错误容易监控，业务失败则更容易遗漏。

请求返回成功，用户目标未必完成，消息正常消费，最终状态也未必一致。关键业务还要有自己的过程和结果指标，技术指标则用来解释这些结果为什么变化。

只监控机器，系统可能在业务已经失败时仍然全部显示绿色。

报警只是把异常送到人面前。是否及时处理，还取决于责任是否清楚、信息是否足够，以及团队是否知道怎样升级问题。

报警过多会让人逐渐忽略，报警缺少上下文则会增加排查时间。没有定期清理和复盘的规则，最终都会失去作用。

所以，监控体系同时涉及技术和组织：平台负责可靠地采集与计算，业务团队定义真正重要的信号，责任人处理异常，复盘再把新的经验补回规则。

数据链路稳定以后，我还会看报警能不能更早发现问题、接收人是否明确、排查有没有变快，以及发生过的问题有没有补进规则。只把工具装好，还不能说明这些事已经有人做了。