Prometheus最佳实践 Summary和Histogram
内容提要
本文介绍了Prometheus中的Histogram和Summary指标的最佳实践，包括它们的用途、适用场景和配置选择。Histogram适用于计数和监控容易，而Summary适用于计算分位数和聚合。在使用Histogram时，需要合理定义区间和确定分位数和滑动窗口。根据需要选择Histogram或Summary，并根据值的范围和分布选择合适的配置。
延伸解读
聚合场景下的选择：Histogram 优于 Summary
当服务有多个实例时，Summary 在客户端预计算的分位数无法直接聚合，平均分位数会产生无意义的值。而 Histogram 在服务端通过 histogram_quantile() 函数可以正确聚合，例如 histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))。因此，如果需要跨实例聚合，应选择 Histogram。
分位数误差的来源与控制
分位数是估计值，误差不可避免。Histogram 的误差取决于桶的宽度，桶越宽误差越大；Summary 的误差在客户端配置，通过 φ 维度控制，如 0.95±0.01。理解误差有助于正确解读监控数据，避免误判 SLO 状态。
SLO 监控与 Apdex 计算
Histogram 适合用于 SLO 监控，例如定义桶界限为 300ms，计算请求在 300ms 内完成的比例。Apdex 分数也可通过 Histogram 估算，配置目标时长和最大忍受时长的桶，但需注意桶是累积的，计算时需除以 2 调整。
配置与性能的权衡
Histogram 需要合理定义桶区间，客户端性能开销小，但服务端计算分位数可能较昂贵；Summary 需预定义分位数和滑动窗口，客户端计算开销大，但服务端消耗低。选择时需根据实际场景权衡配置复杂度和性能。
Q&A
Prometheus中Histogram和Summary的主要区别是什么？
Histogram在客户端暴露桶的计数，在服务端使用histogram_quantile()计算分位数；Summary在客户端计算分位数并直接暴露。Histogram适合聚合，Summary适合准确分位数计算但通常不可聚合。
如何用Histogram计算Apdex分数？
配置两个桶：一个为目标请求时长（如0.3s），另一个为最大忍受时长（如1.2s）。表达式：(sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) by (job) + sum(rate(http_request_duration_seconds_bucket{le="1.2"}[5m])) by (job)) / 2 / sum(rate(http_request_duration_seconds_count[5m])) by (job)。注意桶是累积的，需除以2调整。
为什么Summary在多个实例间聚合分位数通常不可行？
Summary在客户端预先计算分位数，聚合这些分位数（如取平均）会产生统计上无意义的值。例如，avg(http_request_duration_seconds{quantile="0.95"}) 是错误的。而Histogram可以通过histogram_quantile()在服务端正确聚合。
使用Histogram时如何减少分位数估计的误差？
通过合理定义桶的边界来控制误差。桶的宽度决定了误差大小，桶越密集，分位数估计越准确。应根据观测值的范围和分布选择合适的桶布局。
在什么情况下应该选择Summary而不是Histogram？
当需要准确的分位数，且不需要跨多个客户端聚合时，应选择Summary。如果对观测值的范围和分布有了解，Histogram也能提供足够准确的分位数，但若需要精确分位数且不聚合，Summary更合适。
如何用Histogram监控SLO（例如95%的请求在300ms内完成）？
定义一个Histogram，设置桶边界为300ms（le="0.3"）。使用表达式：sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m])) by (job) / sum(rate(http_request_duration_seconds_count[5m])) by (job)。当该比例小于95%时触发告警。
