📚 课程目录第4章资源健康检测定义

4. 资源健康检测定义：健康检测的维度与黄金信号

在服务目录资源健康检测方案中，健康检测的核心目标是回答一个关键问题：“资源是否在正常工作？”。为了系统化地回答这个问题，业界普遍采用 Google SRE 提出的 “四个黄金信号”（Latency, Traffic, Errors, Saturation）作为衡量维度。本章将详细定义这四个维度，并说明如何将其映射到 Prometheus 告警规则中。

核心原则： 黄金信号并非孤立存在，它们共同构成资源健康的完整视图。单一维度的健康不代表整体健康，例如低延迟但高错误率的服务仍然不可用。

4.1 四个黄金信号概述

黄金信号将复杂的系统状态抽象为四个可观测、可量化的指标类别。下表总结了每个维度的定义、典型指标及在 Prometheus 中的常见表达方式：

维度	定义	典型 Prometheus 指标	健康含义
延迟 (Latency)	请求从发出到收到响应所花费的时间	`http_request_duration_seconds`	反映资源响应速度，高延迟通常意味着性能瓶颈或过载
流量 (Traffic)	系统处理的请求数量或数据量	`http_requests_total`	反映资源负载水平，异常流量可能预示攻击或故障
错误率 (Errors)	请求失败的比率（显式错误 + 隐式错误）	`http_requests_total{status=~"5.."}`	直接反映资源可用性，高错误率是告警的首要触发条件
饱和度 (Saturation)	资源被使用的程度，通常指容量上限的占比	`node_memory_MemAvailable_bytes`	预示资源即将耗尽，是容量规划和预防性告警的关键

  关键区别： 错误率衡量的是“请求是否成功”，而饱和度衡量的是“资源是否还有余量”。一个饱和度高的系统可能暂时没有错误，但随时可能因资源耗尽而崩溃。

4.2 黄金信号在资源健康检测中的映射关系

不同的资源类型（如计算、网络、存储）对黄金信号的侧重点不同。下图展示了黄金信号与常见资源类型的映射关系，以及它们如何共同构成健康检测的决策基础。

4.3 各维度的详细定义与告警阈值设计

4.3.1 延迟 (Latency)

延迟衡量的是资源响应请求的速度。在 Prometheus 中，通常使用 Histogram 或 Summary 指标类型来采集延迟数据。告警阈值应关注 高百分位延迟（如 p99、p95），而非平均值，因为平均值会掩盖长尾延迟问题。

# 示例：检测 p99 延迟超过 500ms 持续 5 分钟
- alert: HighLatency
  expr: histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) > 0.5
  for: 5m
  labels:
    severity: critical
  annotations:
    summary: "{{ $labels.instance }} 的 p99 延迟为 {{ $value }}s，超过 0.5s"

4.3.2 流量 (Traffic)

流量反映系统负载。对于 Web 服务，流量通常指 QPS（每秒请求数）；对于数据库，指 TPS（每秒事务数）。流量告警通常用于检测 异常突增（可能预示 DDoS 或热点事件）或 异常突降（可能预示上游故障）。

# 示例：检测 QPS 突增超过基线 3 倍
- alert: TrafficSurge
  expr: rate(http_requests_total[5m]) / avg(rate(http_requests_total[1h])) > 3
  for: 2m
  labels:
    severity: warning
  annotations:
    summary: "流量突增，当前 QPS 为基线 {{ $value }} 倍"

4.3.3 错误率 (Errors)

错误率是健康检测中最直接的维度。错误分为 显式错误（如 HTTP 5xx）和 隐式错误（如返回 200 但业务逻辑错误）。告警阈值通常设置为 错误率 > 0% 或 错误率 > 1%，具体取决于服务 SLA。

# 示例：检测 HTTP 5xx 错误率超过 1%
- alert: HighErrorRate
  expr: sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.01
  for: 3m
  labels:
    severity: critical
  annotations:
    summary: "错误率 {{ $value | humanizePercentage }}，超过 1%"

4.3.4 饱和度 (Saturation)

饱和度衡量资源使用程度。常见的饱和度指标包括 CPU 使用率、内存使用率、磁盘 IO 等待时间、网络带宽利用率等。饱和度告警是 预防性告警，通常在资源使用率达到 80%-90% 时触发，预留缓冲时间进行扩容。

# 示例：检测节点内存使用率超过 85%
- alert: HighMemoryUsage
  expr: (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) > 0.85
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: "节点 {{ $labels.instance }} 内存使用率 {{ $value | humanizePercentage }}"

4.4 黄金信号与 USE/RED 方法论的关系

在 SRE 实践中，黄金信号常与 USE 方法论（Utilization, Saturation, Errors）和 RED 方法论（Rate, Errors, Duration）结合使用。下表对比了这三种方法论在资源健康检测中的适用场景：

方法论	适用资源类型	核心维度	与黄金信号的关系
USE	基础设施资源（CPU、内存、磁盘、网络）	利用率、饱和度、错误	USE 的“饱和度”和“错误”直接对应黄金信号；“利用率”是饱和度的前置指标
RED	微服务、API 网关、应用层	速率、错误、持续时间	RED 的“速率”对应黄金信号的“流量”；“持续时间”对应“延迟”；“错误”对应“错误率”
黄金信号	通用（覆盖基础设施 + 应用层）	延迟、流量、错误率、饱和度	综合 USE 和 RED，提供更全面的健康视图

实践建议： 在服务目录资源健康检测中，建议对基础设施资源使用 USE 方法论 定义告警，对应用服务使用 RED 方法论 定义告警，最终统一映射到黄金信号的四个维度中，确保告警体系的一致性。

4.5 黄金信号在告警规则中的组合使用

单一维度的告警可能产生误报。例如，高延迟可能由高饱和度引起，此时同时触发延迟告警和饱和度告警会造成告警风暴。因此，建议在告警规则中组合多个黄金信号，实现更精准的检测。

下图展示了一个组合告警的决策流程：

通过组合延迟和饱和度，可以快速区分性能问题的根因是 容量不足 还是 应用代码缺陷，从而减少告警排查时间。

4.6 本章小结

四个黄金信号（延迟、流量、错误率、饱和度）是资源健康检测的通用框架，覆盖了从用户体验到系统容量的全维度。
告警阈值设计应基于高百分位延迟、错误率百分比、饱和度百分比等具体指标，避免使用平均值。
USE 和 RED 方法论是黄金信号在基础设施和应用层的具体实践，建议在服务目录中统一使用。
组合告警可以有效减少误报，提升告警的根因定位能力。