MetricsQL(VictoriaMetrics)和PromQL(Prometheus)的不同之处

1、如果对PromSQL不熟悉可以先看以下链接

https://valyala.medium.com/promql-tutorial-for-beginners-9ab455142085

2、与PromQL相比，以下功能在MetricsQL中的实现方式不同，这也改善了用户体验

2-1、MetricsQL 考虑了方括号中窗口之前的前一个点，用于范围函数，例如速率和增加。这允许返回用户对 increase(metric[$__interval]) 查询期望的准确结果，而不是 Prometheus 为此类查询返回的不完整结果

2-2、MetricsQL不推断范围函数结果，（且考虑方括号中窗口之前的前一个点）使得rate函数更为精确

MetricsQL 有意使 rate 和 increase 的实现略有不同。它考虑了前一个时间间隔的最后一个样本，这允许在计算速率或增加时捕获时间序列中的所有信息：

此外，如果间隔中没有足够的样本用于计算 和 ，MetricsQL 会自动增加方括号中的间隔（也称为后视窗口rate）increase。这解决了放大时出现意外“无数据”错误的问题。

2-3、MetricsQL 在计算rate和increase时不应用外推法。这解决了整数计数器的小数结果问题：

2-4、MetricsQL支持更完善的负偏移

VictoriaMetrics 支持负偏移量，如果启用了特定功能标志， Prometheus 从2.26版开始也支持负偏移量。但是，由于 Prometheus 在额外的 5 分钟内继续使用指标的最后一个值，因此即使使用启用的功能标志，查询结果也不同：

原因：这是因为在获取系列时进行了回溯而不是陈旧，并且它被设置为从查询时间回溯 5m。如果您尝试查询时间为 X 的系列，查询引擎会查找从 X-5m 到 X 的系列并获取最新样本。因此，当您以偏移量 -10m 展望未来时，回溯将找到未来 5m 内的最后一个样本。

相关issue：https://github.com/prometheus/prometheus/discussions/9428

2-5、相比vm，prometheus外推可能带来数据不准确问题：

因为有时候prometheus漏掉了一半的点，然后由于需要外推，就会自动按那个趋势去算，导致以下问题：

下面假设每个点间隔5s，计算间隔10s。1121这种的其实增量1，但是如果外推只取到了中间的数据点1和2，然后根据增量1和只采了一半的数据点来外推乘2倍数，那就是2了，导致错误数据

1-----1-----2------1
   ｜------｜-----｜

此时取了中间两个点的增量2-1=1，然后两个点间隔5s，计算间隔又是10s，那就做外推，得到估计的增量是2，就变成了正常数值的2倍，实际就偏差了很多

2-6、MetricsQL支持查询：{name=~“.*”}

PromQL 拒绝这样的查询以防止数据库过载，因为查询会从中选择所有指标。同时，PromQL 不会阻止用户运行几乎相同的查询{name=~“.+”}，其目的相同。

2-7、metrics有着比prometheus更大的精度损失

由于使用了压缩算法， VictoriaMetrics 可能会降低超过 15 位小数的值的精度。
虽然这种精度损失在极少数情况下可能很重要，但在大多数实际情况下并不重要，因为测量误差通常比精度损失大得多。

2-8、metricsQL可以省略后视窗口，自动计算

为 Prometheus和在 Prometheus 中选择正确的后视窗口非常重要。否则，可能会返回不正确的数据或不返回任何数据。Grafana甚至引入了一个特殊的变量$__rate_interval来解决这个问题，但它可能会导致比它解决的问题更多的问题：

• 1、用户需要在数据源设置中配置抓取间隔值才能使其工作；
• 2、用户仍然需要$__rate_interval手动添加到每个使用的查询rate；
• 3、如果数据源存储具有不同抓取间隔的指标（例如跨多个数据源的全局视图），它将不起作用；

它仅适用于 Grafana。在 MetricsQL 中，可以省略方括号中的后视窗口。VictoriaMetrics 会根据当前步骤自动选择后视窗口，因此rate(node_network_receive_bytes_total)与rate(node_network_receive_bytes_total[$__interval]). 并且即使间隔太小而无法捕获足够的数据点，MetricsQL 也会自动对其进行扩展。

这就是为什么类似deriv(demo_disk_usage_bytes[1s])Prometheus不返回任何数据，但VictoriaMetrics 的查询会在进行计算之前扩展后视窗口。

2-9、MetricsQL返回step小于scrape interval的rate的预期非空响应结果

rate() 函数为您提供所提供的时间序列的变化率，因此rate(mysql_global_status_questions[10s])基本上会为我们提供过去 10 秒内 MySQL 问题的平均数。到目前为止一切都很好。
但是，如果这个时间序列的分辨率低于 10 秒，例如，如果我们只每分钟测量一次mysql_global_status_questions怎么办？在这种情况下，rate() 函数将不返回任何内容，数据将从图中消失。

MetricsQL在间隔太小而无法捕获足够的数据点时也会自动对其进行扩展

我们查看对于上述情况，prometheus与vm的不同处理方式

2-10、MetricsQL 将scalar类型视为与不带标签的instant vector相同，因为这些类型之间的细微差别通常会使用户感到困惑

2-11、MetricsQL从输出中移除所有NaN值，因此一些查询（如 (-1)^0.5）在 VictoriaMetrics 中返回空结果，而在 Prometheus 中返回一系列 NaN 值。请注意，Grafana 不会为 NaN 值绘制任何线条或点，因此 VictoriaMetrics 和 Prometheus 的最终结果看起来相同。

2-12、MetricsQL 在应用函数后保留指标名称，这不会改变原始时间序列的含义。例如，min_over_time(foo) 或 round(foo) 在结果中留下 foo 指标名称

PromSQL：

input：min_over_time(foo)
output：{xxx} value

MetricsQL：

input：min_over_time(foo)
output：foo{xxx} value