先说结论

指标用于快速发现趋势和告警，结构化日志提供离散事件细节，分布式追踪还原一次请求的跨服务路径，业务事件解释技术指标背后的用户影响。设计应从 SLI/SLO、关键用户旅程和故障假设出发，确保告警能指向可执行的排查入口。

常用入口指标可围绕请求量、错误、延迟和资源饱和度，并按服务依赖继续下钻。

上下文关联

请求在边界生成或接收 trace id，在服务、消息和异步任务间传播；日志记录 trace id、业务操作 id 和稳定错误码。消息链路还要保留原 trace 关系或 link，避免异步后完全断链。

从 SLO 反推信号

先定义“用户是否成功”：例如支付请求成功率、搜索 P99、消息端到端延迟、配置生效时间。再建立对应 SLI：请求量、错误、延迟、饱和度、Lag、版本差异等。仅采集 CPU、内存和 JVM GC 不能说明用户是否受影响；同样，接口 200 也可能返回业务失败。

用户旅程 SLO -> 服务 SLI -> 依赖指标 -> 日志/trace 证据 -> 可执行告警

告警应表达“预算正在消耗且需要动作”，例如过去 10 分钟 P99 超过阈值并影响 5% 请求，而不是每个 Pod CPU 短暂升高都通知值班人员。

指标设计与高基数

指标标签适合有限集合：service、route template、status class、region、instance；不要把 user_id、order_id、完整 URL、异常堆栈放成 Prometheus label，这会造成时间序列爆炸。高基数字段进入结构化日志或 trace span，按需检索。

请求指标至少区分成功/业务拒绝/系统错误、路由模板和依赖；队列类系统同时记录入口速率、处理速率、当前积压和最老消息年龄。资源指标要和容量上限关联，而不是只画当前值。

结构化日志规范

{
  "timestamp":"2026-07-22T10:00:00Z",
  "level":"WARN",
  "service":"order-api",
  "trace_id":"t-01",
  "operation_id":"op-1001",
  "error_code":"INVENTORY_TIMEOUT",
  "duration_ms":312,
  "retry_count":1
}

日志应可机器解析，字段命名稳定，敏感信息脱敏，避免把 token、身份证、支付数据和完整请求体写入。错误码比自然语言更适合聚合；堆栈应在最有上下文的边界记录一次。

Trace 的采样策略

全量 trace 对高吞吐服务成本很高，可保留错误、慢请求、关键交易和随机代表样本。采样决定要在入口保持一致，否则一条请求在下游突然丢失。异步消息使用 parent/links 传播，批量处理要注意一个 span 包含多少消息，避免产生海量子 span。

告警与成本

告警优先基于用户可感知 SLO 消耗和持续异常，减少瞬时噪声。高基数字段不能直接做指标标签，明细进入日志或追踪；采样要保留错误、慢请求和关键业务，并设置数据保留层级。

容易踩坑的地方

日志越多不等于可观测性越好，无结构、无上下文和重复堆栈只增加成本。平均延迟会掩盖长尾，应关注分位数、错误预算和分组后的异常差异。

告警到排障闭环

告警 -> 确认用户影响/变更时间 -> 看入口 P99/错误预算
     -> trace 找慢依赖 -> 日志核对错误码与参数
     -> 指标验证容量/资源 -> 止损/修复 -> 验证 SLO 恢复

告警页面应提供 dashboard、最近发布、关联 trace 查询和 runbook 链接。故障结束后记录检测时间、定位时间、恢复时间、误报和缺失信号，推动新增监控而非只扩大日志量。

成本和保留

按数据价值分层保留：指标保留长周期用于趋势，错误和慢 trace 保留更久，普通 debug 日志短期采样；冷热存储、压缩和脱敏都要纳入预算。可观测性系统本身也需要限流，避免故障风暴把日志平台打崩。

常见问题

追问：线上故障如何从告警开始定位？

先确认用户范围和变更时间线，再按入口指标定位服务与依赖，通过 trace 找慢点或错误点，用结构化日志验证具体失败，最后用业务指标确认恢复。

追问：为什么不把所有请求都采全量 Trace？

成本、存储、网络和查询压力可能随流量线性增长。应优先保留错误、慢请求、关键交易和代表样本，并保证跨服务采样策略一致。

追问：日志里应该记录完整请求体吗？

通常不应。敏感信息、超大 payload 和个人数据会带来安全与成本风险；应记录稳定操作 ID、摘要、错误码和必要字段，调试数据使用受控采样。

追问：业务指标和技术指标冲突怎么办？

先确认口径和时间窗口。例如接口 200 但支付成功率下降，说明技术健康指标没有覆盖业务结果；应把业务事件和技术 trace 关联起来定位。

追问：指标告警为什么会疲劳？

阈值过多、没有用户影响、没有去重和恢复条件都会产生噪声。以 SLO/错误预算为核心，按持续时间和影响范围触发可执行告警。