为什么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 评估双栈成本。并非替代所有场景，而是多一个选型参考。