📚 课程目录第4章滚动升级监控指标体系

4. 滚动升级监控指标体系：Pod启动延迟、就绪探针失败率、错误率、P99延迟

滚动升级的故障排查不能依赖单一指标。Pod 启动延迟、就绪探针失败率、错误率、P99 延迟这四个维度构成了一个完整的监控指标体系，分别对应升级过程中的基础设施就绪、健康检查、业务质量和用户体验。任何一个指标异常都可能导致升级回滚或线上事故。

4.1 核心指标体系总览

下表列出了四个核心指标的定义、PromQL 查询示例及故障含义：

指标名称	定义	PromQL 示例	故障含义
Pod 启动延迟	Pod 从创建到进入 Running 状态的时间（秒）	`time() - kube_pod_created{job="kube-state-metrics"}`	镜像拉取慢、资源不足、初始化容器阻塞
就绪探针失败率	就绪探针失败次数 / 总探测次数	`rate(probe_success_total{probe="readiness"}[1m])`	应用启动后未完成预热、依赖服务未就绪
错误率	HTTP 5xx / 总请求数	`sum(rate(http_requests_total{status=~"5.."}[1m])) / sum(rate(http_requests_total[1m]))`	新版本代码缺陷、配置错误、依赖故障
P99 延迟	99% 请求的响应时间（毫秒）	`histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[1m])) by (le))`	性能退化、慢查询、资源争抢

实战建议：在滚动升级期间，这四个指标应同时观察。如果仅看错误率正常，但 P99 延迟翻倍，说明新版本存在性能退化，同样需要回滚。

4.2 指标联动关系与故障排查流程

四个指标之间存在明确的因果关系。下图展示了滚动升级过程中指标异常的典型传递路径：

4.3 各指标详细解读与阈值建议

4.3.1 Pod 启动延迟

该指标反映的是 Pod 从 Pending 到 Running 的时间。在滚动升级中，如果启动延迟超过预期，会导致新旧 Pod 交替节奏被打乱。

正常范围： < 30s（Java 应用 < 60s）
警告阈值： > 60s
严重阈值： > 120s
常见原因： 镜像过大、镜像拉取限速、节点资源不足、PVC 挂载慢

4.3.2 就绪探针失败率

就绪探针失败率是滚动升级中最敏感的指标。如果新 Pod 的就绪探针持续失败，Kubernetes 会阻止流量进入，导致升级卡住。

正常范围： < 1%
警告阈值： > 5%
严重阈值： > 20%
常见原因： 应用启动后未完成预热、依赖的数据库/缓存未就绪、探针路径配置错误

  关键排查技巧： 使用 kubectl describe pod <pod-name> 查看就绪探针的 Events 字段，可以精确看到每次探测失败的原因（如 TCP 连接超时、HTTP 返回码非 200）。

4.3.3 错误率

错误率是业务质量的直接体现。滚动升级期间，应同时监控新版本和旧版本的错误率，以便对比。

正常范围： < 0.1%
警告阈值： > 1%
严重阈值： > 5%
常见原因： 新版本代码 bug、配置项变更错误、API 兼容性问题

4.3.4 P99 延迟

P99 延迟是用户体验的黄金指标。即使错误率为 0，P99 延迟翻倍也意味着新版本存在性能退化。

正常范围： 基线 ±20%
警告阈值： 超过基线 50%
严重阈值： 超过基线 100%
常见原因： 慢查询、内存泄漏、线程池耗尽、依赖服务超时

4.4 滚动升级期间的多维度监控看板

以下是一个推荐的 Grafana 看板布局，用于在滚动升级期间实时监控四个指标：

4.5 自动化告警规则示例

将以下 Prometheus 告警规则部署到集群中，可以在滚动升级期间自动触发告警：

groups:
- name: rolling-upgrade-alerts
  rules:
  - alert: PodStartupDelayHigh
    expr: |
      avg by (deployment) (
        time() - kube_pod_created{job="kube-state-metrics"}
      ) > 60
    for: 2m
    labels:
      severity: warning
    annotations:
      summary: "Pod 启动延迟过高 (deployment {{ $labels.deployment }})"

  - alert: ReadinessProbeFailureRateHigh
    expr: |
      rate(probe_success_total{probe="readiness"}[1m]) < 0.95
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "就绪探针失败率超过 5% (deployment {{ $labels.deployment }})"

  - alert: ErrorRateSpike
    expr: |
      sum(rate(http_requests_total{status=~"5.."}[1m])) 
      / sum(rate(http_requests_total[1m])) > 0.01
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "错误率超过 1% (deployment {{ $labels.deployment }})"

  - alert: P99LatencyDegradation
    expr: |
      histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))
      / scalar(histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m] offset 10m)) by (le)))
      > 1.5
    for: 3m
    labels:
      severity: warning
    annotations:
      summary: "P99 延迟超过基线 50% (deployment {{ $labels.deployment }})"

重要提醒： 滚动升级期间，告警的 for 持续时间应适当缩短（如 1-2 分钟），因为升级窗口通常只有几分钟。如果使用默认的 5 分钟，可能错过回滚时机。

4.6 指标异常时的标准操作流程

Pod 启动延迟高： 检查镜像大小、节点资源、镜像拉取策略。如果超过 120s，手动删除卡住的 Pod 并排查节点状态。
就绪探针失败率高： 立即查看新版本 Pod 的日志和 Events。如果是依赖服务未就绪，考虑调整探针的 initialDelaySeconds。
错误率升高： 暂停滚动升级，保留新旧版本各一个 Pod 进行对比测试。确认是新版本代码问题后执行回滚。
P99 延迟升高： 检查新版本 Pod 的 CPU/内存使用率、慢查询日志。如果延迟超过基线 100%，即使错误率为 0 也应回滚。

通过建立这四个维度的监控指标体系，SRE 团队可以在滚动升级的每个阶段都获得清晰的可见性，从而在故障发生前或发生初期快速决策，保障服务稳定性。