可观测性 vs 监控：别搞混了，它们真不一样
说实话，我刚入行那几年，一直觉得「可观测性」就是「监控」的时髦说法。直到有一次，我负责的实时数据管道在凌晨三点出了故障——监控面板上全是绿的，但数据就是不对。嗯，那次之后我才真正明白，这两者压根不是一回事。
今天咱们就把这事彻底聊透。我会结合自己踩过的坑，帮你理清监控和可观测性的区别、联系，以及什么时候该用哪个。
传统监控：它很好，但不够
监控是什么？说白了，就是「我知道我要看什么，所以我提前设好了指标和告警」。比如：
- CPU 使用率超过 90% 就报警
- Kafka 消费延迟超过 1000 条就发邮件
- API 响应时间超过 2 秒就触发 PagerDuty
这些都没错。但问题在于——你只能监控你想到的东西。
传统监控的三大局限：
- 已知的已知：你只能对已知的故障模式设告警。未知的故障？监控面板上全是绿的。
- 孤立的指标：CPU 高了？内存满了？但为什么高、为什么满，监控不会告诉你。
- 静态阈值：业务流量有波峰波谷，但告警阈值往往是拍脑袋定的。我见过太多因为阈值设得太死，半夜被误报警叫醒的案例。
我记得有一次，一个数据管道在凌晨跑批处理，突然慢了 3 倍。监控显示 CPU、内存、磁盘 IO 都在正常范围。但数据就是出不来。最后排查了 4 个小时，发现是上游的一个 API 接口在返回数据时，偶尔会多一个换行符——解析器崩了。监控能抓到 CPU 吗？不能。能抓到内存吗？不能。它只能抓到「我告诉它要抓的东西」。
这就是传统监控的致命伤：你无法监控你不知道的东西。
可观测性：让系统自己告诉你它怎么了
可观测性（Observability）这个概念，最早来自控制理论。简单说就是：通过系统的外部输出，推断内部状态的能力。
放到数据管道里，可观测性意味着：
- 我不需要提前知道所有可能的故障模式
- 当问题发生时，我可以随时「问」系统发生了什么
- 我可以从多个维度（日志、指标、链路追踪）交叉定位问题
我个人习惯把可观测性理解为「系统的体检报告」——监控只告诉你「体温 38 度了，快报警」，而可观测性能告诉你「白细胞升高了，可能是细菌感染，建议做进一步检查」。
可观测性的三大支柱，大家应该都听过：
| 支柱 | 作用 | 我踩过的坑 |
|---|---|---|
| 日志（Logs） | 记录离散事件，告诉你「发生了什么」 | 日志太多，没做结构化，查问题时像大海捞针 |
| 指标（Metrics） | 聚合数据，告诉你「趋势是什么」 | 指标维度太少，无法按业务线、机房、版本下钻 |
| 链路追踪（Traces） | 记录请求在分布式系统中的完整路径 | 只追踪了入口和出口，中间环节全黑盒 |
这三者缺一不可。你想想看，如果只有指标，你只知道「延迟高了」，但不知道是哪个环节慢了。如果只有日志，你只知道「某条记录出错了」，但不知道这个错误影响了多少用户。如果只有链路追踪，你只知道「请求走了哪些服务」，但不知道每个服务的资源消耗情况。
可观测性的真正优势
跟传统监控比，可观测性有几个实实在在的好处：
- 未知故障也能查：不需要提前设告警，出问题时通过日志和链路追踪反向定位。我曾经靠一条「看起来不太对」的日志，揪出了一个隐藏了三个月的内存泄漏。
- 多维度下钻：指标可以按机房、版本、用户、业务线切分。比如「整体延迟正常，但某个机房的延迟突然飙升」——监控可能不会报警，但可观测性让你一眼看到。
- 减少告警疲劳：可观测性不是「什么都报警」，而是「需要的时候能查到」。我现在的团队，告警数量减少了 60%，但故障定位时间缩短了 80%。
注意：可观测性不是银弹。它需要投入基础设施成本（存储、计算、工具链），也需要团队有相应的数据思维。如果你连基本的监控都没做好，别急着上可观测性——先学会走，再学跑。
适用场景对比：什么时候用什么
我一般这样跟团队讲：
| 场景 | 推荐用监控 | 推荐用可观测性 | 我的建议 |
|---|---|---|---|
| 基础设施健康检查 | ✅ 首选 | 辅助 | CPU、内存、磁盘这些，监控就够了 |
| 已知故障模式 | ✅ 高效 | 辅助 | 比如「磁盘满了就报警」，监控最直接 |
| 复杂分布式系统排障 | 不够用 | ✅ 必须 | 没有链路追踪，你根本不知道请求去了哪 |
| 数据质量异常 | 很难 | ✅ 核心 | 数据少了一行、多了一列，监控抓不到 |
| 容量规划 | ✅ 基础 | 辅助 | 监控提供趋势数据，可观测性提供细节 |
| 安全审计 | 不够 | ✅ 必须 | 日志和链路追踪是审计的基础 |
说白了，监控是「我知道我要找什么」，可观测性是「我不知道问题在哪，但系统能帮我找到」。两者不是替代关系，而是互补关系。
一张图看懂：监控 vs 可观测性
下面这张图，是我自己画的知识结构。它把监控和可观测性的核心区别、联系、适用场景串在了一起。你可以把它当作本章的「思维导图」。
我的建议：先监控，后可观测性
如果你问我，一个团队应该先做监控还是先做可观测性？我的回答是：先做好监控，再逐步建设可观测性。
为什么？因为监控是基础。你连 CPU 满了都不知道，谈什么链路追踪？你连 API 挂了都没告警，谈什么日志分析？
但当你发现：
- 告警越来越多，但真正有用的越来越少
- 故障定位时间越来越长，因为信息太分散
- 数据管道越来越复杂，你根本不知道数据流到了哪里
这时候，就该认真考虑可观测性了。
一个小建议：从「三大支柱」中最容易入手的一个开始。我个人推荐先从结构化日志开始——把日志从纯文本改成 JSON 格式，加上请求 ID、时间戳、服务名等字段。这一步成本最低，但效果立竿见影。我曾经在一个项目里，只做了这一步，排障效率就提升了 3 倍。
好了，这一章就聊到这。记住一句话：监控告诉你「出事了」，可观测性告诉你「为什么出事」。两者都重要，但别搞混了它们的定位。