一次让人沮丧的故障

第三方 OAuth 服务降级，登录接口响应时间从 200ms 飙升到 8 秒，用户大量流失。

Prometheus 全程显示：一切正常。

原因很简单：那个第三方依赖根本没被监控。

监控只能发现你预先设想过的问题。

三个常见的监控盲区

盲区1：指标维度不够

只监控了整体成功率，没有按用户类型、地区、接口分别监控。某类用户的严重问题被整体数据稀释，看不出来。

盲区2：标签基数爆炸导致系统崩溃

为了监控得更细，给指标加了太多高基数标签（用户 ID、请求 ID），结果 Prometheus 自己先崩了。

盲区3：把相关性当因果性

CPU 升高和响应时间变慢同时出现，不代表 CPU 是根因。可能两者都是同一个底层问题的结果。

从「监控思维」到「可观测性思维」

监控思维：预先定义指标，等待阈值触发告警。

可观测性思维：保留足够的上下文数据（日志、Trace、指标），让你在故障发生时能够快速调查任何问题——包括你没有预先设想过的问题。

核心区别：监控告诉你「出了什么问题」，可观测性让你能够回答「为什么出了这个问题」。

实践建议

1. 在请求链路中传递 TraceID

每个请求从入口到出口都携带唯一 TraceID，出问题时能快速定位是哪个环节出了问题。

2. 只保留 5-7 条核心告警

告警越多，越容易麻木。只对「需要立即人工介入」的情况告警。

3. 把基础设施变更记录为事件

部署、配置变更、扩缩容——这些都应该在监控时间线上有标注，方便关联分析。

4. 监控你的依赖，不只是你自己

第三方 API、数据库、消息队列——这些依赖的健康状态同样需要监控。

总结

Prometheus 是很好的工具，但工具本身不能替代监控策略的设计。

真正有效的监控体系，需要在「监控已知问题」和「保留调查未知问题的能力」之间取得平衡。