OpenTelemetry、SLO、告警与故障响应

报警响起时，最需要知道的是谁受影响、从什么时候开始、接下来查哪里。日志、指标与追踪要围绕这些问题组织。SLO 则帮助团队明确可接受的服务水平，避免每一点波动都触发同样的响应。

可观测性从服务目标和诊断问题出发，用日志、指标、追踪和 profile 提供证据，再以告警和 runbook 驱动响应。

1. 本文覆盖范围

• Telemetry 与 context propagation
• RED/USE 与业务指标
• SLI/SLO/error budget
• 告警、事故指挥和复盘

2. 核心知识详解

1. OpenTelemetry

OTel 提供 API、SDK、语义约定、OTLP 和 Collector，把 trace、metric、log 上下文跨进程关联。

• 自动 instrumentation 与手工业务 span 配合。
• resource 标识 service/version/environment。
• collector 负责批量、重试、过滤和导出，设有界队列。

这里容易混淆的是： 采集成功不代表数据有用；span 名、属性基数和业务语义需要设计。

2. 指标和关联

入口用 Rate/Errors/Duration，资源用 Utilization/Saturation/Errors，关键业务状态另设指标。trace id 连接日志与调用链。

• 标签只用有界枚举，不用 userId/orderId。
• histogram 桶与 SLO 阈值对齐。
• 日志记录决策和异常，metric 负责聚合趋势。

这里容易混淆的是： 百分位不能通过实例百分位取平均得到全局百分位，使用可聚合直方图。

3. SLI/SLO 与错误预算

SLI 是用户可感知测量，SLO 是目标，错误预算表示目标窗口允许的不良事件。多窗口 burn-rate 告警兼顾速度和置信。

• 从成功率、可用性、正确性、延迟和新鲜度选 SLI。
• 计划停机是否计入由产品承诺决定。
• 预算消耗影响发布速度和可靠性投资。

这里容易混淆的是： SLO 是目标值，不是一个固定百分比。不要把“通常不宜为可用性选择 100%”写成“定义上禁止 100%”。目标若没有容错空间，就很难借助错误预算权衡发布与可靠性。先说明统计窗口、有效请求和成功标准，再讨论 99.9% 对这项服务是否合适。参见 Google SRE：实施 SLO。

4. 事故响应

告警应可行动，包含影响、仪表盘、变更和 runbook。事故中明确指挥、沟通、操作和记录角色，恢复后做无责复盘。

• 先限制影响，再恢复，再找根因。
• 操作带时间线、审批和回滚。
• 复盘产出有所有者/期限的系统改进。

这里容易混淆的是： 复盘只写“加强注意”不会降低复发概率；行动应修改系统、测试、门禁或监控。

3. 工程链路

4. 教学示例（结合本章运行前提）

Collector 在这里接收 OTLP trace，批量处理后转发。配置省略了具体认证和部署设置，${env:OBSERVABILITY_ENDPOINT} 使用 Collector 的显式环境变量提供者；启动前配置该变量，并按选用发行版检查组件是否可用。先用一条测试 trace 验证全程，再接入真实流量。

yaml复制
receivers:
  otlp:
    protocols: { grpc: {}, http: {} }
processors:
  batch: {}
exporters:
  otlphttp:
    endpoint: ${env:OBSERVABILITY_ENDPOINT}
service:
  pipelines:
    traces: { receivers: [otlp], processors: [batch], exporters: [otlphttp] }

5. 实践与验证

1. 为登录服务定义可用性和延迟 SLI/SLO。
2. 接入 OTel 并验证 HTTP、数据库和消息 context。
3. 写一份含停止条件、回滚和沟通的故障 runbook。

6. 掌握检查

• 能控制属性基数。
• 能定义用户导向 SLI。
• 能使用错误预算。
• 能运行可复盘事故响应。

参考资料

• OpenTelemetry Java
• OpenTelemetry Semantic Conventions
• Google SRE Workbook: Alerting on SLOs