一句话

让生产行为可见可诊断：先定义「正常工作」长什么样，再上结构化日志、RED/USE 指标、trace 和按症状的告警。

何时用

• 适合：加日志、指标、trace、告警；上生产的功能需要「它确实在工作」的证据；线上出事但现有数据说不清。
• 不适合：无运维需求的内部工具；还没定义什么叫「正常」就埋点。

怎么用

给订单服务的关键路径加可观测性：日志、指标、告警都要有

1. 先写清 working 的定义，再决定埋什么。
2. 按问题选信号：日志记事件，指标答聚合问题，trace 追单个请求。
3. 结构化日志；指标上 RED（请求侧）或 USE（资源侧），标签基数必须受控。
4. 分布式 trace 跨异步边界传 context；告警按症状不按原因，配 runbook。
5. 验证遥测本身：演练一次故障，确认信号真的出现。

产出

• 埋点代码、指标与仪表盘定义、告警规则和 runbook。

要点与坑

• 基数失控是指标的失败模式：标签只用小固定集合，user ID、原始 URL 进日志不进指标。
• 告警按症状触发（用户已受影响），原因类信号进仪表盘不触发告警。
• OpenTelemetry 是 vendor-neutral 的默认路径。

关联

• 搭配：addy-ci-cd-and-automation、addy-shipping-and-launch · 上游：addy-incremental-implementation
• 所属：00-addy-概览 · 工作流：W7-交付与运维循环