云原生应用被拆成成百上千个服务之后,“系统为什么变慢”这个问题越来越难回答。过去团队通常分别部署指标、日志与链路追踪三套系统,各自采集、各自查询,数据之间靠人工拼接。这种工具拼盘模式在服务数量有限时还能应付,一旦跨集群、跨云、跨语言,排障时间就会被迅速拉长。可观测性由此从辅助手段变成基础设施的一部分。

从工具拼盘到统一语义

开放遥测规范(OpenTelemetry)把指标、日志与链路追踪收进同一套数据模型和采集协议(OTLP),试图解决数据割裂的问题。近一年有两个明显变化:主流指标系统开始原生接收 OTLP 数据,指标与追踪之间的边界被削弱;语义约定不断完善,HTTP、数据库、消息队列等组件的属性命名趋于一致,跨团队的看板与告警规则得以复用。对企业而言,统一语义的价值不只是少装几套采集器,而是让观测数据变成可迁移资产,更换后端时采集侧不必推倒重来,议价与退出成本也随之下降。

采集层向无侵入演进

采集方式同样在变化。基于 eBPF 的技术可以在内核层获取网络调用与系统调用信息,无需修改代码、无需重启服务,尤其适合遗留系统与第三方组件。它的局限也很明显:依赖较新的内核版本,解析加密流量需要额外配合,高负载下还要控制自身开销。因此实践中常见的是混合方案,关键业务路径保留显式埋点,基础设施层交给无侵入采集打底,再通过统一语义把两路数据对齐。

大模型应用带来新观测维度

生成式应用上线后,观测对象从一次请求扩展到一次会话。团队开始关注首字延迟、token 消耗、检索命中情况、工具调用成功率等指标,并把提示词版本、模型版本写进追踪属性,便于回溯“到底是模型换了,还是数据变了”。这类链路的特点是调用次数不多但单次成本高,传统按请求量计费与均质采样的思路需要调整:更合理的做法是对高成本样本全量留存,对低频调试流量抽样。

成本与数据治理成为硬约束

可观测性数据量常常超过业务数据本身,长期全量留存并不经济。通行做法包括:指标做聚合与降采样;追踪采用尾部采样,优先保留报错与慢请求;日志区分热存与冷存并设定保留期;用统一标签控制维度基数,避免高基数把存储和查询一并拖垮。这些规则最好在接入阶段就写进规范,而不是等到账单上涨再补救。

结语

可观测性正在从“买工具”变成“建能力”。统一语义降低迁移成本,无侵入采集扩大覆盖范围,大模型链路提出了新的观测维度,成本治理则决定整套体系能否长期运转。对多数团队来说,先统一下采集与命名规范,再讨论后端选型,是更稳妥的顺序。