Grafana: 使用模板变量对查询的警报支持

+1

1. 与仅使用全部相比有什么区别？

+1
能够在生命周期较短的服务器上添加警报（AWS 自动扩展）会很好，使用模板在 grafana 上自动注册服务器很容易，但很遗憾无法对它们进行警报

@bergquist例如，当您有十几个主机时，使用 all 是不切实际的。

例如，如果其中只有少数失败（假设是 5 个），则为每个失败警报接收一封电子邮件非常有用。 这种方式也更容易与通常期望每个指标一个警报的其他工具集成。

当前的方法（使用全部）非常简洁，尽管当实例较少或您在服务级别发出警报时（例如队列中的作业数）。

@calind所说的，我有多个 $host 变量，它们在 influxDB 中运行良好，但在警报中没有

+1 也是如此。

只是一个想法，因为您可以使用模板变量进行查询，您是否只能对警报指标进行相同的查询，并可能遍历结果以查看哪些符合警报条件？

@NotSoCleverLogin有可能。 但是您想根据选择的模板值来更改警报规则的行为吗？

对模板使用 all 选项是唯一对我有意义的方法。

+1

我有一个 X 环境设置，每个环境中都有相同的组件。 我们目前正在使用 prometheus 来提醒例如 cpu 使用/磁盘使用等。在那里我们为查询指定一个警报，当触发警报时，它只会说明警报是从哪个环境触发的。

如果我们对 All 变量执行此操作，那将在某种程度上起作用。 但是，使用@calind的示例，屏幕截图将充满来自我所有环境的所有 cpu 的趋势，而不仅仅是我想要了解上述问题的环境。 该图将（或可以）被来自其他环境的信息所掩盖。 在某些情况下，比较其他环境中的 cpu 可能会很有趣，但不能保证测试环境中发生的事情正在我们的生产环境中发生，等等。

我们还在研究创建可供操作使用的仪表板，在“标准”概览仪表板中显示警报注释。 鉴于我们对这类仪表板使用“env”模板变量，我们现在不可能通过它的实现方式来做到这一点。 我将不得不手动（至少在某种程度上）生成一个“影子”仪表板，在该仪表板中触发警报（这使我失去了概览仪表板中的注释）。

我认为模板变量可以帮助您做的另一件事是将警报（如果您选择实现这样的功能）路由到不同的来源（如果在生产中，一些到操作，如果在测试环境中，到 qa/开发人员等）。

+1 用于支持模板化查询的警报。

@bergquist ，一些仪表板没有 _All_ 选项。 例如 collectd 的系统指标 (https://grafana.net/dashboards/24)。 对于 10 台或更多服务器来说，拥有一个 _All_ 选项肯定是不切实际的。 这就是为什么需要遍历模板变量的原因。

允许使用 All 是一个良好且受欢迎的开始。

在 Prometheus 中，查询需要以不同的方式编写以允许 All：

some.metric{hostname=~"$Hostname"}

注意那里的额外波浪号，允许正则表达式搜索（以及 All 中的通配符）。

我没有对从直接查询到正则表达式搜索查询的可能性能影响进行基准测试，但至少目前它显然可以解决我们的问题。

+1

+1

不知道应该如何实现，只知道它是需要的..

+1
我们使用 Prometheus 作为数据源来监控我们的 Kubernetes 基础设施，以了解我们的 On-Prem K8S 集群和我们的 AWS K8S 集群。
我们所有的仪表板都对数据源 ($Environment)、$Instance/Node、$Namespace 和 $Pod 使用模板化变量。
由于 Prometheus 查询结构的方式； 所有查询都有模板变量； 这会阻止警报规则允许保存。
我希望看到将模板化变量查询添加到警报中。

+1

+1
我们将模板仪表板用于多服务器环境，这是合乎逻辑的方式（很多人都在使用），所以我们现在不能在 grafana 中使用警报。 唯一的方法是拥有一个单独的非模板仪表板或使用 prometheus 本身设置警报，这并不容易。

也许如果有一个选项或简单的方法来保存/导出仪表板，其中模板变量支持/预呈现到所有字段中......这可能是一个很好的中途点，直到找到另一个解决方案。

+1 用于支持模板化查询的警报。 我们目前在所有仪表板上都使用模板，因此无法利用这个非常酷的功能。

+1，我们有很多模板化的仪表板，我们现在不能使用警报，我们必须对具有警报的仪表板进行重复数据删除，因此我们失去了模板功能

+1，我们几乎所有的仪表板都使用模板变量（和嵌套的模板变量）。

我们希望能够在重复面板上设置警报，以便在需要时为每个模板变量组获取单独的警报。 另外，这意味着警报是动态的，而不是像现在这样的超级手动。

危险：理论上有变量会很好，但我们需要记住，如果有人进入您的仪表板并更改值并保存，则生成的警报将受到影响。 不知道这是否可以的行为，会很复杂。

+1

使用 grafana 时，感觉到处都鼓励使用模板，并且创建一组额外的图表而不使用变量只是为了使用警报功能感觉是错误的......

+1 用于支持模板化查询的警报。
另外，我们发现当我们使用中文规则名或中文标题时，我们收到了触发规则的异常邮件。 例如，我们预期“个股分时线接口请求时间(getTimeTrend) 警报”，但收到“个è,¡åˆ†æ—¶çº¿æŽ¥å £è¯·æ±‚时间( getTimeTrend) alert"，可能字符集不正确。

+1 在警报中实现模板化变量

+1

+1 会得到很好的补充

+1

+1 在警报中实现模板化变量

+1

+1 期待

+1

+1

+1

+1

请停止写+1 ！
订阅此问题的每个人都会收到一封电子邮件...

有一个 github 功能只是为了摆脱那些+1评论：
https://github.com/blog/2119-add-reactions-to-pull-requests-issues-and-comments

@thetechnick电子邮件中有一个链接，您可以在其中静音线程并且不接收任何电子邮件。 但我知道您可能只想在功能完成时收到通知，但我也想解决这个问题，以便希望它尽快得到解决:)

