4. Prometheus 核心指标类型：Counter、Gauge、Histogram、Summary 的适用场景与 MTTR 关联
在 MTTR 复盘过程中，不同阶段的故障数据需要不同类型的指标来承载。Prometheus 提供的四种核心指标类型——Counter、Gauge、Histogram、Summary——各自具备独特的语义和计算特性。选错指标类型，轻则导致复盘数据失真，重则掩盖故障根因。本节将逐一拆解每种指标的定义、适用场景，并直接关联到 MTTR 各阶段（发现、定位、恢复）的复盘口径优化。
4.1 指标类型全景对比
| 指标类型 | 核心语义 | 典型值域 | 聚合方式 | MTTR 关联阶段 |
|---|---|---|---|---|
| Counter | 只增不减的累计值 | 非负整数 | rate() / increase() | 发现阶段（错误率、请求量） |
| Gauge | 可增可减的瞬时值 | 任意实数 | avg() / max() / min() | 定位阶段（资源水位、队列深度） |
| Histogram | 分桶统计的分布数据 | 桶计数 + 总和 + 总数 | histogram_quantile() | 定位阶段（延迟分布、异常分位点） |
| Summary | 预计算的分位值 | 分位值 + 总和 + 总数 | 直接查询分位值 | 恢复阶段（SLO 验证、服务质量确认） |
复盘口径关键点： Counter 适合衡量“发生了多少次”，Gauge 适合衡量“当前是多少”，Histogram 适合衡量“分布怎么样”，Summary 适合衡量“约定好的分位值是否达标”。MTTR 复盘时，四个类型需要组合使用，单一类型无法覆盖全链路。
4.2 Counter：故障发现的第一道防线
Counter 是最基础的指标类型，其值在进程生命周期内单调递增。重启后归零，但 Prometheus 的 rate() 函数会自动处理重置场景。
适用场景
- 请求总量：
http_requests_total - 错误计数：
http_requests_errors_total - 队列写入量：
queue_writes_total
MTTR 关联：发现阶段
故障发现的核心是“异常趋势识别”。通过 rate(error_total[5m]) 计算错误率，当错误率突增时触发告警。复盘时，Counter 数据用于回答：
- 故障从哪个时间点开始？
- 错误量级是多少？
- 故障期间累计影响了多少请求？
# 错误率突增检测（PromQL）
rate(http_requests_errors_total[5m]) > 0.05
# 故障期间累计错误数（复盘用）
increase(http_requests_errors_total[1h])
避坑提示： 不要对 Counter 直接使用
avg() 或 sum() 聚合原始值，必须先用 rate() 或 increase() 转换为速率或增量，否则重启后数值归零会导致聚合结果失真。
4.3 Gauge：故障定位的实时仪表盘
Gauge 反映系统的瞬时状态，可升可降。它不依赖时间窗口计算，直接反映当前值。
适用场景
- CPU/内存使用率：
node_cpu_usage_percent - 队列当前深度：
queue_depth - 连接数：
active_connections - 温度/水位：
sensor_temperature_celsius
MTTR 关联：定位阶段
当故障告警触发后，Gauge 数据帮助快速定位根因：
- CPU 是否被打满？
- 内存是否泄漏？
- 连接池是否耗尽？
# 定位 CPU 打满的节点
max(node_cpu_usage_percent) by (instance) > 0.9
# 查看故障时刻的队列深度（精确到秒）
queue_depth{instance="web-01"} @ 1712345678
复盘口径注意： Gauge 的瞬时值在故障复盘时容易丢失上下文。建议在告警触发时，自动记录关键 Gauge 指标的“故障前 5 分钟均值”和“故障峰值”，作为复盘基线数据。
4.4 Histogram：延迟分布与异常分位点
Histogram 将观测值分配到预定义的桶（bucket）中，同时记录总和与总数。它不存储精确值，而是存储分布统计。
适用场景
- 请求延迟：
http_request_duration_seconds_bucket - 响应大小：
http_response_size_bytes_bucket - 批处理耗时：
batch_processing_seconds_bucket
MTTR 关联：定位阶段（延迟异常）
故障定位时，平均延迟往往掩盖问题。Histogram 通过分位点暴露尾部延迟：
# 计算 P99 延迟（故障期间）
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
# 对比故障前后 P50 与 P99 的差距
histogram_quantile(0.50, rate(http_request_duration_seconds_bucket[5m]))
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))
复盘关键指标： 故障期间 P99 延迟与基线 P99 延迟的比值。如果 P99 飙升而 P50 正常，说明是少数请求被阻塞（如慢查询、锁竞争），而非整体过载。
桶设计原则
| 场景 | 推荐桶范围 | 说明 |
|---|---|---|
| API 延迟（毫秒级） | 5, 10, 25, 50, 100, 250, 500, 1000 | 覆盖正常与异常区间 |
| 批处理耗时（秒级） | 1, 5, 10, 30, 60, 120, 300 | 关注超时边界 |
| 响应大小（KB） | 1, 10, 100, 500, 1024, 5120 | 匹配实际业务分布 |
4.5 Summary：SLO 验证与恢复确认
Summary 在客户端预计算分位值（如 P50、P90、P99），服务端直接读取结果。它不依赖 histogram_quantile() 计算，适合对分位值精度要求高、且已知分位点固定的场景。
适用场景
- SLO 监控：
api_latency_seconds{quantile="0.99"} - 固定分位值报告：P50、P90、P99
- 高精度要求：金融交易、实时计费
MTTR 关联：恢复阶段
故障恢复后，需要验证服务是否回到 SLO 范围内。Summary 直接提供分位值，无需二次计算：
# 验证 P99 延迟是否恢复到 SLO 以内
api_latency_seconds{quantile="0.99"} < 0.5
# 对比恢复前后 P50 与 P99 的差值
api_latency_seconds{quantile="0.50"}
api_latency_seconds{quantile="0.99"}
选择建议： 如果分位点固定且需要跨服务聚合，优先使用 Summary；如果需要灵活调整分位点或进行 ad-hoc 分析，使用 Histogram。MTTR 复盘时，Summary 适合“恢复确认”，Histogram 适合“根因分析”。
4.6 四种指标在 MTTR 复盘中的协同关系
4.7 常见误用与复盘口径修正
| 误用场景 | 错误做法 | 后果 | 修正方案 |
|---|---|---|---|
| Counter 直接聚合 | sum(error_total) |
重启后归零，聚合值异常 | 使用 sum(rate(error_total[5m])) |
| Gauge 计算速率 | rate(memory_usage[5m]) |
语义错误，Gauge 无速率概念 | 使用 avg(memory_usage) 或 max(memory_usage) |
| Histogram 桶过少 | 只设 3 个桶 | 分位点计算误差大 | 按业务分布设置 6~10 个桶 |
| Summary 分位点不匹配 | 只记录 P50，复盘需要 P99 | 无法分析尾部延迟 | 同时记录 P50、P90、P99 |
复盘口径红线： 不要在复盘报告中混用指标类型语义。例如，用 Gauge 的瞬时值推导“故障期间总错误数”，或用 Counter 的原始值描述“当前 CPU 使用率”。每种指标只能回答其设计范围内的问题。
4.8 本章小结
- Counter：故障发现的核心，通过速率检测异常趋势。
- Gauge：故障定位的实时数据源，反映资源水位与系统状态。
- Histogram：延迟分布分析利器，暴露尾部延迟与异常分位点。
- Summary：恢复阶段 SLO 验证工具，直接提供约定分位值。
- 四种指标在 MTTR 复盘中的协同关系：Counter → Gauge + Histogram → Summary，覆盖发现、定位、恢复全链路。