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 服务5m钟处理的请求数,那么可以所有单个的速率相加就可以,这样就可以算得5m内所有的请求数量。
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()
<aggregation>_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:] )