整体警报方面取得了很大进展。
对于警报中的模板变量，我也错过了它。 +1：D

=
最重要的是，Grafana 检测query中使用的指标是否使用模板变量的方式可能存在错误。

当您有一个间接使用模板变量的系列时，Grafana 不会阻止您将该系列添加为警报。 警报显然无法正常工作。

请参阅#K （它使用 #D，它使用 #A 和 #A 使用 templ.var）：

我仍然可以选择它：

无处不在的模板，这意味着无处发出警报。
不知道警报是如何实现的，但是对于一个简单的图表，在调用数据源之前，查询会被“翻译”，模板变量被替换为值，对吧？ 那么为什么不在这种情况下呢？ 无论如何，如前所述，几乎所有查询都使用模板变量，警报完全适合我。 拜托，您能否实施它，以便我们不必将警报移到 Grafana 之外？ 非常感谢！

我认为我们应该认识到使用模板进行警报并非易事，我认为所有选项都是可行的方法，因为我们不希望在有人使用仪表板时更改警报。
但是，如果模板查询返回新结果，grafana 仍然必须创建新警报……当我们扩展应用程序时，这种情况经常发生。
如果您使用 InfluxDB，这会导致更多问题，因为我猜我们中的许多人都在使用标签/标签值，并且它们没有时间过滤器......所以 grafana 将为任何主机上曾经存在的所有服务创建警报...... .

+1

只允许在警报中指定数据源对我来说就可以了。 它不会破坏任何逻辑，我至少可以指定要注意的生产和登台环境。

ALL 是一个选项，当然。 更灵活的是识别查询中的模板变量并让用户在警报条件配置中设置值。 我猜最好但很复杂的是有多个警报（与有多个查询相同的方式），以便可以为查询中的不同模板变量值设置不同的警报。 例如，这将使管理员能够为不同的主机设置不同的警报条件。

多个警报配置文件会很棒，但对于初始阶段，只需提供与警报面板中仪表板上可用的模板选择器相同的模板选择器就可以解决很多问题。

我还认为每个变量都应该有一个切换，以将该变量的结果聚合到一个通知中，这可能仅适用于启用了多选的模板变量。 这提供了一种简单但有效的方法来控制通知的详细程度——您可能只想为多个相关指标通知一次，但在任何指标失败的情况下通知每个主机。 或者，无论有多少主机受到影响，您可能只想通知一次失败的指标。

我们对这个错误有任何目标里程碑吗？

我对复杂查询和模板变量查询的警报有一些问题。 我发现了简单的解决方法，这可能并不漂亮，但它适用于我的用例。
它只是在构建查询后提取查询，因此没有模板变量和任何#ROW 引用。 这对你来说可能很明显，没有火箭科学，但对我来说，它改变了生活。

