如何优化 PromQL 和 MetricsQL 查询

PromQL和MetricsQL是强大的查询语言。它们允许编写简单的查询，用于构建漂亮的时间序列数据图形。它们还允许编写复杂的查询，用于SLI / SLO计算和警报。但优化PromQL查询可能很困难。本文介绍了如何确定缓慢的PromQL查询，如何理解查询成本以及如何优化这些查询，使其执行更快并消耗更少的CPU和RAM。

优化思路总览

PromQL 查询慢，通常不是因为语法看起来复杂，而是因为查询在实际数据上选择了太多时间序列、扫描了太多原始样本，或在 Grafana 范围查询中反复处理同一批样本。

可以按下面的顺序排查：

先用慢查询日志、查询统计或生产环境实际执行结果确认慢查询。
用 count(last_over_time(...)) 估算查询选择了多少时间序列。
用 sum(count_over_time(...)) 估算查询扫描了多少原始样本。
对 Grafana 范围查询，继续判断 lookbehind 窗口是否导致样本被重复处理。
检查 Kubernetes 等场景中的高流失率标签。
对复杂查询，分别优化每个 series selector，并减少二元运算两侧不匹配的时间序列。

问题类型	诊断方式	常见优化方向
选择太多 series	`count(last_over_time(...))`	增加标签过滤、治理高流失率标签
扫描太多样本	`sum(count_over_time(...))`	缩短 lookbehind 窗口、缩短图表时间范围
重复处理样本	对范围查询估算处理样本数	调大 Grafana step、降低分辨率、缩短窗口
标签流失率高	`/api/v1/status/tsdb`	删除或重写频繁变化的标签
复杂二元运算浪费	分别检查左右选择器	给两侧选择器添加公共标签过滤器

如何确定 PromQL 查询是否缓慢？

