哪些用例真正使普罗米修斯的摘要指标类型变得必要/独特？

Question

对于 Prometheus 指标集合，如标题，我无法真正找到只能通过 type Summary 完成的用例，似乎它们都可以通过 type Histogram 来完成。

以请求并发指标为例，毫无疑问通过

type Summary

可以完美完成，但我也可以使用

type Histogram

达到同样的效果，如下：

我能看到的唯一区别是：对于摘要，百分位数是在客户端中计算的，它由计数和总和计数器（如直方图类型）以及结果分位数值组成。

所以我有点迷失了什么用例真正使

type Summary

变得必要/独特，请帮助启发我。

Answer 1

摘要指标并不是唯一的，许多其他仪器系统也提供类似的功能 - 例如 Dropwizard 的直方图类型（它内部是直方图，但作为分位数公开）。这是它存在的原因之一，因此来自其他仪器系统的此类类型可以更清晰地映射。

它存在的另一个原因是历史原因。在 Prometheus 中，摘要位于直方图之前，一般建议使用直方图，因为它是可聚合的，而摘要的分位数则不可聚合。另一方面，直方图要求您预先选择存储桶，以便可聚合并允许在任意时间范围内进行分析。

文档中有两种类型的更长的比较。

Answer 2

当存在一组预定义的

percentiles 时，Prometheus 摘要指标类型非常有用，必须为某些指标公开这些

request duration

或

response size

，并且无需计算多个指标的聚合百分位数。例如，如果您需要在单个服务器上测量

request duration

的第 90、97 和 99 个百分位，则构成 Prometheus 摘要的以下指标对于导出非常有用：

http_request_duration_seconds{quantile="0.99"}
http_request_duration_seconds{quantile="0.97"}
http_request_duration_seconds{quantile="0.90"}

用户更喜欢 Prometheus 汇总类型而不是 Prometheus 直方图类型的另一个常见原因是汇总指标更容易理解和处理。

与直方图指标类型相比，摘要指标类型具有以下限制：

摘要指标类型不允许计算除已预定义的百分位数之外的百分位数。例如，如果汇总指标仅公开 0.9 和 0.95 百分位数，则无法从收集的数据计算 0.99 或 0.5 百分位数。
汇总指标类型不允许计算多个汇总指标的聚合百分位数。例如，如果
```
http_request_duration_seconds{quantile="0.99"}
```
指标是针对集群中的每个服务器单独公开的，则无法计算集群中所有服务器的请求持续时间的第 99 个百分位。用户有时会使用
```
avg(http_request_duration_seconds{quantile="0.99"})
```
或
```
max(http_request_duration_seconds{quantile="0.99"})
```
作为解决方法，但结果值可能与实际百分位相差甚远。

Prometheus 中的直方图度量类型也有其自身的问题：

当导出的直方图桶没有足够的测量覆盖范围时，计算的百分位数精度太低。例如，如果
```
http_request_duration_seconds
```
直方图具有以下存储桶：
```
[0-0.1]
```
、
```
(0.1-1.0]
```
、
```
(1.0-10.0]
```
- 并且大多数请求在 0.5 秒内执行，那么所有这些请求都将转到
```
[0.1-1.0]
```
存储桶。但从这样的数据中不可能高精度地计算出任何百分位。
导出的桶数量过多。当用户偶然发现第一个问题时，最常见的反应是创建大量存储桶，以便更好地覆盖测量。这可能会导致高基数问题，因为每个存储桶都作为单独的指标（也称为时间序列）公开。
无法使用不同的桶集聚合直方图。例如，
```
http_request_duration_seconds
```
直方图可能对每个受监控的服务具有不同的存储桶组。那么就不可能计算该直方图在多个服务上的百分位数。

这些问题在 VictoriaMetrics 直方图类型中得到解决（我是 VictoriaMetrics 的核心开发人员） - 详细信息请参阅这篇文章。