聚合

---

我们知道 Prometheus 的时间序列数据是多维数据模型，我们经常就有根据各个维度进行汇总的需求。

基于标签聚合

---

request_duration_seconds_count 就是一共有多少个请求request_duration_seconds_sum 是总的延迟时间，就是所有请求一共花了多长时间

例如我们想知道我们的 demo 服务每秒处理的请求数，那么可以将单个的速率相加就可以。

sum(rate(demo_api_request_duration_seconds_count{job="demo"}[5m]))

可以得到如下所示的结果：

 但是我们可以看到绘制出来的图形没有保留任何标签维度，一般来说可能我们希望保留一些维度，例如，我们可能更希望计算每个 instance 和 path 的变化率，但并不关心单个 method 或者 status 的结果，这个时候我们可以在 sum() 聚合器中添加一个 without() 的修饰符：

sum without(method, status) (rate(demo_api_request_duration_seconds_count{job="demo"}[5m]))

上面的查询语句相当于用 by() 修饰符来保留需要的标签的取反操作：by()类似于SQL语句里面的group by，这里是根据什么去做聚合。

sum by(instance, path, job) (rate(demo_api_request_duration_seconds_count{job="demo"}[5m]))

 现在得到的 sum 结果是就是按照 instance、path、job 来进行分组去聚合的了：

最后同理apiserver也是一样的

sum by(verb)(rate(apiserver_request_duration_seconds_count[5m]))

这里的分组概念和 SQL 语句中的分组去聚合就非常类似了。

除了 sum() 之外，Prometheus 还支持下面的这些聚合器/聚合函数：（如果不加上by进行分组，那么计算的是整个时间序列的值，只是一个值而已，没有标签维度）

sum()：对聚合分组中的所有值进行求和min()：获取一个聚合分组中最小值max()：获取一个聚合分组中最大值avg()：计算聚合分组中所有值的平均值stddev()：计算聚合分组中所有数值的标准差stdvar()：计算聚合分组中所有数值的标准方差count()：计算聚合分组中所有序列的总数    计算序列的总数,要和sum取分开count_values()：计算具有相同样本值的元素数量bottomk(k, ...)：计算按样本值计算的最小的 k 个元素topk(k，...)：计算最大的 k 个元素的样本值quantile(φ，...)：计算维度上的 φ-分位数(0≤φ≤1)group(...)：只是按标签分组，并将样本值设为 1。

练习：

1.按 job 分组聚合，计算我们正在监控的所有进程的总内存使用量（process_resident_memory_bytes 指标）：

sum by(job) (process_resident_memory_bytes)

 2.计算 demo_cpu_usage_seconds_total 指标有多少不同的 CPU 模式：

count (group by(mode) (demo_cpu_usage_seconds_total))

3.计算每个 job 任务和指标名称的时间序列数量：

count by (job, __name__) ({__name__ != ""})

每个指标里面都有_name_ 

基于时间聚合

---

前面我们已经学习了如何使用 sum()、avg() 和相关的聚合运算符从标签维度进行聚合，这些运算符在一个时间内对多个序列进行聚合，但是有时候我们可能想在每个序列中按时间进行聚合，例如，使尖锐的曲线更平滑，或深入了解一个序列在一段时间内的最大值。

为了基于时间来计算这些聚合，PromQL 提供了一些与标签聚合运算符类似的函数，但是在这些函数名前面附加了 _over_time()：

avg_over_time(range-vector)：区间向量内每个指标的平均值。min_over_time(range-vector)：区间向量内每个指标的最小值。max_over_time(range-vector)：区间向量内每个指标的最大值。sum_over_time(range-vector)：区间向量内每个指标的求和。count_over_time(range-vector)：区间向量内每个指标的样本数据个数。quantile_over_time(scalar, range-vector)：区间向量内每个指标的样本数据值分位数。stddev_over_time(range-vector)：区间向量内每个指标的总体标准差。stdvar_over_time(range-vector)：区间向量内每个指标的总体标准方差。

例如，我们查询 demo 实例中使用的 goroutine 的原始数量，可以使用查询语句 go_goroutines{job="demo"}，这会产生一些尖锐的峰值图：

我们可以通过对图中的每一个点来计算 10 分钟内的 goroutines 数量进行平均来使图形更加平滑：

他要算十分钟之内的平均值，其实就是将这些值全部加起来求平均。

 可以看到计算的平均值

avg_over_time(go_goroutines{job="demo"}[10m])

这个查询结果生成的图表看起来就平滑很多了：

比如要查询 1 小时内内存的使用率则可以用下面的查询语句：

100 * (1 - ((avg_over_time(node_memory_MemFree_bytes[1h]) + avg_over_time(node_memory_Cached_bytes[1h]) + avg_over_time(node_memory_Buffers_bytes[1h])) / avg_over_time(node_memory_MemTotal_bytes[1h])))

子查询

---

上面所有的 _over_time() 函数都需要一个范围向量作为输入(比如[5m])，通常情况下只能由一个区间向量选择器来产生，比如 my_metric[5m]。但是如果现在我们想使用例如 max_over_time() 函数来找出过去一天中 demo 服务的最大请求率应该怎么办呢？

请求率 rate 并不是一个我们可以直接选择时间的原始值，而是一个计算后得到的值，比如：

rate(demo_api_request_duration_seconds_count{job="demo"}[5m])

如果我们直接将表达式传入 max_over_time() 并附加一天的持续时间查询的话就会产生错误：

# ERROR!
max_over_time(
  rate(
    demo_api_request_duration_seconds_count{job="demo"}[5m]
  )[1d]
)

实际上 Prometheus 是支持子查询的，它允许我们首先以指定的步长在一段时间内执行内部查询，然后根据子查询的结果计算外部查询。子查询的表示方式类似于区间向量的持续时间，但需要冒号后添加了一个额外的步长参数：[:]。

这样我们可以重写上面的查询语句，告诉 Prometheus 在一天的范围内评估内部表达式，步长分辨率为 15s：

max_over_time(
  rate(
    demo_api_request_duration_seconds_count{job="demo"}[5m]
  )[1d:15s] # 在1天内明确地评估内部查询，步长为15秒
)

也可以省略冒号后的步长，在这种情况下，Prometheus 会使用配置的全局 evaluation_interval 参数进行评估内部表达式：

max_over_time(
  rate(
    demo_api_request_duration_seconds_count{job="demo"}[5m]
  )[1d:]
)

这样就可以得到过去一天中 demo 服务最大的 5 分钟请求率，不过冒号仍然是需要的，以明确表示运行子查询。子查询还允许添加一个偏移修饰符 offset 来对内部查询进行时间偏移，类似于瞬时和区间向量选择器。

但是也需要注意长时间计算子查询代价也是非常昂贵的，我们可以使用记录规则（后续会讲解）预先记录中间的表达式，而不是每次运行外部查询时都实时计算它。

练习：

输出过去一小时内 demo 服务的最大 95 分位数延迟值（1 分钟内平均），按 path 划分：

max_over_time(
   histogram_quantile(0.95, sum by(le, path) (
     rate(demo_api_request_duration_seconds_bucket[1m])
    )
  )[1h:]
)