很遗憾，仅凭外观无法确定PromQL查询是快还是慢 :( PromQL查询性能除了查询本身之外还取决于以下因素：

查询选择的series数量。如果查询选择了数百万个series，则在执行期间可能需要占用几千兆字节的RAM、高数量的磁盘IOPS和大量CPU时间。
查询需要扫描的原始样本数。这个数字等于所选时间范围内所有匹配series的原始样本之和。样本数量还取决于数据库中存储的采样间隔（即Prometheus世界中的scrape_interval）-较短的间隔意味着更多的采样。
Grafana中用于构建图形所使用到的时段。较长时段意味着必须从数据库中读取更多数据。请注意，较长时段可能会增加要扫描和匹配时间series数目，因为老series会随着新series而被替换掉（也称为series流失率）。
所选时间范围内数据库中总共有多少个series。通常情况下，更多series表示查找匹配series速度变慢。请注意，如果 series 有很高的流失率，活跃的 series 数量可能会远小于给定时段内的总 series 数量。

例如，简单的查询 up 只匹配了选定时间范围内几千个样本的少数时间序列，可能会在一眨眼之间就执行完了。但是，如果该查询匹配了选定时间范围内数十亿个样本和成百上千个时间序列，则相同的查询 up 可能需要花费数十秒钟，并且可能会消耗几GB的RAM。

查询性能也取决于查询本身。例如，不同的函数具有不同的性能。MetricsQL 和 PromQL 有以下函数类型：

标签操作函数，例如label_replace、label_join和label_set。尽管在查询中使用时看起来很复杂，但它们是最轻量级的函数。
转换函数，例如abs、round和time。这些通常是快速的函数。有一些例外，如histogram_quantile、prometheus_buckets和其他直方图相关的函数，在执行过程中需要更多时间和资源。
聚合函数，例如sum、count、avg、min和max。这些函数大多数也是轻量级的，除了一些非常规的聚合函数，如count_values、quantile或histogram。
滚动函数，如rate、increase、min_over_time和quantile_over_time。这些是最昂贵的函数。滚动函数使用存储在数据库中的原始样本，而其他函数则使用从滚动函数返回的计算结果。每个滚动函数都接受方括号（在Prometheus中称为范围向量）中的lookbehind窗口（一个时间范围，比如1m表示1分钟）。例如，rate(http_requests_total[1h]) 示例中的lookbehind窗口-1小时-更改了查询需要处理每个匹配时间序列的原始样本数量。较大的窗口意味着需要处理更多原始样本。

PromQL和MetricsQL有一个额外的功能，如果使用不当可能会显著减慢查询速度 - 子查询。了解子查询的工作原理，以了解它们如何影响查询性能和资源使用情况。

正如您所看到的，仅凭查询本身很难确定查询是快还是慢。确定缓慢的查询最好的方法是在生产环境中运行它们，并查看在实际数据上执行时哪些查询较慢。VictoriaMetrics提供以下其他选项，可能有助于确定缓慢的查询：

慢查询日志。如果执行时间超过传递给-searchlogSlowQueryDuration命令行标志的值，则VictoriaMetrics会记录查询。
查询统计数据。它可以在 /api/v1/status/top_queries 页面中找到。它显示了最常执行的查询以及最慢的查询。有关更多详细信息，请参阅这些文档。

好的，检测到慢查询。如何确定为什么这些查询很慢？

为什么 PromQL 查询很慢？

让我们重复一下PromQL和MetricsQL查询变慢的最常见情况：

当它选择大量时间序列时。
当它选择大量原始样本时。
当查询中使用的个别标签过滤器匹配大量时间序列时。

因此，您需要检查每个案例以便检测导致查询缓慢的情况。

换句话说，优化 PromQL 的关键不是“把表达式写短”，而是减少底层需要查找、读取和处理的数据量。

给定的 PromQL 查询选择了多少时间序列？

使用count和last_over_time函数，结合查询中的系列选择器。例如，如果查询看起来像avg(rate(http_requests_total[5m])) by (job)，那么以下查询将返回初始查询需要选择的时间序列数量：

count(last_over_time(http_requests_total[5m]))

这适用于即时查询，这些查询通常用于警报和记录规则(recoding rules)。这些查询仅返回给定时间的值。如果把查询语句放到Grafana中来构建给定时间范围内的图形，则会使用范围查询。他们为图表上的每个点计算独立的结果。在高流失率下，实际查询和处理的series数量远高于count(last_over_time(...))查到的值。在这种情况下，您应该将所选的时间范围放在方括号中，以获取查询需要选择的时间序列的实际数量。例如，为了选择原始查询在过去24小时内构建图表所涉及的系列数量，必须使用以下查询：

count(last_over_time(http_requests_total[24h]))

如果count(last_over_time(…))查询返回的值小于几千个，则原始查询在选择时间序列数量方面没有瓶颈。如果返回的数字超过数万个，则可能会有问题。尝试以下方法来减少所选时间序列的数量：

在系列选择器中添加更多的标签过滤器，以便选择更少的时间序列。
检测和修复高流失率的来源。这些通常是随时间定期更改值的标签。此类标签可以通过 /api/v1/status/tsdb 页面检测到。
将方括号中的回溯窗口减小或在Grafana中缩小图形的时间范围。这可能有助于在高流失率下减少所选时间序列的数量。

这里的判断阈值来自原文经验，实际环境还要结合后端存储能力、保留周期、采样间隔和查询并发来看。

给定的 PromQL 查询选择了多少个样本？

使用sum和count_over_time函数结合查询中的系列选择器。例如，如果查询看起来像avg(rate(http_requests_total[5m])) by (job)，那么以下查询将返回初始查询需要选择的样本数：

sum(count_over_time(http_requests_total[5m]))

这适用于警报和记录规则。如果您需要确定在给定时间范围内选择多少原始样本来构建Grafana中的图形，则必须将方括号中的lookbehind窗口更改为给定的时间范围。例如，以下查询返回了构建最近24小时图形所需的原始样本数量：

sum(count_over_time(http_requests_total[24h]))

如果 sum(count_over_time(...)) 查询返回的值小于几百万，则初始查询在扫描原始样本数方面没有瓶颈。如果返回的数字超过了数亿，则您可能需要通过以下技术来优化查询：

通过前面解释的办法来减少所选时间序列的数量
减少方括号中的回溯窗口大小，从而在查询期间需要处理的原始样本数量更少
在Grafana中缩短图表的时间范围
在Grafana中调大分辨率选项，以便请求更少的数据点来构建图表。请参阅这些文档。

如果你在告警规则里使用这类查询，还要注意评估间隔和规则数量。单条查询看起来还能接受，多条高成本规则并发执行时，后端压力会被放大。

这个 PromQL 查询处理了多少个样本？

通常情况下，处理的原始样本数量与选择的原始样本数量相匹配。但有时候，处理的原始样本数量可能显著超过选择的原始样本数量。如果满足以下条件，PromQL 和 MetricsQL 会多次处理同一份原始样本：

该查询用于在Grafana中构建图表。
方括号中的回溯窗口超出了图表上点之间的时间间隔（Grafana通过step查询参数传递此间隔到/api/v1/query_range）。

例如，如果使用以下查询来构建过去一小时的图表：max_over_time(process_resident_memory_bytes[30m])，Grafana会把step参数传给/api/v1/query_range，step比30分钟显然会小很多。这意味着每个原始样本都会被多次用于计算，以计算图表上每个点的max_over_time。以下的MetricsQL查询可用于确定查询需要处理的样本数量：

range_last(
  running_sum(
    sum(
      count_over_time(process_resident_memory_bytes[30m])
    )
  )
)

如果返回的数字超过亿级别，那么就需要通过减少方括号中的lookbehind窗口来优化查询。另一个优化选项是通过调高分辨率选项来指示Grafana调大step参数。有关详细信息，请参阅这些文档。

高流失率和PromQL查询性能

时间序列的高流失率可能会导致查询性能下降。高流失率会增加数据库中时间序列的总数。这也增加了查询中每个标签过滤器匹配时间序列的数量。这反过来会减慢查找匹配时间序列的过程。

这是Kubernetes监控中常见的问题，特别是在频繁部署时。每次新部署都会增加时间序列的变化率，因为被部署对象（pod、endpoint、service）暴露出来的指标可能具有与部署相关的标签（如deployment id、pod id、image id等）的新值。解决这个问题的方法是使用Prometheus relabeling规则删除或重写这些标签，以便它们不会随着每次部署而经常更改。最经常更改值的标签可以通过/api/v1/status/tsdb页面检测到。详细信息请参阅此文档。

这类问题的根因通常不在查询语句本身，而在指标标签设计。只在查询层面加过滤条件，可以缓解部分成本；如果标签持续制造新 series，最终还是要回到采集和 relabeling 规则上治理。

优化复杂的PromQL查询

PromQL允许编写具有多个系列选择器的查询。例如，foo + bar包含两个系列选择器 - foo和bar。这些系列选择器独立地进行评估。这意味着优化过程应该针对查询中每个系列选择器分别执行。

当二元运算符左右两侧的时间序列选择器返回不同数量和标签集合的时间序列时，复杂查询存在常见性能问题。PromQL 和 MetricsQL 剥离指标名称，然后将二元运算分别应用于左侧和右侧系列上具有相同标签集的系列，而其他系列则被丢弃。查阅此文档了解更多细节。这意味着在二元运算符的另一侧没有相应匹配对的系列只会浪费计算资源（CPU 时间、RAM、磁盘 IO）。解决方法是在二元运算符两边的指标选择器中添加公共标签过滤器。这将减少所选时间序列的数量，从而减少资源使用。例如，查询 foo{instance="x"} + bar 可以被优化为 foo{instance="x"} + bar{instance="x"}，这样 bar 就只会将搜索范围缩小到带有 {instance="x"} 标签的时间序列。

PromQL 慢查询优化清单

检查项	问题	优化方向
series 数量	查询是否选中了过多时间序列	增加标签过滤，缩短范围，治理流失率
样本数量	是否扫描了过多原始样本	缩短 lookbehind 窗口或图表时间范围
Grafana step	每个点是否重复处理大量样本	调大分辨率或 step，减少返回点数
函数类型	是否大量使用滚动函数、直方图函数或子查询	评估窗口大小，必要时拆分或预聚合
标签设计	是否存在 deployment id、pod id、image id 等频繁变化标签	用 relabeling 删除或重写
二元运算	左右两侧是否匹配集合差异过大	给两侧选择器加公共标签过滤

结语

MetricsQL 和 PromQL 查询优化并不是一项容易的任务。它取决于查询本身和被查询的数据。Prometheus 和 VictoriaMetrics 提供了一些工具来确定缓慢的查询，并检测哪个部分的查询速度较慢。本文介绍了确定查询缓慢部分的常见技术，并提供可能的优化解决方案。我希望这篇文章能够帮助在生产环境中优化 PromQL 查询。