为什么IT系统需要可观测性
摘要：微服务与云原生时代，「服务器还活着」无法回答业务为何失败、慢在哪一段。本文从 Metrics / Logs / Traces 三类信号出发，结合 Databuff 官方 Demo 现场截图，说明可观测性与传统监控的差异、为何成为生产必备能力，并给出 OTel 落地路径与选型自检问题。
先不争论「买什么产品」，我们把问题收窄到：可观测性到底解决什么、与监控差在哪？下文按「概念澄清 → 三类信号演示 → 为什么现在更需要 → 落地路径」展开；演示环境为demo.databuff.ai[3]，每一步配有真实界面截图，方便对照自己团队缺哪一环。
§1 监控 ≠ 可观测性
很多人把「可观测性」等同于「上了 Prometheus + ELK」。其实两者关注点不同：
- 传统监控回答：CPU 是否飙高、磁盘是否将满、进程是否存活。
- 可观测性回答：这次下单为什么失败、P99 从 200ms 涨到 2s 是哪一段调用拖慢的、灰度新版本是否引入了新错误。
监控是阈值告警；可观测性是任意维度的下钻与关联——仍能从现有 telemetry 里「问出」系统当时发生了什么[1]。大促零点流量涌入时，只有主机监控会告诉你「Pod 都正常」；有 Trace 和 RED 指标，才能看到是某条下游 RPC 超时在拖垮整条链路。
结论先行：IT 系统需要可观测性，是因为架构变复杂之后，你很难只靠「机器存活」来回答「业务为什么坏了、坏在哪、影响了谁」。过去单体时代 tail 日志往往还能定位；微服务下一次请求穿过十几个服务，报错日志里未必有根因，值班同学只能在多个视图间来回切换，MTTR 被白白拉长。
§2 三类信号：Metrics、Logs、Traces
| 信号 | 典型用途 | 排障角色 |
|---|---|---|
| Metrics | 请求量、错误率、延迟分位 | 发现「哪个服务红了」 |
| Logs | 某时刻进程打印了什么 | 看异常栈、业务上下文 |
| Traces | 一次请求跨服务的完整路径 | 定位「慢在哪一跳」 |
三者互补：指标发现异常，追踪缩小范围，日志补足细节。这也是应用性能监控（APM）与全链路追踪在微服务里被反复提起的原因。
2.1 Metrics：先看见「谁慢了、谁错了」
Databuff Demo · 服务列表
图 2-1 · 服务列表 RED 指标：service-a 平均 240ms、service-b 约 70ms，错误率均为 0[3]
开源 APMDatabuff的服务列表页把RED 指标（请求量、错误率、响应时间）放在同一屏——这就是可观测性里「从业务视角看健康度」，而不是只看 CPU 曲线。
2.2 Traces：把一次点击串成完整调用链
Databuff Demo · 链路追踪
图 2-2 · Trace 数量、错误统计与 P50–P99 响应时间；点击图表可下钻慢请求[3]
仅有指标还不够。链路追踪页展示 Trace 分布与延迟分位；点击图表中的任意点，可下钻到具体慢请求——这正是「从指标到证据」的跳转。
图 2-3 · 单条 Trace Span 瀑布图：定位 SQL、RPC 或网关哪一跳拖慢整体[3]
2.3 拓扑：理解「谁依赖谁」
Databuff Demo · 全局拓扑
图 2-4 · 全局拓扑：service-a / service-b 与 MySQL、Redis、Kafka、Elasticsearch 依赖关系[3]
当服务数量一多，没人能靠记忆画全调用图。全局拓扑自动绘制服务与中间件依赖，故障时能快速判断「是应用本身还是下游组件」在拖后腿。
§3 为什么现在「更需要」了？
- 架构复杂度上升：服务一多，调用路径随发布、扩缩不断变化。
- 变更频率加快：CI/CD 每天多次上线，没有链路级证据很难判断哪次变更引入 regression。
- 用户体验与 SLA 绑定：P99 延迟、支付失败率直接关联收入。
- SRE 文化：On-call 需要的是一条证据链，而不是五套互不相通的工具。
全局大盘把各服务在分钟级时间轴上的告警与异常状态并排展示——适合值班同学做「第一眼巡检」，也是可观测性从被动救火走向主动发现的基础能力。
Databuff Demo · 全局大盘
图 3-1 · 全局大盘：按分钟展示各服务告警与健康时间轴[3]
§4 落地路径
工程上通常三步走：
- 统一采集：OpenTelemetry 已成为多语言埋点事实标准[2]，经 OTLP 接入后端——常见端口 gRPC4317、HTTP4318。
- 存算分离：Trace、指标写入时序或 OLAP 存储，查询层做关联。
- 排障闭环：拓扑看依赖、Trace 瀑布图看慢点、告警做主动发现；理想状态是在一个界面完成「告警 → 拓扑 → Trace → 日志上下文」。
落地还要注意采样率与TraceId 传递——全量 Trace 存储很贵，埋点断链则拓扑再漂亮也是幻觉。
不少团队从 SkyWalking、Jaeger 等开源 APM 起步；也有团队希望以 OTel 为唯一数据面，把指标、链路与辅助分析放在同一栈。Databuff 走 OTLP 原生接入，界面侧支持拓扑、RED 指标，并可用自然语言问数查服务列表、拓扑与趋势——对不熟悉查询 DSL 的值班同学，能少记一套语法。
Databuff Demo · AI 问数
图 4-1 · AI 问数：自然语言查询服务列表、拓扑与指标趋势[3]
若已有 SkyWalking 等存量监控，也可让新业务 OTel 化后并行接入，对照同一请求的 Trace 评估双栈成本。并非替代所有场景，而是多一个选型参考。
§5 小结
IT 系统需要可观测性，是因为复杂性超出人脑能实时掌握的范围。只要系统对外提供业务价值、且由多个组件协作完成，可观测性就从「锦上添花」变成「生产必备能力」。
评估优先级时，先问三个问题：有没有跨服务 Trace？能不能从慢请求钻到 Span？告警后需要切换几个工具？答案越偏向「没有 / 很多」，建设优先级就越高——这比先争论「买哪家」更重要。
引用资料
[1] https://opentelemetry.io/docs/concepts/observability-primer/
[2] https://opentelemetry.io/docs/languages/
[3] https://demo.databuff.ai/