我要做的是准备一个查询：

然后使用 Chrome 开发工具提取它（复制目标参数值）：

把它放在另一行（先切换到切换编辑模式）：

设置警报：

瞧！

@siteshbehera这不是错误。 它是一个功能请求。

但不是。 我们目前没有这方面的里程碑。

人工智能 grafana 插件应包含在此功能的提交中。

也在等待警报中的模板 +1

我也非常赞成 calind 在开篇文章中提供的可能实现。 它似乎完全适合有多少（包括我在内）使用模板化仪表板 - 您有一个仪表板，但切换/限制一些变量以手动查看特定事物。 我认为“服务器”变量的示例可能是最合适的示例。 在那里，模板变量（没有 _all_-value）将变成与仪表板中的“_tab_”不同的东西——我可以在它们之间切换以查看不同的数据集。 然后很容易假设，在设置警报时，警报将分别针对每个可能的“_tab_”存在。

等待支持警报 +1 中的模板

作为以前的 Librato 用户，警报部分能够实现这种模板，我想加入一个同样部分的解决方案。 在 Librato 中，每个指标都带有一个“源”变量，并且图表上的警报将自动针对每个源。

我认为一个平等的解决方案将满足这里提出的需求。 创建警报时，您应该能够选择单个模板值作为“源”，并且警报中提到了此源，所有其他都设置为“全部”。 如果允许使用多个模板变量，该解决方案至少可以避免您遇到的组合问题。

我自己只是在我感兴趣的数据上设置了一个不可见的最大值或最小值图，并对其发出警报，虽然没有那么强大，但在解决这个问题之前仍然是一个可行的解决方案。

嗨，我肯定在寻找这个功能，因为在之前的大多数情况下，我所有的仪表板都使用模板化查询来支持多个环境（至少）。

有没有跟踪grafana的路线图的地方？ 或者我们可以通过任何方式查看功能（比如这个）是否会在未来（接近或不那么接近）实现，而不需要在 github 上戳 mantainers？ :)

太棒了，真的很期待这个

+1

+1

我们仍然不确定如何做到这一点。

我认为重复使用选定的模板变量进行警报会很危险，因为人们可以选择仅查看一个选项，然后忘记更改回All或更广泛的内容。 我不会对这种行为感到安全。 警报规则应该非常容易理解和推理。 显式规则 > 魔术规则。

此问题的一种解决方案是为每个模板变量设置两个值。 一种用于仪表板中的可视化，另一种用于警报。 这样就可以在警报中始终拥有更广泛的选项，并且仍然只在图表中选择几个选项。 连接这些值应该是可能的，但不是默认行为。

该解决方案将如何成为相当大且复杂的功能。

我有两个解决方案的建议。

1. 一个短期建议是添加一个警报选项，以便在呈现的图形（通过电子邮件发送的图形）中仅显示正在警报的指标。 当警报图包含数十个指标时，这将解决混乱问题。

2. 一个长期的解决方案是遍历模板变量，以便您对每个模板值组合都有不同的警报。

正如我在 11 月提到的那样。 对于 prometheus 用户，如果查询编写正确（ some.metric{hostname=~"$Hostname"} ），只需使用 'All' 作为变量值就足够了。

应该也很容易实现。

@bergquist我认为选项 2 正朝着正确的方向前进（我在 https://github.com/grafana/grafana/issues/6557#issuecomment-272588490 中建议的部分实现），它似乎不太复杂，由于仪表板已经存在处理模板 var 选择的代码，因此无需复制 var 配置，只需选择即可。 我不认为我会费心将仪表板选择连接到此功能的第一遍警报。

我通过为警报创建一个新的指标查询来解决它，没有模板变量并在 Grafana 版本 v4.1.1 上禁用它（以将其从图表中排除）。

+1 在警报中实现模板化变量

+1 在警报中实现模板化变量

这会影响 Grafana 的所有版本吗？ 或者这是以前可用的功能？ 这对我来说是一种破坏交易，不介意安装以前的版本。

@alejandroandreu警报是在版本 4 中添加的，它从未与模板一起使用。

+1 在警报中实现模板化变量

我希望能够选择/输入警报应该评估的组合，因为我运行的一些环境不是生产环境，有两种方法可以实现，第一种更明确，第二种是更容易配置。

