4. Histogram vs Summary：Prometheus 中两种分位数计算方式的优劣对比与选型
在 Prometheus 生态中，计算分位数（P50、P90、P99）有两种原生方式：Histogram（直方图）和 Summary（摘要）。虽然两者都能输出百分位指标，但其底层实现、资源消耗、聚合能力与适用场景存在本质差异。选型错误会导致告警失真或性能瓶颈。
核心结论： 在告警降噪与多维度聚合场景下，Histogram 是首选；Summary 仅适用于无法容忍计算延迟的“单实例精确分位数”场景。
4.1 核心差异对比
| 对比维度 | Histogram（直方图） | Summary（摘要） |
|---|---|---|
| 分位数计算位置 | 服务端（Prometheus Server） | 客户端（应用进程内） |
| 聚合能力 | 支持多维度聚合（sum/avg 跨实例） |
不支持聚合，只能查看单实例 |
| 存储开销 | 固定桶数 × 标签基数（可预测） | 固定分位数数量（通常 3~5 个） |
| 精确度 | 取决于桶划分粒度（近似计算） | 流式精确计算（误差可控） |
| 延迟影响 | 无（客户端仅累加计数器） | 有（需在请求路径上排序/计算） |
| 分位数可扩展性 | 查询时可任意指定分位数（P50/P95/P99.9） | 必须在代码中预定义，无法动态增加 |
| 典型适用场景 | 多服务聚合告警、全局延迟监控 | 单实例延迟精确追踪、无法接受近似值 |
选型口诀： 要聚合、要灵活、要告警 → 选 Histogram；要精确、单实例、低基数 → 选 Summary。
4.2 架构对比：计算路径的差异
下图展示了两种方案在数据采集、计算与查询链路上的根本区别：
4.3 聚合能力：Histogram 的优势
在微服务架构中，告警通常需要关注全局聚合延迟（例如：所有实例的 P99 延迟）。Histogram 支持通过 sum(rate()) 将多个实例的桶数据合并后再计算分位数，而 Summary 无法做到这一点。
# Histogram 支持聚合查询（正确做法）
histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[5m])) by (le, service))
# Summary 只能查询单实例（无法聚合）
http_request_duration_seconds{quantile="0.99", instance="web-01"}
常见陷阱： 如果使用 Summary 做跨实例聚合（如
avg(http_request_duration_seconds{quantile="0.99"})），得到的是“各实例 P99 的平均值”，而非“全局 P99”。这在统计学上是错误的，会导致告警阈值严重偏差。
4.4 资源开销与性能权衡
| 资源维度 | Histogram | Summary |
|---|---|---|
| 客户端 CPU | 极低（仅原子计数器累加） | 较高（需维护排序数据结构） |
| 客户端内存 | 固定（桶数 × 标签组合） | 固定（分位数数量 × 滑动窗口） |
| 网络传输 | 桶计数器（通常 10~20 个值） | 分位数结果（通常 3~5 个值） |
| 服务端计算 | 查询时计算（可缓存） | 无（直接读取） |
| 存储膨胀风险 | 高（标签基数 × 桶数） | 低（仅预定义分位数） |
性能建议： 对于高并发服务（QPS > 10k），Histogram 的客户端开销几乎为零，而 Summary 的流式计算可能成为瓶颈。建议优先使用 Histogram，并通过合理设置桶边界控制存储成本。
4.5 选型决策树
根据实际场景，可按照以下流程快速决策：
4.6 实战选型建议
- 告警降噪场景（推荐 Histogram）： 需要跨实例聚合 P99/P90 延迟，并基于聚合结果设置动态阈值。Histogram 的
histogram_quantile配合sum(rate())是标准做法。 - 单实例精确调试（推荐 Summary）： 当需要精确追踪某个特定实例的延迟分布，且不关心聚合时，Summary 的流式精确计算更有优势。
- 高基数标签场景（谨慎使用 Histogram）： 如果标签组合超过 1000 种，Histogram 的存储开销会急剧膨胀。此时可考虑降低桶数量或改用 Summary。
- 动态分位数需求（必须用 Histogram）： 如果未来可能需要查看 P99.9 或 P99.99，而当前只配置了 P50/P90/P99，Histogram 允许查询时任意指定分位数，Summary 则需要修改代码并重启应用。
最终建议： 在 90% 的监控与告警场景中，Histogram 是更优选择。它牺牲了客户端精确度，换来了服务端聚合能力与查询灵活性，这与告警降噪“全局视角、动态阈值”的核心需求高度匹配。Summary 应仅作为精确调试的补充工具，而非告警数据源。