8.1 可观测性信号：从用户症状到系统状态

服务已经在 K8s 上稳定交付，用户却只留下一句“报告生成很慢”。单看某台机器的 CPU 或一行错误日志都不足以解释整条请求路径。值班同事该从用户症状出发，怎样组合指标、日志和追踪来缩小范围？

监控常用于检查预先知道的条件；可观测性让团队借助系统输出解释未知内部状态。目标不是“收集三种数据”，而是缩短从用户影响到可操作原因的路径。

先从用户可见结果开始

服务入口优先使用 RED：

• Rate：请求或任务速率；
• Errors：对用户无效的结果比例；
• Duration：延迟分布。

基础资源可用 USE：

• Utilization：资源忙碌比例；
• Saturation：排队或超额需求；
• Errors：资源错误。

它们不是固定仪表盘模板。队列消费者还需要 lag/最老消息年龄，批作业需要新鲜度和完成率，数据库需要事务与复制信号。

Metrics 适合聚合趋势和告警

Counter 累计事件数，在一次运行内单调增加，进程重启等情况会重置；计算速率时必须处理重置。Gauge 表示可增减的当前测量值，Histogram 表示分布。延迟不能只看平均值，应保留直方图以计算分位和 SLO 阈值比例。

例如经典 Histogram 配置了 300 ms 的桶边界，10,000 次请求中有 8,000 次落在该累计桶内，则“延迟不超过 300 ms”的比例为 80%。若没有相应边界，就不能把相邻桶估算当作精确阈值计数；分位数也受桶精度影响。多个实例的 p99 不能直接求平均，应先合并兼容的分布数据再估算。

Label 形成时间序列维度。service、route、status_code 通常可控；user_id、完整 URL、trace ID 会产生高基数并拖垮成本和查询。

不要把业务 ID 放进 metric label；需要逐请求定位时使用 trace 或结构化日志。

Logs 记录离散事件

请求内的结构化日志应包含时间、严重性、服务、版本、环境、消息、有效 trace/span ID 和稳定错误码。后台独立事件没有当前 span 时，不应伪造一个 ID。下面是应用自定义 JSON 日志，采集器需要把资源属性和上下文字段映射到对应日志模型；它不是 OTLP 协议报文。

{
  "timestamp": "2026-09-05T12:00:00Z",
  "severity": "ERROR",
  "service.name": "scoring",
  "service.version": "42.0.0",
  "deployment.environment.name": "production",
  "event": "settlement_failed",
  "message": "Settlement rejected because the score version changed",
  "matchId": "m-8472",
  "code": "VERSION_CONFLICT",
  "traceId": "4bf92f3577b34da6a3ce929d0e0e4736",
  "spanId": "00f067aa0ba902b7"
}

日志不是把对象和请求体全部序列化。密钥、token、个人信息和支付数据需要默认屏蔽，并设置访问控制和保留期限。

Traces 表达一次工作跨边界的路径

Trace 由 spans 组成。Span 记录操作、父子/链接关系、时间、状态、attributes 和 events。

异步消息不总是严格父子关系，可以用 links 表达一个消费操作由多个消息或批次触发。长业务流程也不应强行成为一个持续数天的 trace，可用 correlation ID 连接多个 traces。

三种信号通过身份相关联

SLO 告警：错误率上升
  → 按 service.version/zone 定位
  → exemplar/trace 找慢请求
  → span 指向数据库等待
  → 关联该实例结构化日志

统一 service.name、版本、部署环境、区域和 trace context，才能让这些跳转成立。Exemplar 是某次指标观测附带的追踪引用，不是另建一个 trace ID label；若被引用的 trace 未保留或已过期，跳转仍会找不到记录。

观测不是证明因果

两个指标同时变化可能只是相关。Telemetry 还会采样、丢失、延迟或被错误埋点。诊断需要结合变更记录、实验、业务不变量和底层证据。

下一课说明如何用 OpenTelemetry 和 Collector 建立不拖垮业务的采集管线。

参考资料

• Prometheus, Histograms and summaries

• Prometheus, Metric types

• OpenTelemetry, Deployment environment attributes

• OpenTelemetry, Concepts

• Google SRE Workbook, Monitoring