当一次用户请求被容器与微服务拆成几十次调用之后，运维数据的形态发生了根本变化：指标数量随实例和标签组合快速膨胀，日志量随副本数线性增长，链路追踪则把每一次调用都记录成跨服务的时间片段。很多团队过去按指标、日志、链路分别采购工具，结果是排障时要在三个界面之间来回跳转，靠时间戳手工拼图。

这一局面正在改变。可观测性建设的重心，正从“多接几个工具”转向“建一套统一的数据底座”。

三套系统分立的老问题

分立的代价首先体现在上下文断裂上。监控系统报警说某接口延迟升高，工程师还要去日志平台搜关键字，再去链路系统找慢调用，中间往往缺少统一的服务名、实例标识和请求 ID。其次是口径不一致：同一个服务在 A 系统叫 order-svc，在 B 系统叫 order_service，告警规则与看板难以复用。最后是成本失控，标签基数一旦失控，指标存储费用可能在一个季度内翻倍，而真正被查询的序列不到总量的一成。

统一采集层成为共识

OpenTelemetry 的成熟是这轮转变的关键推力。它提供厂商中立的 SDK 与 Collector，把指标、日志、链路统一到一套语义约定和传输协议上，数据可以按需送往不同后端，而不再被某一家平台的埋点接口锁死。近两年，主流云厂商的托管可观测服务陆续支持 OTLP 直接接入，采集侧的“一次埋点、多处消费”从概念变成了可落地的工程实践。

更实际的价值在于 Collector 的分层部署：在节点或集群侧做初步过滤、脱敏和批量发送，在网关侧做集中路由与采样决策，让数据在离开业务集群之前就完成瘦身。

采样与保留策略决定账单

统一底座并不意味着把所有数据都留下来。高基数标签是云上可观测成本的常见放大器，把用户 ID、请求参数原样写进标签，看似方便排查，实际会让时间序列数量指数级上升。较为务实的做法是：指标侧严格控制标签维度，必要时用聚合换取成本；链路侧采用尾部采样，优先保留错误与高延迟请求；日志侧按级别与业务域分层，热数据短期全量、冷数据长期降采样留存。

从工具采购到数据治理

可观测性正在变成一项需要长期治理的数据能力，而非一次性的软件采购。它的衡量标准不是接入了多少种工具，而是故障发生时平均定位时间是否下降、单位请求的可观测成本是否可控、新服务上线时是否能自动获得一致的观测数据。对多数企业而言，比较稳妥的推进顺序是先统一语义约定与采集链路，再逐步替换旧工具，最后才谈平台整合与智能分析，避免一次性重构带来的运维风险。