导语
在 React/Compiler、PostgreSQL 18、云原生边缘计算等多线演进背景下，后端可观测是“共同底座”。OpenTelemetry（OTel）成为事实标准，但真正的一体化落地远不止“装个 SDK”。本文给出 2025 年可观测落地的 8 项原则与工程清单。
八项原则
- 一体化：Trace/Metric/Log 三位一体，语义一致；
- 以 SLO 为锚：把可观测与用户体验挂钩（INP、延迟、错误率、可用性）；
- 低侵入：SDK/自动注入/Sidecar 结合，降低改造成本；
- 采样与成本：动态采样、采集过滤、保留策略；
- 统一标识：TraceID/SpanID 贯通到日志与指标；
- 数据质量：字段规范、标签治理与卡片化展示；
- 事故闭环：从告警到事后复盘（Root Cause + Runbook）；
- 开放生态：标准协议与可替换后端，避免锁定。
工程清单
- SDK：语言栈统一版本、自动注入优先；
- 网关：OTLP 收敛、限流与脱敏；
- 标签：服务/版本/环境/区域统一命名；
- SLO：定义服务 SLI 与目标，接入预算与告警；
- 存储：冷热分层与生命周期；
- 可视化：从“跨层级视图”直达“问题工单”；
- 变更挂钩：把发布/配置变更打点进追踪；
- 训练与文化：让开发者以 Span 视角思考问题。
采样与告警设计（实践要点）
- 采样：基于错误/延迟的动态提高采样率；
- 告警：以 SLO 为锚，避免“阈值型噪声”，引入冷却时间与聚合；
- 演练：季度级“可观测演习”，验证链路完整与 Runbook 有效。
反模式（摘录）
- 只接 Trace 不做指标与日志贯通；
- 标签任意扩散，导致成本飙升与查询困难；
- 告警泛滥，值班疲劳；
- 把 OTel 当“打点工具”，忽视团队文化与流程。
结语
OTel 不是工具，是“度量语言”。当可观测以 SLO 与工程术语表达，后端的复杂性就被压到可控范围之内。
参考
- OpenTelemetry 官方文档与社区实践（2025）
