Grafana 7.2 中的新功能：$__rate_interval 用于 Prometheus 中 rate() 速率查询

引用

链接：https://grafana.com/blog/2020/09/28/new-in-grafana-7.2-__rate_interval-for-prometheus-rate-queries-that-just-work/

我们应该使用什么范围rate()？这不仅是许多有用的Robust Perception 博客文章中真正经典的标题；它也是 PromQL（Prometheus查询语言）最常见的问题之一。我将它作为我在 GrafanaCONline 2020 上演讲的主题，如果你还没有，我邀请你观看。

Grafana 7.2引入了一个名为 的新变量$__rate_interval。在大多数图形rate查询的情况下，简单地用作范围将是正确的选择$__rate_interval。

之前

两个重要的内容：

1. 查询中的范围rate应至少是抓取间隔的四倍。
2. 对于使用 Grafana 绘图，该变量$__interval对于指定查询中的范围非常有用rate。

但是如果我们放大很多会发生什么？让我们从上面的两天缩短到一小时。

结果非常令人失望：“没有数据”！原因是我们违反了上面列出的第一个要点。该$__interval变量扩展到图表中两个数据点之间的持续时间。Grafana 有用地告诉我们面板编辑器中的值，如上面的屏幕截图所示。可以看到，间隔只有15s。rate我们的 Prometheus 服务器配置了 15s 的抓取间隔，所以我们应该在查询中使用至少 1m 的范围。但是在这种情况下我们只使用了 15s，因此在大多数情况下范围选择器只会覆盖一个样本，这不足以计算rate.

让我们通过设置四倍刮擦间隔的最小步长来解决这种情况，即 1m：

到目前为止，此方法遵循推荐的最佳实践。它工作得很好，但它有两个问题：

1. 它要求您在使用查询的每个面板中填写一个最小步骤。rate
2. 它限制了 Grafana 向 Prometheus 请求评估结果的分辨率。rate有人可能会争辩说，以高于每分钟一个数据点的分辨率请求超过 1m 没有多大意义。更高的分辨率本质上会导致移动平均线。但这正是一些用户想要的。

现在

新$__rate_interval变量解决了上述两个问题。让我们再次删除Min step条目并更改$__interval为$__rate_interval：

现在一切看起来都很棒了。上述移动平均效应甚至揭示了一些以前不可见的更高分辨率结构。（专业提示：如果您想要像以前一样更平滑的图形，请不要绝望。只需打开查询选项并将最小间隔设置为 1m。）

那么背后的魔力是$__rate_interval什么？无论如何，它只是保证至少是刮擦间隔的四倍。但它如何知道刮擦间隔是多少？这实际上是一个非常好的问题，因为 Prometheus 本身只知道当前配置的抓取间隔，而不会将用于历史数据的抓取间隔存储在任何地方。（也许将来会改变，但那是另一天的故事。）Grafana 只能依赖其 Prometheus 数据源中配置的抓取间隔。如果您打开 Prometheus 数据源的设置，您会在下半部分找到Scrape interval字段：