手动输入所有想要的组合

• 此配置应显示在警报配置面板中

例如，如果我有 3 个模板变量： cloud 、 region和type ，我将填写一个如下所示的表格：

| 云 | 地区 | 类型 |
|-------|------------|------|
| aws | 我们-东-1 | 产品 |
| aws | 我们-西-1 | 产品 |
| 天蓝色 | 美国中部 | 产品 |

该表应该有额外的行来插入新行和每一行的删除按钮。

输入可能的值，Grafana 将计算笛卡尔积

• 注意：这个配置可以在模板变量配置面板中输入

| 云 | 地区 | 类型 |
|-------|------------|------|
| aws | 我们-东-1 | 产品 |
| 天蓝色 | 我们-西-1 | |
| | 美国中部 | |

将为该输入创建的组合是：

• aws us-east-1 prod
• aws us-west-1 prod
• aws Central US prod
• azure us-east-1 prod
• azure us-west-1 prod
• azure Central US prod

但是Grafana 可以通过“输入”第一个变量 ( cloud ) 来处理这种情况，然后从第二个变量 ( region ) 中过滤可用值，直到找到所有可能的组合（注意 -它应该对所有变量迭代地完成）。 当人们在这样的标签中使用查询时，这是可能的：

SHOW TAG VALUES WITH KEY = "REGION" WHERE "CLOUD" =~ /$CLOUD/   

在这种情况下，生成的组合会很好（与第一个选项中的表格相同）：

• aws us-east-1 prod
• aws us-west-1 prod
• azure Central US prod

我希望我的建议会有所帮助。

我们在稍微不同的上下文中遇到了这个问题（OpenTSDB 数据源） - 如果您使用模板 var 在指标中选择下采样间隔，警报查询将失败并出现错误 400。我理解实施通用解决方案的困难，但我们是将不得不重新设计各种现有仪表板以启用警报。

@dbcook听起来像是一个明显的问题，您可能应该为它单独提交一个问题。

模板确实是一个很棒的功能，警报也是如此。 我们最好让他们顺利合作，而不是任何尴尬的解决方法。

@tomekit感谢您的解决方法，在我们等待真正的实施时，它看起来确实很有希望。 但是，我找不到使用 Chrome 开发工具提取查询的位置，因此无法复制新查询的目标参数值。 我已经尝试过“检查元素”，但我很难找到您在屏幕截图中显示的“名称”或“标题”或“表单数据”。

您能否说明执行此操作的步骤？ 您的帮助将不胜感激！

谢谢

@mathurj这是网络-> XHR 选项卡。 现在有用吗？

然后点击“渲染”请求。

谢谢@tomekit我现在可以看到这个页面，但是我看不到任何名为“render”的请求。 然而，还有另一个关于我正在执行的查询的请求，但它没有任何“目标”参数。

关于如何处理“渲染”请求的任何线索？

@mathurj我收到“渲染”请求，一旦查看仪表板上的一张图表并单击刷新（右上角）。

试过了，我仍然没有“渲染”请求:(也没有“目标”参数。无论如何感谢您的帮助@tomekit 。我想我将不得不等待实际的实施，这可能需要一段时间@bergquist @torkelo吗？

好的
some.metric{hostname=\~"$Hostname"}
在查询本身很好，
但它的我的数据源是这里的模板......

环境=\~"$环境"
似乎没有用......有什么方法可以让它工作我错过了什么吗？ 还是我应该摆脱模板：失望：

+2

这个特性在使用prometheus作为数据源的时候特别有用！

出于与上述类似的原因，我也需要这个。 我希望这可以作为模板定义的整个集合的 for each 循环。

我们需要这个！！！ :) 👍

我个人也支持这个功能。 我们正在使用一组生成延迟指标的负载测试来测试多个系统。 我们没有使用一个仪表板，而是使用一个变量在保存各种系统数据的数据源之间切换，以便只需要维护一个板而不是编写脚本。
因此，对警报中模板的支持将受到高度赞赏。

+1
我们也需要这个

+1
我们也需要这个

+1
我们也需要这个

我能问一下为什么有这么多人“不喜欢”那些 +1 回复吗？

@skygragon当存在 +1 原始帖子的选项时，它基本上是无用的垃圾邮件。 只需单击第一篇文章中的竖起大拇指图标即可。

模板变量和警报是 Grafana 的两个最佳功能。
很遗憾看到它们是相互排斥的......

