Prometheus还提供了下列内置的聚合操作符，这些操作符作用域瞬时向量。可以将瞬时表达式返回的样本数据进行聚合，形成一个新的时间序列。
聚合运算符从标签维度进行聚合，这些运算符在一个时间内对多个序列进行聚合
-
sum (求和) -
min (最小值) -
max (最大值) -
avg (平均值) -
stddev (标准差) -
stdvar (标准方差) -
count (计数) -
count_values (对value进行计数) -
bottomk (后n条时序) -
topk (前n条时序) -
quantile (分位数)
使用聚合操作的语法如下：
<aggr-op>([parameter,] <vector expression>) [without|by (<label list>)]
其中只有count_values, quantile, topk, bottomk支持参数(parameter)。
without用于从计算结果中移除列举的标签，而保留其它标签。by则正好相反，结果向量中只保留列出的标签，其余标签则移除。通过without和by可以按照样本的问题对数据进行聚合。
例如：
sum(http_requests_total) without (instance)
等价于
sum(http_requests_total) by (code,handler,job,method)
如果只需要计算整个应用的HTTP请求总量，可以直接使用表达式：
sum(http_requests_total)
聚合
我们知道 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.计算 指标有多少不同的 CPU 模式：
count (group by(mode) (demo_cpu_usage_seconds_total))
3.计算每个 job 任务和指标名称的时间序列数量：
count by (job, __name__) ({__name__ != ""})
每个指标里面都有_name_
基于时间聚合(Gauge类型)
前面我们已经学习了如何使用 sum()、avg() 和相关的聚合运算符从标签维度进行聚合，这些运算符在一个时间内对多个序列进行聚合，但是有时候我们可能想在每个序列中按时间进行聚合，例如，使尖锐的曲线更平滑，或深入了解一个序列在一段时间内的最大值。
为了基于时间来计算这些聚合，PromQL 提供了一些与标签聚合运算符类似的函数，但是在这些函数名前面附加了 _over_time()
_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)：区间向量内每个指标的总体标准方差。
[info] 注意
即使区间向量内的值分布不均匀，它们在聚合时的权重也是相同的。
例如，我们查询 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 是支持子查询的，它允许我们首先以指定的步长在一段时间内执行内部查询，然后根据子查询的结果计算外部查询。子查询的表示方式类似于区间向量的持续时间，但需要冒号后添加了一个额外的步长参数：[<duration>:<resolution>]。
这样我们可以重写上面的查询语句，告诉 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:]
)
