4. 回滚前的健康检查：检查 Collector 状态、数据流完整性、目标系统连通性、告警基线

在触发任何回滚操作之前，必须对当前管线状态进行全面的健康检查。健康检查的目的是确认“当前状态是否可回滚”以及“回滚后能否快速恢复”。本章将健康检查拆解为四个维度：Collector 状态、数据流完整性、目标系统连通性、告警基线。每个维度都有明确的检查项、通过标准和失败处理建议。

4.1 健康检查总览

下表列出了四个维度的核心检查项与快速判定标准，供 SRE 在回滚前逐项核对。

4.2 Collector 状态检查

Collector 是管线的核心代理，其健康状态直接影响数据采集与转发。检查分为三个子步骤：

1. 进程存活检查：通过 systemd 或容器编排工具确认 Collector 进程持续运行超过 5 分钟，无频繁重启。
2. 端口可达性：使用 curl 或 grpcurl 验证 Collector 的 gRPC 端口（默认 4317）和 HTTP 端口（默认 4318）是否正常响应。
3. 资源水位：检查 Collector 的内存使用率（process_runtime_memory_bytes）和 CPU 使用率（process_cpu_seconds_total），确保未超过阈值。

# 检查 Collector 进程
systemctl status otelcol-contrib

# 检查 gRPC 端口
grpcurl -plaintext localhost:4317 list

# 检查内存使用（PromQL）
otelcol_process_memory_rss{service="otelcol"} / otelcol_process_memory_limit{service="otelcol"} > 0.8

4.3 数据流完整性检查

数据流完整性是回滚前最关键的检查项。如果当前管线已经出现数据丢失或严重积压，回滚可能加剧问题。检查点包括：

• 接收速率 vs 导出速率：使用 Collector 自暴露指标 otelcol_receiver_accepted_spans 和 otelcol_exporter_sent_spans，对比两者差值。差值超过 5% 说明存在丢数风险。
• 错误率：检查 otelcol_exporter_send_failed_spans 与总发送量的比值，应低于 0.1%。
• 队列积压：查看 otelcol_exporter_queue_size 指标，若持续超过队列容量的 50%，说明导出端存在瓶颈。

# 数据流健康度 = 1 - (发送失败数 / 总发送数)
1 - (
  sum(rate(otelcol_exporter_send_failed_spans[5m]))
  /
  sum(rate(otelcol_exporter_sent_spans[5m]))
)

4.4 目标系统连通性检查

回滚操作通常涉及修改导出器配置，因此必须确保目标后端（如 Jaeger、Prometheus、Elasticsearch）在当前网络环境下可正常写入。检查清单：

4.5 告警基线检查

回滚前必须确认当前告警状态处于“可干预”水平。检查内容包括：

• P0/P1 告警数量：当前是否有未解决的 P0 告警？P1 告警是否超过 3 条？若存在，需先处理或确认与回滚无关。
• 告警延迟：检查告警系统的处理延迟（如 Alertmanager 的 alertmanager_alerts 指标），确保延迟 < 30 秒，避免回滚期间告警风暴。
• 静默期：确认当前不在组织的变更静默窗口内（如大促、核心业务高峰期）。

4.6 健康检查流程总图

下图展示了回滚前健康检查的完整流程，从四个维度并行检查到最终决策。

4.7 检查结果记录与决策

完成四个维度的检查后，SRE 应将结果记录到回滚工单或 Runbook 日志中。推荐使用以下格式：

# 健康检查记录模板
时间戳: 2025-03-21T14:30:00Z
检查人: sre-ops-01

Collector 状态: ✅ 通过 (进程运行 12min, 内存 62%)
数据流完整性: ✅ 通过 (错误率 0.02%, 队列深度 23%)
目标系统连通性: ✅ 通过 (Jaeger 200, ES 200)
告警基线: ✅ 通过 (P0:0, P1:1, 延迟 12s)

结论: 全部通过，允许执行回滚。