+1

@bergquist你的团队能否再次讨论这个问题，并希望在这方面树立一个里程碑？ 这是近 2 年来最受欢迎的功能，我敢打赌，很多用户会很高兴获得此功能。

尚未提出好的解决方案，我们仍然很确定这是一个坏主意，因为它混合了两个用于不同目的的功能。 模板变量用于动态仪表板和探索。 警报规则已经可以通过正则表达式/通配符查询动态化。 将这两者混合起来似乎是一个糟糕的主意，至少以可以理解和可预测的方式。

尽管以某种有限的方式支持它有一些很好的理由，但不确定它是否值得增加极端复杂性和开发成本。 但我们对想法、建议和 PR 持开放态度。

问题是我有很多我监控的服务器，它们是通过亚马逊动态创建的，所以在给定的时间我不知道有多少服务器在运行。

我有一个模板图，显示每个服务器的 CPU（例如），所以我也想在那里发出警报。

但是你是说我可以通过使用通配符来达到同样的效果？

@yesman85当然，这取决于您的时间序列存储。 但大多数支持某种形式的 glob/regex 查询语法来定位遵循命名模式的多个指标。

@torkelo我相信这是第一次公开表明这一立场。 我认为这里可能存在一些误解 - 我不相信用户希望为仪表板输出选择的模板值影响警报，而是在配置警报时提供相同的模板选择。

此线程的相关实施建议：
https://github.com/grafana/grafana/issues/6557#issuecomment -272588490
https://github.com/grafana/grafana/issues/6557#issuecomment -281049641（选项2）

另外，相关问题：
https://github.com/grafana/grafana/issues/6041
https://github.com/grafana/grafana/issues/6553
https://github.com/grafana/grafana/issues/6983
https://github.com/grafana/grafana/issues/7252

这些限制使我们无法使用 Grafana 进行愤怒警报，因为目前这样做的唯一方法是添加一堆单独的隐藏查询用于警报，或者创建单独的仪表板用于警报和显示. 这两个选项都是维护的噩梦，并且限制了 Grafana 的巨大潜力，以便用户轻松监控配置和解释。

我认为我的上述建议受到 Libratos 基于源的警报的启发，提供了一个有限的、可理解的和可预测的解决方案，似乎涵盖了几乎所有上述问题。

在 grafana 中，它将转化为能够使用一个且仅一个模板变量进行警报，并且该变量中的每个值都会生成自己的警报。 您还可以在其上添加一个正则表达式，以过滤/过滤出您要在其上创建警报的那些。

@pdf我同意https://github.com/grafana/grafana/issues/6041是一个很大的限制，我们肯定想解决这个问题，但与这个问题无关。 很遗憾，我们还没有修复它，我同意，过去几个月我们在警报方面有点人手不足，但很快就会改变！

@danhallin不一样，它似乎会转化为 Grafana 中的查询，该查询针对许多系列，在查询中使用通配符或 glob 表达式，或者仅过滤一组有限的标签？ Librato 警报规则是与仪表板分开定义的，不是这样，它如何转化为仪表板范围的数据过滤功能？

目前这样做的方法是为警报添加一堆单独的隐藏查询，这是维护的噩梦

了解在模板化图表中混合警报规则是一场噩梦。 但是认为在警报中支持模板变量可能是一个更大的噩梦。 可能是一个愚蠢的问题，但您不能构建专注于警报的仪表板和图表吗？ 并为仪表板留下许多模板变量以进行探索和故障排除？ 我知道在很多情况下它们可能是相似的，所以感觉像是重复工作:(在带有几个模板变量的仪表板的上下文中，警报规则的问题是它应该如何工作和易于理解，以及它如何甚至可以完全实施。

假设一个查询使用 2 个模板变量 $A 和 $B，它们每个都有 50 个值。 这会导致评估警报规则 2500 次吗？ 我的意思是，如果变量是“单一值”，即构建查询仅在 $A 和 $B 具有单一值时才起作用，那么我们将不得不这样做。 可能不是一个显示停止器，我们将不得不解释只支持多值变量。 可能还有更多限制和有问题的细节，这将使该功能很难实现、使用和理解

但我不是 100% 反对它，认为可能有办法以有限的方式做到这一点（比如只支持一个
多值变量）。 还有一个用例是拥有多个数据源并能够在警报规则中定位数据源变量，以便在必须解决用例的许多数据中心/环境（具有单独的 TSDB）中重用这些警报规则使用数据源模板变量作为带有通配符的度量查询无法解决它。

但是您不能构建专注于警报的仪表板和图表吗？ 并为仪表板留下许多模板变量以进行探索和故障排除？ 我知道可能在很多情况下它们会相似，所以感觉像是重复工作:(

实际上，我确实编辑了我的评论以引用此选项（并添加了一些其他与警报相关的痛点问题）。 正如您已经确定的那样，这意味着将仪表板/面板的创建（以及维护，如果所有这些查询都需要更新）乘以您要发出警报的模板变体的数量，并且还将警报注释与它们可能所在的位置分开最有用的 - 带有警报注释的模板化仪表板对于建立关联非常有用，但如果您必须尝试跨多个浏览器选项卡进行探索并尝试排列内容，则不是那么有用。

假设一个查询使用 2 个模板变量 $A 和 $B，它们每个都有 50 个值。 这会导致评估警报规则 2500 次吗？ 我的意思是，如果变量是“单一值”，即构建查询仅在 $A 和 $B 具有单一值时才起作用，那么我们将不得不这样做。 可能不是一个显示停止器，我们将不得不解释只支持多值变量。 可能还有更多限制和有问题的细节，这将使该功能很难实现、使用和理解

我认为这里有两个不同的问题。 一个_is_（我相信）与#6041 密切相关，因为可能希望每个系列/模板值单独评估警报条件（我在之前的评论中提到的聚合切换）。 如果我们暂时把它放在一边，我相信解决大部分问题的理想方法是允许每个面板有多个警报配置，并且只需以与仪表板输出完全相同的方式进行变量插值：允许用户选择单或配置警报查询时的多值模板值； 查询将在每个警报配置中执行一次，并填充选定的值； 并且结果将被解释为与当前完全相同的方式。 除非我严重误解了某些东西，否则我不认为这会显着增加复杂性，并且应该非常用户友好。

选择模板值以简单地限制警报范围的能力在没有多个警报配置的情况下仍然很有用（如果它有助于按该顺序开发此功能），但对于多个配置将具有指数级更高的价值。

还有一个用例是拥有多个数据源并能够在警报规则中定位数据源变量，以便在必须解决用例的许多数据中心/环境（具有单独的 TSDB）中重用这些警报规则使用数据源模板变量作为带有通配符的度量查询无法解决它。

每个面板的多个警报配置/查询将提供一种处理多个 TSDB 的方法，一个选项可能是允许对警报查询进行分组，以便根据组中所有查询的结果发生状态转换（类似于当前的工作方式系列）。 看起来不是太复杂。

这绝对是一个流行的需求。现在要实现警报，我们必须移动
远离 Grafana 并使用 Graphite 的 Render 创建我们的自定义解决方案
API原始数据..我不认为支持动态/模板化警报
数据至少是使用 Graphite 的任何复杂数据。

另一个想法是，。 为什么 Grafana 有警报部分是仪表板的一部分
如果这被认为是复杂的，请配置。 你可以把它移开分开
警报视图，用户可以在其中输入/配置他们的动态查询，
区间，那边的评价条件。。也许这可能意味着我们
没有重复的仪表板.. 有意义吗？

BR,
维什瓦..

2017 年 8 月 23 日上午 8:01，“Peter Fern” [email protected]写道：

但是您不能构建专注于警报的仪表板和图表吗？
并为仪表板留下许多模板变量以供探索和
故障排除？ 我知道可能有很多情况下他们会
类似所以感觉像是重复的工作:(

我确实编辑了我的评论以引用这个选项（并添加了几个
其他与警报相关的痛点问题）。 正如你已经确定的那样，
这意味着增加仪表板/面板的创建（和维护，如果全部
这些查询需要更新）按您想要的模板变体数量
发出警报，并将警报注释与位置隔离
它们可能最有用 - 带有警报注释的模板化仪表板
对于建立相关性可能非常有用，但如果您必须这样做，则不是那么有用
尝试跨多个浏览器选项卡进行探索并尝试排列。

假设一个查询使用 2 个模板变量 $A 和 $B，它们各有 50 个
价值观。 这会导致评估警报规则 2500 次吗？ 我是说
如果变量是“单值”，即查询被构建为只能工作
如果 $A 和 $B 有一个值，那么我们将不得不这样做。 不是表演
塞子也许，我们只需要解释多值变量是
支持的。 可能还有更多限制和有问题的细节
这将使此功能很难实现、使用和理解

我认为这里有两个不同的问题。 一个是（我相信）密切
与 #6041 https://github.com/grafana/grafana/issues/6041相关，在
可能需要单独评估警报条件
系列/模板值（我在前面提到的聚合切换
评论）。 如果我们暂时把它放在一边，我相信理想的解决方法
这个问题的大部分是允许每个面板有多个警报配置，并且
只需以与仪表板完全相同的方式进行变量插值
输出 - 允许用户选择单值或多值模板值
配置警报查询； 查询将在每个警报中执行一次
配置，填充选定的值； 结果将是
与他们目前的解释方式完全相同。 除非我很严重
误解了一些东西，我认为这不会显着增加
复杂性，并且应该非常用户友好。

选择模板值以简单地限制警报范围的能力将
在没有多个警报配置的情况下仍然有用（如果它有助于开发
此功能按此顺序排列），但价值将成倍增加
有多个配置。

—
您收到此消息是因为您订阅了此线程。
直接回复此邮件，在 GitHub 上查看
https://github.com/grafana/grafana/issues/6557#issuecomment-324363795 ，
或使线程静音
https://github.com/notifications/unsubscribe-auth/AAz1sbIwOT7Xb1MwoDYgZCPz182h2ENxks5sbD62gaJpZM4Kwf5K
.

@danhallin不一样，它似乎会转化为 Grafana 中的查询，该查询针对许多系列，在查询中使用通配符或 glob 表达式，或者仅过滤一组有限的标签？ Librato 警报规则是与仪表板分开定义的，不是这样，它如何转化为仪表板范围的数据过滤功能？

我现在看到我正在讨论的基本上是以下内容的副本： https ://github.com/grafana/grafana/issues/6041

我支持这个功能请求。

我们定期启动服务器，并且我们有模板化的仪表板来测量所有主机（mem、hd、cpu 等）的常见事物。 为每个可能的组合制作一个包含图表的“警报”仪表板太乏味了，许多所需的警报可以在所有主机上泛化。 AFAIKT 这个问题正在寻求一种方法来使这个用例成为可能，并且不会在 #6041 中得到解决。 除非我错过了什么。

为每个组合制作图表和警报并不是我们建议的，只是您警报查询使用通配符或正则表达式，以便它涵盖所有主机等。然后您有一个警报和图表可以针对警报进行调整而不是与之竞争故障排除和动态过滤的要求。

对于我们的用例，我们有许多（可能）临时实例提供事件的实时处理 - 如果某些应用程序生成的指标下降到 0，我们需要收到警报。但是，如果实例被删除或停止，它们仍然会有一个命名的指标与它们相关联的内容会显示在直接通配符搜索中，从而导致错误生成的警报。

通过使用从“简单 JSON 数据源”生成的模板化多值变量（设置为全部）解决了这个问题，该变量包含应该运行哪些实例的真实来源——所有这些都运行良好。 唉，当我尝试启用警报时，我被引导到这个功能请求:)

不确定我们的特定用例有多独特，但我不确定在不使用模板的情况下是否有任何其他方式来提醒这一点——目前，我们需要在 Grafana 之外继续提醒这些问题（这很遗憾- 我们是 Grafana 的重度用户！）

+1

因此，我们没有任何这些问题的一种情况是模板变量是常量类型。 例如，我们有多个仪表板依赖于一个常量变量来将该仪表板上的数据限制为特定资源（我们没有使用多值变量的原因是因为每个仪表板的差异足以证明不同的设置是合理的，但又足够接近证明“模板”仪表板的合理性）。 至少在这种情况下（常量变量），当前警报行为无需更改。

有关于这个话题的消息吗？

你好，

有没有希望获得这个功能？ 我只是想知道其他系统如何具有此功能，因为它们也必须使用某种模板，因为当我们安装代理时，它会自动出现在门户上，并且也可以为此设置警报。 （这是我对 New Relic 的体验）。

@vishwanathh我喜欢有单独的警报部分的方法（如果在图形面板中使用它很复杂），我们可以在其中输入查询仅用于警报。 这样我们的用户就不会看到占位符面板（用于警报）。

很抱歉产生了额外的噪音，但这将是 Grafana 中的一个非常棒的功能。

+1，非常非常重要的功能！

另外，如果让我修改prometheus metric 查询表达式来移除模板变量，这根本不可行。 所以，我认为这个特性对于prometheus+grafana 落地生产最重要！

无论如何，请团队可以考虑优先级，谢谢！

随着 5.0 即将推出，我希望在下一个版本系列中看到一些重要的关注点。 从 Github 的反应来看，与警报相关的缺陷似乎是用户最感兴趣的。

我知道由于 UI/UX 复杂性问题，有些人不愿意解决这些问题，但是我不相信这些问题一定是合理的。 作为用户，我们是否可以做任何事情来帮助规划/设计或推动这些问题，而不是使用实际代码的拉取请求？

@torkelo这帮助我使用标签为我的所有主机设置警报，现在我的每个警报图都包含由标签组合形成的多个系列。 一切似乎都运行良好。 但是通过文档和其他问题，我意识到如果图中的任何系列已经处于警报状态，那么如果其他系列也超过限制，则不会触发其他系列的警报。

那又是限制。

谢谢。

有关此功能的任何消息？

新贡献者添加此功能的努力是什么？

+1

请允许将模板变量用于警报通知。
+1

+1

我们希望得到解决。

+1

我不想在这里打死马，但我们遇到了同样的问题，我想提供一些背景信息，说明为什么现有提案在所有情况下都不起作用。 我也有一些关于变通办法的想法，但为什么我们需要_一些特性_来帮助使变通办法足够。

对于以下所有场景，我们使用单个模板变量： $env

“为什么不直接创建警报仪表板？”

我们想提醒几个不同的环境，而不仅仅是生产环境。 所以我们现在需要在_至少_ 3 个不同的地方拥有相同的指标（包含所有指标的故障排除仪表板，而不仅仅是我们提醒的指标；产品警报仪表板；集成警报仪表板）。 这很快就会失控，并且容易出现用户错误。

同样重要的是，这抵消了警报自动注释的大部分收益。 如果我必须从探索性仪表板到警报仪表板来回查看事件开始时间和结束时间的注释，那将非常乏味。

尝试的解决方案

为了解决这个问题，我们所做的就是在我们的仪表板中添加了重复的指标（特别是用于警报）。 因此，如果有我们想要提醒的指标，我们会转到面板并为这些提醒添加明确的指标（并隐藏它们）。

对于需要提醒的给定面板，我们的系列列表将如下所示：

将非模板系列标记为隐藏。 然后在警报选项卡中，我们为 _these_ 系列设置阈值，而不是变量系列。

此解决方案的问题

这虽然不是很好。 例如：

如您所见，警报面板不允许我们指定_哪个环境_正在发出警报——因此我们必须深入了解警报以确定当前哪个环境出现故障。 然而，一个简单的解决方法可能是让描述像显示状态转换的警报历史面板一样冗长：

这至少有点帮助，但即使在这个面板中，也没有迹象表明哪个警报已经回到Healthy （如果有人想知道如何至少要显示那么多）。

在解决此特定票证之前会有所帮助的事情

• 允许显示系列别名而不是警报的类型描述的选项（这样别名至少可以指定它发出警报的 $variable）
• 允许状态转换回健康以显示系列别名（在上面的历史截图中）
• 允许给定面板的活动警报的图例值（使用我假设的系列别名）

我不确定如何解决的事情

为多个环境/变量配置了警报的图表上的注释：

有了这个，如果不进入面板，我们就无法真正分辨出哪个警报正在触发。 图例建议可以帮助澄清这一点，但如果未选择正确的$env （在上图中， int正在提醒，但prod是在仪表板上选择的变量，因此我们使用prod在图表顶部显示来自int警报的注释。

+1

加一 ：）

请停止对此问题 +1。 它会生成不必要的垃圾邮件。 对 github 问题评论添加反应的功能已经存在了一段时间，超过 429 人已经想出了如何为最初的评论点赞，而不是向所有订阅的人发送垃圾邮件。

请我们真的需要这个功能，我们想使用模板，但在我们的情况下，拥有一个清晰的警报系统是最重要的。 因此，为了解决这个问题，我们避免在仪表板中进行模板化......它一团糟。

我同意，此功能将对我们有很大帮助！！！！

请+1

我们需要这个

请+1。 真的很需要。

@bergquist @torkelo我们可以锁定这个问题以阻止 +1 垃圾邮件吗？