Grafana: [功能请求] 每个图表多个警报

具体用例：我已经对我的应用程序进行了检测，以便在 Prometheus 中为每个主要功能（例如发生外部 HTTP 调用或磁盘 I/O 的地方）记录直方图，并希望在其中任何一个变慢时发出警报。

目前我必须为此定义虚拟图，因为图和警报之间的关系是 1:1。 将警报定义在与图表本身相同的位置会更合乎逻辑。

你不能在一个查询中定义它吗？

不; 一连串的OR条件很粗糙，单一的Alert 名称并不能清楚地识别出alert 的确切原因。 我绝对不想按照Some part of service X is failing的方式发送警报 - 随叫随到的工程师不会是我的朋友...

如果您想要单独的警报规则名称和消息等，那么为警报设置单独的面板会更有意义。

是的，这正是我目前正在做的事情。 是否有可能在不久的将来为每个图表实施多个警报，以便我可以摆脱这种解决方法？

不太可能

也许如果有巨大的需求:)

哈哈好吧——我看看我能不能把愤怒的暴徒吵起来；）说真的，谢谢你的诚实。

好的，我们有两个暴民 :-) 我正在绘制多个油箱中的燃油油位图，并希望为每个油箱设置低燃油警报。

每个坦克都有不同的阈值或通知？

确切地。 一个是 285 加仑的取暖油箱。 当油箱低于 70 加仑时，我想设置“取暖油低”警报。 另一个是一个 500 加仑的丙烷罐，因为当它低于 100 加仑时，我想要一个“丙烷低”警报。 我为每个设置了单统计，但警报在单统计中不可用。

我有一个带有中位数和第 90 个百分位数指标的图表。 我想得到每个警报。 为了做到这一点，我必须为每个创建一个图表。 然后，如果我想要为每个警告和严重警报，我必须为每个创建第二个图表。

我有 30 或 40 个服务要监控，每个服务有 2 到 5 个关键指标。 我有图表，其中我为多个客户绘制了相同的指标，虽然我不必（还）为每个客户做警报，但它确实增加了我想要警报的指标数量。 创建数十个图表的工作量迅速增加。 在我当前的生产环境（以及我以前的生产环境）中，发出警告和严重警报，并在单个图表中显示多个指标并对其发出警报，这将非常有用。

我也想看看这个功能。 一个很好的例子是，如果指标超出阈值，则发出警报，如果数据更新失败，则发出另一个警报。 即，如果值过高或值无法报告。 这可用于表明无论报告数据的任何内容都遇到了阻止与 grafana（或任何后端）通信的问题。

嗨托克洛！

我得到了几个“喜欢”的功能！ 我们会进入下一个 realease =) 吗？

@rmsys也许在某个时候，从 UX 角度和代码复杂性（和 UX 复杂性）角度解决它需要时间，它还没有在任何路线图上，但可能在明年随着警报引擎更加成熟并且为此的 UX 设计工作出去

多个警报的另一个很好的用例是具有不同的严重性阈值和不同的操作。 如果服务器开始出现减速，一封电子邮件可能就足够了，但如果减速变得极端，则可能值得向管理员传呼。

我有一个图表，它返回一个值为valid和invalid的指标。 这对我很有用，因为我可以使用包含两个查询的单个图表来创建警报，当valid太低和invalid太高时触发。

此外，跟踪警报的单独状态并不总是首选（因为最终用户需要知道各个状态背后的详细信息）而不是只知道警报是否被触发。

不知道我明白你的意思。 你能详细说明吗？

您能否描述每个图表的多个警报的工作方式和外观？ 注释会说什么，面板标题旁边的绿色/红色心脏会显示（如果说 2/5 警报规则在哪里触发）？

您想在警报规则之间共享某些内容还是将它们完全隔离（除了生活在同一个图形面板中并且可能引用相同的查询）。

当您有多个警报规则时，您将如何可视化阈值？ 它们会在警报规则页面和警报列表面板中显示为单独的规则吗？ 然后，您需要一种方法来导航到规则的特定实例，而不仅仅是到警报选项卡。

Grafana 是一种可视化工具，我们选择将警报规则与图表联系起来，以便可以轻松地可视化警报规则状态（通过指标、阈值和警报状态历史记录）。 恐怕让每个图表都能够表示多个警报规则会在很大程度上使这变得复杂，我不确定是否需要这样做。

@rssalerno在 singlestat 面板中支持警报规则似乎与此问题无关。

@alex-phillips 您的场景听起来可以通过使单个警报规则更加灵活来解决。

有人有一些具体的例子吗？ 只是没有看到它最终会出现在一个令人困惑的图表中，其中包含 2-5 个您不知道的阈值与您也不知道它们来自什么警报规则的指标和警报历史注释相关（没有悬停）。

您能否描述每个图表的多个警报的工作方式和外观？ 注释会说什么，面板标题旁边的绿色/红色心脏会显示（如果说 2/5 警报规则在哪里触发）？

我认为将单独注释多个警报规则。 心可能是彩色编码的。 需要命名规则以区分警报/面板。

您想在警报规则之间共享某些内容还是将它们完全隔离（除了生活在同一个图形面板中并且可能引用相同的查询）。

一般来说，我认为不会，尽管我怀疑组需要有一个共享的阈值，并在它们被实施时命名（根据 https://github.com/grafana/grafana/issues/6557#issuecomment-324363795）。

当您有多个警报规则时，您将如何可视化阈值？ 它们会在警报规则页面和警报列表面板中显示为单独的规则吗？ 然后，您需要一种方法来导航到规则的特定实例，而不仅仅是到警报选项卡。

如果规则采用额外的颜色参数，则可以使用它来呈现阈值，并因此区分，可能还需要一个工具提示。 能够切换规则会很有用，我认为呈现特定规则的参数会处理后者？

@rssalerno在 singlestat 面板中支持警报规则似乎与此问题无关。

我相信您会发现他指的是下面的图表，尽管由于他为每个坦克都有单独的面板，单态警报可能会解决他针对特定仪表板的问题。

有人有一些具体的例子吗？ 只是没有看到它最终会出现在一个令人困惑的图表中，其中包含 2-5 个您不知道的阈值与您也不知道它们来自什么警报规则的指标和警报历史注释相关（没有悬停）。

首先，我希望它支持#6557 和#6553，以及多个阈值，类似于@alex-phillips。 例如，#6557 的一个用例是针对不同的环境（ production 、 beta 、 dev等）发出不同的警报，并结合多个阈值解决我们的大部分问题。 如果有没有多个规则的更好的方法，那对我来说并不明显。

@torkelo

您能否描述每个图表的多个警报的工作方式和外观？ 注释会说什么，面板标题旁边的绿色/红色心脏会显示（如果说 2/5 警报规则在哪里触发）？

我喜欢@pdf建议的方法

此外，显示注释的方法将与当前情况相同，在当前情况下，您的警报规则具有 > 1 个条件（每个条件具有不同的阈值）。 并且面板标题旁边的绿色/红色心将显示为红色（如果至少有一个警报正在触发），类似于当前的场景，其中警报规则的至少一个条件评估为真）。 并且可能还会在标题中显示数字（2/5）以及红色的心。

您想在警报规则之间共享某些内容还是将它们完全隔离（除了生活在同一个图形面板中并且可能引用相同的查询）。

在我们的大多数用例中，这些规则不会在它们之间共享任何内容，并且查询也不同

当您有多个警报规则时，您将如何可视化阈值？ 它们会在警报规则页面和警报列表面板中显示为单独的规则吗？ 然后，您需要一种方法来导航到规则的特定实例，而不仅仅是到警报选项卡。

它们将在警报页面中显示为单独的规则。 警报选项卡可能会定义一个警报列表。 是的，当从通知访问警报规则 url（应该捕获警报 id 或索引）时，我们需要在此选项卡上突出显示/扩展特定警报规则。 似乎很容易解决。

在警报列表面板中，不会有任何变化。 它分别显示所有这些。 从语义上讲，每个警报都是独立的。 只是它已被放置在同一个面板中。

有人有一些具体的例子吗？ 只是没有看到它最终会出现在一个令人困惑的图表中，其中包含 2-5 个您不知道的阈值与您也不知道它们来自什么警报规则的指标和警报历史注释相关（没有悬停）。

考虑到很多人都赞成这个功能，它肯定是一个有用的功能。 如果我们支持多个警报，那么我认为这取决于每个用户的感知是否令人困惑。 恕我直言，那些认为这令人困惑的人会采用当前为每个图表使用单独面板的方法，而对于那些认为将同一面板用于可视化和警报的实用性/便利性超过感知混乱的人，将采用多重警报方式. 当然它会稍微改变用户体验

在 splunk 中，我们有高/低警报。 如果 grafana 中有多个警报可用，我们只需使用相同的搜索，它们只是针对相同搜索的不同阈值。

+1 此功能。

为此+1。 我们的用例如下：我们想要定义一个图表，其中包含所有服务器的 CPU 使用情况。 然后在同一张图表上，我们将制作两个隐藏指标，一个用于生产服务器上的 cpu 使用情况，另一个用于非生产服务器上的 cpu 使用情况。 这些指标中的每一个都有自己的警报，具有不同的通知渠道。 我们不希望必须创建多个图表或面板或仪表板来完成此操作。

+1 此功能。

来到这里阅读有关类别和严重性的其他一些问题。 我同意所有警报都应该是可操作的。 但是“早上解决这个问题”警报和“尽快呼叫 400 美元/小时的顾问”警报之间是有区别的。

正如许多人所提到的，这是最常见的解决方法是警告和严重阈值。

从技术上讲，这可以通过多种方式实现，标签，每个面板的多个警报，每个警报的多个阈值等。

如果分类过于复杂，会造成混淆，警告/严重设置可以简单地使用红色/黄色。 红色覆盖黄色。

对于更复杂的设置，除了悬停来定位有问题的时间序列之外的另一个选项可能是闪烁的线/区域/什么？ 这可以很容易地引起人们对正确时间序列的注意。

我认为大多数用户都会对相当简单的警告/暴击分离感到满意。

这对于警报软件来说是绝对必须的，尤其是对于服务器监控。 磁盘空间、内存、cpu 使用率、温度、平均负载......所有主要示例都希望使用具有不同阈值的不同消息配置多个警报。 以磁盘空间为例。 磁盘使用率超过 70% 时需要一个警报，磁盘使用率超过 90% 时需要另一个警报。

有点极端情况，但如果产品在几天内没有售出，我们会使用警报来通知我们。 我们将每个产品作为一个指标，这反过来意味着当其中一个指标进入警报阈值时，我们只会收到一个警报。 理想情况下，如果警报显示任何其他指标也已进入警报阈值，我们希望收到警报。

我们还使用模板变量为每个选定的产品重复一个图表，在左右 y 轴上覆盖两个指标（数量和毛利率）。 这会扼杀任何使用警报的机会，因为警报查询没有为我们的IN ($sku)获取$sku列表变量。

为了解决这个问题，我尝试了另一个查询B ，它只运行模板查询来查找我们感兴趣的所有 skus 并将其直接放入警报查询IN (SELECT skus from interested_product_table) 。 但是，这开始向我们发送每个图表的警报，以了解每个图表中的所有指标，这意味着我们得到：

Email Alert 1 - metric1,metric2,metric3
Email Alert 2 - metric1,metric2,metric3
Email Alert 3 - metric1,metric2,metric3
Email Alert 4 - metric1,metric2,metric3

Email Alert 5 - metric4
Email Alert 6 - metric4
Email Alert 7 - metric4
Email Alert 8 - metric4

例如，这是相当垃圾的。

完全同意该功能是必须的，并且完全不同意所有通知都应该是可操作的。

最简单的例子是，您可能收到警报，您需要尽快采取行动，例如第二天早上，而其他类型的警报即使在半夜也应该让您起床以修复生产服务器。

投入我的两分钱 - 我很想拥有这个功能。

我什至不需要不同的心或不同颜色的心（红色表示图表上的任何警报都可以），这是我想要不同名称的电子邮件通知。

请添加此功能。 对于这样的用例，
从单个图表
如果值 > X --> 松弛
如果值 > X+Y --> PD

我们在此处制定了可操作警报的政策，警报应在可能的情况下指定要采取的措施。 根据指标太低或太高，我们有不同的行动要采取。

例如：RDS CPU 太低？ 在此处检查另一个堆栈的行为。 太高？ 扩大实例。

与其他人一样，我们也喜欢在不同的阈值下提供不同类型的警报。

与@jdblack类似，我想要一个高水位警告级别和一个高水位紧急级别。 我知道我可以通过两个查询来做到这一点，但它并不直观或流畅。

我正在考虑使用 Grafana 作为向自动缩放系统发出信号的一种方式。 如果指标太低，则发送带有消息的 webhook 以缩小，如果太高，则发送带有消息的 webhook 以扩展。 如果没有多个警报，我认为这是不可能的。 我也同意线程中的其他人的观点，即“警告”然后是“关键”阈值的用例很常见。

也许应该重新考虑将警报耦合到图表的想法？ 也许应该单独创建警报，并在创建警报时使用漂亮的预览图。 在更改图形指标时，这种解耦可能会使它更有效，但至少它在发出多个警报方面会有更大的灵活性。

我一直在尝试将 Grafana + Influx 用于传感器网络。 仪表板工作得很好，除了警报。 当 Sensor123 超过某个阈值时，我需要收到警报。 我不需要图表，只是一个警报。 此外，我可能需要有 1000 个传感器。 如果“任何”传感器超过阈值，我可以设置警报，但我需要知道哪些传感器正在发出警报。 我使用模板变量设置仪表板以查看特定传感器，但我无法为模板变量添加警报。 为了进行测试，我只是在一个没人看的额外仪表板中为少数传感器设置了少量警报，但接下来我需要一个不同的警报解决方案。

@torkelo ，距离官方对此发表任何评论已经快一年了——只是想知道现在警报系统已经存在一段时间了，是否有任何更新可以分享？

@MakoSDV ，您应该考虑将 kapacitor 用于该用例。

+1 此功能； 它对于两级警报也非常有用（例如：某物> X =黄色警报，某物> Y =红色警报）

+1 使警报更灵活

我在加热锅炉中监控温度图，低温阈值是微不足道的，需要转到非关键通知通道，但高温是紧急的，需要通过紧急通道蜂鸣。 多个警报规则在这里很有意义。

很遗憾，这个问题似乎被放弃了。 有谁知道我们如何让开发人员注意它？

看起来 UI 方面，以实现覆盖的方式实现警报相对容易，允许一个或多个警报而不需要太多 UI 更改。

@Gaibhne写道：

有谁知道我们如何让开发人员注意它？

也许支付支持？ 似乎没有任何资源可用于任何与警报相关的严重缺陷，尽管它们多年来一直是 Github 用户评价最高的问题。

对此请求 +1。

我们在我们的应用程序中设置了一个计数器，用于当对我们在 Grafana 中创建的图表的超时集成的外部服务的请求时。

如果有几次我们想知道的超时，以便我们稍后可以追查外部服务，如果有很多超时，则意味着我们的应用程序可能对大多数客户都受到了影响，因此我们需要做出响应并立即处理。

为此也为此+1。

目前正在尝试为图表设置两个单独的警报：

1. 数据达到_warning_级别的 Slack 消息
2. 数据达到_critical_级别的寻呼机职责警报

目前据我了解，我必须为相同的数据创建两个单独的图表才能完成此操作。 对我来说，让多个不同的警报作用在同一个图表上会更有意义。

@torkelo是否有关于 2019 年计划的更新？

+1

我们有仪表板，可以使用变量在显示的环境之间切换来监视多个客户端/环境的相同微服务。

如果我们能够在警报标题/文本中使用变量以便我们可以识别客户端/环境，那么我们当前的痛苦可能会减少，但从长远来看，我们真的希望能够使用相同的图表创建具有不同阈值的单独警报。

即使它需要为每个警报使用不同的查询，并且只是将查询设置为在图表上不可见，它也会很棒。

你所描述的@itonlytakeswon似乎也与 https://github.com/grafana/grafana/issues/6557 有关，所以你可能也想跟踪那个:)

这怎么不是一个功能？

@jsterling7完美地描述了我们想要的用例。

@torkelo任何功能发布

多个警报或在某处的警报标题/正文中允许标签值可以为我们的使用解决这个问题。 我们有一个图表显示了一个带有多个独立来源的标记指标，并且想知道哪个低于阈值。 我现在正在制作我需要完成此任务的 10 个单独的图表，但它感觉像是一个缺失的功能，并且对于我的长期维护来说很差。

似乎需求量很大，我是需要这种功能的人之一。 我几乎爱上了 grafana，然后突然间这个限制让我失望了。

我的用例与此处引用的其他用例和 #6557 问题类似。 我们在单个模板仪表板中监控了多个弹性搜索集群。 我想单独触发对它们的警报，因为现在我不能只创建一个带有硬编码查询的图表，而是必须为每个集群创建一个图表，以便让这个警报正常工作......

+1，这对我们的环境有很大帮助！ 即使每个图形设置只有一个黄色/红色“心脏”两个警报，如果触发红色，它会覆盖黄色。

+1这会很棒，想知道只允许每个条件都有一个可选的可配置警报通知是多么微不足道，如果不是针对特定条件，它可以退回到默认通知消息......实现它的最快方法我认为 ？

+1 这对我们也很有用。 我们有很多带有多个变量模板的仪表板，在警报名称和警报通知上都进行模板替换会很棒。

+1，IMO 这应该存在于每个监控系统中……在很多情况下，您需要确定警报的严重性并做出相应的反应，这意味着在同一个仪表板中具有不同阈值的多个警报。

我也 +1 - 很惊讶这还不存在！

+1

我认为此功能与模板查询支持的限制密切相关。

我已经设置了一些 prometheus 馈送图表，其中包含在实例上具有模板和类型标签的查询。 我通过为模板值创建不可见的查询来解决模板问题。

我希望每个模板值都有单独的警报，但我仅限于具有通用的一刀切操作+消息的单个警报。 我可以使用很长的 OR 列表来提醒我所有的查询，但这感觉很粗糙。

另一种方法是制作一个单独的仪表板，其中包含大量没有人看的面板，只是作为警报源。

添加对多个警报的支持似乎是支持模板查询警报的第一步。

+1。 这是必须的！

+1 这非常有用

@torkelo “如果您想要单独的警报规则名称和消息等，那么为警报设置单独的面板会更有意义。”

这没有任何意义。 要求用户多次可视化同一个面板以便他们可以发送有用的非通用警报消息不是解决方案。 这是对应该是功能的东西的破解，它增加了噪音，降低了产品的实用性。

@torkelo “如果您想要单独的警报规则名称和消息等，那么为警报设置单独的面板会更有意义。”

这没有任何意义。 要求用户多次可视化同一个面板以便他们可以发送有用的非通用警报消息不是解决方案。 这是对应该是功能的东西的破解，它增加了噪音，降低了产品的实用性。

确切地。 每个面板有多个警报 +1

在我们的情况下，我们正在测量电池中的电池电压（每个电池 16 个电池）。 我们将 16 个系列绘制在一个面板上进行比较，每个电池都有一个不同的面板。

面板（图表）的单个警报并没有太大帮助。 我们确实需要能够为每个单元设置至少一个警报，以便警报电子邮件指示哪些单元在电压方面超出范围。

由于在我们的例子中，每个电池的可接受电压范围是相同的，因此能够定义上限和下限并将单个电池范围与这些定义的限制相关联会很棒。

目前，我们必须为单元系列编写 16 x OR 语句，并（重新）定义过程中每个单元的限制——设置起来很痛苦，修改起来是一场维护噩梦。

理想情况下，我们还应该为图形面板上的每个单元格编写警告和关键事件。

我认为现在是修改警报结构以包含用户已确定的要求的时候了。 这些要求通常在也会生成警报的 SCADA 系统中实现。 它真的只是一个逻辑引擎，确定吗？

这事有进一步更新吗？ 我觉得这个功能对于大型部署来说是必须的。 特别是因为我们想要一个单独的图表，例如显示存储使用情况，我们想要一个 70%、80% 等的警报，这不应该是大量的图表。

我刚刚偶然发现了这一点，我很惊讶还没有办法做到这一点 D：

我在这里看到https://github.com/grafana/grafana/pull/20822#issuecomment -561047900 这将不会在未来实施，听起来警报将完全从仪表板中撤出。

这将如何影响仪表板 json 模型？ 任何人都可以谈谈什么时候会有更多关于这方面的消息？

这是一个非常需要的功能。 对即将到来的情况有任何更新吗？

每个面板有多个警报 +1

+1 此功能。

这是一个非常需要的功能。 对即将到来的情况有任何更新吗？

需要这个功能。

3年后..有人可以告诉我们为什么没有实施（尽管有很多请求）？
这是由于实施它的技术限制吗？ 被拒绝了？ 这是待办事项吗？
就像之前说的，似乎是一个“基本功能”。
示例：如果我添加警报，我有一个仪表板和一个包含 200 台服务器的系列：
200 台服务器中的一台已死机：酷我收到带有名称的警报
哎呀，新服务器死了：没有警报（或需要刷新仪表板或等待 24 小时后的提醒..）
这不可能像复选框一样添加以进行检查，以便我们可以通过系列中的行（而不是“完整”系列）来提醒我们？
如果开发人员，grafana 团队可以回答反馈...

您是否介意尝试使用 prometheus 进行警报并让 grafana 来做仪表板？

@beastea如果您必须设置另一个工具才能让 Grafana 工作，那么使用 Grafana 是没有意义的。 我们正在迁移到 Datadog，因为该功能在那里存在并且它只是一个工具。

@anne-nelson，您必须设置指标收集器、指标存储，并且为了正确设置，请在其周围使用 HA 以使 Grafana 工作，对吗？
Datadog 不仅仅是一个工具，它只是将它隐藏起来并做好工作，此外，您仍然可以将 grafana 与 datadog 一起使用： https ://grafana.com/grafana/plugins/grafana-datadog-datasource

@beastea我不确定这些工具是什么，所以我认为我们没有使用它们。 我们的指标被发送到 Influx，我们只是将它们发送到 Datadog 而不是 Grafana。 当我可以直接发送它们时，我为什么要通过 Grafana 将它们发送到 Datadog？ 我想使用尽可能少的工具。

@anne-nelson，您可以在您的应用程序中实现指标推送，但有时这对于推送一些系统指标非常有用，这样您就可以了解磁盘和其他东西的情况。 这就是我所说的指标收集器的意思，一些本地守护进程做这样的事情，比如 telegraf、collectd 或 fluentd。
Influx in your setup - 是一种存储指标并提供丰富功能的东西，通过 grafana 作为原始数据的 web ui 前端进行搜索，让您有机会使用一些内部流入查询语言来操作数据。
如果使用 Datadog 而不是 Influx，它的工作方式完全相同。 这里的 Grafana - 是用于访问数据的 ui。 在一般设置中。 所以它不会对你的数据做任何事情，它只是将它呈现在图表中。 所以你无论如何直接发送它们。
如果正如您所描述的那样，您正在与 inlux 合作，为什么不考虑使用 kapacitor 或 Flux 来解决您所描述的问题，因为它们提供了很多到达器功能，那么 grafana 可以为您提供并且它们仍然来自同一供应商并且喜欢相同的环境。 Flux 甚至是 influx 货运包的一部分。

这将非常有帮助。

@beastea所以可能更好地删除 grafana 中的“警报”功能并将人们迁移到另一个工具（以避免多个工具的 gaz 工厂）？
我的意思是，好的，我们可以使用 kapacitor、prometheus 等。但是 Grafana 中已经存在警报功能，所以这对我来说毫无意义。

顺便说一句，阻止添加此复选框以逐行发出警报是什么？ 大概一个解释可以帮助理解。

@beastea您试图说服某人不要使用 Grafana 似乎真的很奇怪。

正如 anthosz 所指出的，只要警报是 Grafana 中的一项功能，就可以合理地期望能够将多个警报添加到图表中。 如果您认为我们不应该使用 Grafana 进行警报，那么 Grafana 不应该将警报作为一项功能。 很明显，很多人都想要这个功能，而且很多竞争产品已经提供了它。 老实说，我不明白为什么会有如此多的反对。

@anne-nelson 我并不是要说服任何人不要做他们想做的任何事情。 我试图给出一个建议，看看今天已经可以为您提供解决方案的不同方向。
我不是在规定您应该使用什么，而是在提供一种替代方案，可以在今天为您提供解决方案。 我不是反抗，我是给你一个建议。 如果您认为我的建议没有帮助，那很遗憾，仅此而已。 很抱歉你觉得我让你很烦，而且我的建议太咄咄逼人。
玩的很开心。

@beastea由于您的防御性，我假设您为 Grafana 工作。 此功能与很多人相关，并且在功能请求中建议替代产品是无益的，并且会破坏此讨论。 这不是堆栈溢出。

每个人都可以打掉它吗？ 您正在向数百人发送垃圾邮件，这没有效率。

抱歉所有额外的噪音。

@torkelo您介意向我们提供有关此功能请求的最新信息吗？ 这个话题已经开放了 _years_ 并且你可以看到仍然有兴趣。 至少它可能有助于减少关于这个话题的争吵和不必要的喋喋不休，以获得某种“官方”答案，说明这是否包含在当前的路线图中。 干杯。

这一个和#6041 相似的完全被忽略了。 我想知道为什么。

对我们来说，这是有道理的，因为我们的运营团队在我们的平台上注册了新的集成。 我们会自动开始向石墨发送指标。 grafana 中只有一个面板可以看到所有这些。

当多个系统出现故障时，我们只会收到第一个系统的警报。 而且也不是很解释。

当一个关闭，第二个也熄灭时，警报不会再次触发。

我的用例是通过 prometheus 和 grafana 定义多窗口多燃烧率警报。 按照 Google SRE 手册https://landing.google.com/sre/workbook/chapters/alerting-on-slos/中的定义，使用此类警报来监控 SLO 是一种标准做法

绝对必须，请跟进这个..

我也从 Prometheus 警报转移到 Grafana 警报，我非常期待这个！

之前在 Grafana 工作过的人能否列出解决此问题的已知挑战？

嘿@torkelo ，也许你能在这件事上给我们启发！

令人失望地看到 7.x 对警报没有任何改进 - 之前关于完全删除警报的建议并没有让我充满希望，但如果是这种情况，肯定会在 7.x 中删除它考虑到改造的规模是否合乎逻辑？

很高兴能得到一些关于为什么这很难实现的更新，这样我们才能理解_为什么_这个问题已经开放了这么久。

@torkelo你好。
我有同样的需求 - 单个 graf 上的单个指标的多个警报，但有多个服务器被监控。
我有大约 100 台服务器，在“/”分区定义了可用空间指标（例如 - 因为我有数十个这样的指标）。 如果“/”上的可用空间将小于 20%，我需要在每个服务器上接收一个唯一的警报通知。
目前不会发生这种情况，例如 server2 会发出警报，而当人们正在努力解决问题时，server4 会发出相同的警报 - 我们不会收到通知。 还是我缺少一些功能？

每个服务器每个指标的面板倍增的方式不是方式。
有人可以为我提供建议，如何使这成为可能？
我应该升级我的 Grafana（当前版本是 6.3.5）吗？ 添加一些扩展？ 插件？ 还要别的吗？

我感谢并感谢所有可以提供建议或帮助的人。

@torkelo你好。
我有同样的需求 - 单个 graf 上的单个指标的多个警报，但有多个服务器被监控。
我有大约 100 台服务器，在“/”分区定义了可用空间指标（例如 - 因为我有数十个这样的指标）。 如果“/”上的可用空间将小于 20%，我需要在每个服务器上接收一个唯一的警报通知。
目前不会发生这种情况，例如 server2 会发出警报，而当人们正在努力解决问题时，server4 会发出相同的警报 - 我们不会收到通知。 还是我缺少一些功能？

每个服务器每个指标的面板倍增的方式不是方式。
有人可以为我提供建议，如何使这成为可能？
我应该升级我的 Grafana（当前版本是 6.3.5）吗？ 添加一些扩展？ 插件？ 还要别的吗？

我感谢并感谢所有可以提供建议或帮助的人。

这个问题自 2017 年开始开放（@torkelo 的回答是🤡 “为警报设置单独的面板更有意义”🤡（当我们有 600 台服务器时，通过服务器/警报创建面板非常好）🤡）。

似乎唯一的方法是从 Grafana 迁移到另一个解决方案或创建一个具有多个工具来维护的 gaz 工厂。

@anthosz - 非常感谢。 问题是环境不是我们的，而是客户的，所以我要坚持这个作为我的领导，然后让他克服客户的“不会为此买单”，这对我来说是一件非常不容易的事.
但是，至少我有一些事实表明“不可能以这种方式组织此类触发器/警报”。

再次感谢。

_加入（声音，合唱团）_
我在电路上有一个电流传感器，用于监控空气泵、标称 1.5 安培和标称 10 安培的污水泵。 空气泵 24/7 运行，污水泵根据水箱液位按需运行。 当一切正常时，当污水泵关闭时电流 (I) 为 1.5A，或者当污水泵开启时电流 (I) 为 11.5A。

第一个常见故障是空气泵烧毁，当空气泵停止工作时，会通过（Imax < 0.5A 或 Iavg 在 9A 到 11A 之间）发出警报，检测到没有电流或污水泵在运行。 这必须在 48 小时内解决，以避免系统故障。 数据为每分钟 1 个点，90 分钟后发出警报。

同一图表上的第二个期望警报是（Imax > 14A 或 Iavg 介于 2A 到 9A 之间），这表明污水泵在应该泵送时堵塞或管道内有空气。 这是一个更紧急的警报，可能需要在 3 小时内解决，因此 5 分钟后发出警报是理想的。

两个警报都来自同一个远程电流传感器，通过 LoRa 发送数据。 多个警报将简化，让我不必为同一个传感器重复仪表板查询。

@torkelo多个图对于许多用户来说根本无法扩展。 这似乎是一件很简单的事情，我很好奇你们为什么不考虑它？

也许如果有巨大的需求:)

嘿@torkelo ，你认为什么是巨大的需求？ 您的评论中有 96 条评论和 250 条“赞”是巨大的吗？ 这是评论最多的第 8 位开放功能请求，只有一个已关闭的功能请求有更多评论。 这也是第 3 个开放功能请求，有更多 :+1: 反应。 进入路线图需要什么？

@torkelo我有一个非常简单的案例场景。

如果值低于阈值，我需要一个不同的警报，而不是值超过（不同）阈值时的警报。

这是一个不同的场景。 当我监控健康的服务器数量时，当我失去 1 台服务器（合法重启这不是问题，除非它占用超过 10 分钟）时，我需要不同的警报，而不是失去 5 台服务器。

这是另一种情况。 如果队列的增加率超过阈值，我想设置不同的警报，如果队列大小本身超过阈值，我想设置不同的警报。

在可视化方面，我相信社区会对任何一开始的解决方案感到满意。 例如，仅可视化第一个警报（因此无需更改 UI）。 使用垂直线可视化所有警报，当悬停时告诉您触发了哪个警报。 仅当您将鼠标悬停在特定系列上时才显示阈值/警报等。

只是我的2美分。

你好！

想在这里插话，我们（Spotify）也需要这个。

我们目前运行我们自己的警报引擎，从 Grafana 采购警报，并按时间序列发出警报。 我们目前将每个时间序列的警报注释推回 grafana。

因此，在 UI 方面，第一个警报时间序列会导致面板/警报进入“警报”状态，并且每个后续警报都会堆积起来（状态历史记录将显示“到”警报的多个更新，同样，多个更改回到“好的”）

我们“需要”这个，因为这就是我们一直以来的警报方式，因此对于大约 10K 警报来说，摆脱按时间序列警报将是一个巨大的社会变革。 我们非常希望使用和采用 Grafana 原生警报并更新我们的数据源以支持它。

想在这里插话，我们（Spotify）也需要这个。

您是否也使用过 Grafana 企业？ 也许可以帮助/激励开发人员 =)

我们也很想看到这个功能，即从同一个图表触发多个警报的能力。 赋予触发“低于”和“高于”状态的能力，并有可能在更重要的阈值突破之前获得有效的琥珀色警告

我们目前运行我们自己的警报引擎，从 Grafana 采购警报，并按时间序列发出警报。 我们目前将每个时间序列的警报注释推回 grafana。

@sjoeboo这里有点离题，但有什么公开可用的吗？

@vbichov还没有，我们确实想开源警报引擎，尽管时间框架在不断变化。 我确信我可以分享我们在（不太理想的）内部分支上的补丁，以通过注释启用按时间序列跟踪警报。

请注意，警报引擎现在特定于我们的 TSDB (https://github.com/spotify/heroic)

+1 此功能。 这有点像警告/关键。 我们希望在生活变得更糟之前得到警告。 然后我们应该得到关键警报以立即采取行动。

令我惊讶的是，在用户提出 3 年的请求后，这还没有实现。

必须创建多个面板（每个警报一个）最终会阻塞仪表板，并使添加新警报的方式比应有的方式更加复杂

如果您不能为每个面板定义多个警报，我总是想知道为什么警报选项卡中会显示 1。 在查询选项卡中，此数字还显示已定义查询的数量。 所以我一直认为这是可能的，我很惊讶这还不可用。

有趣的是，这仍然没有实现。 我同意警报选项卡上的“计数”具有误导性，因为它使人们相信可能有多个。 此外，每个警报规则都有一个面板有点荒谬，因为这意味着我有一个“无用”的仪表板，它只是用于警报的面板。 这肯定是一个杂乱无章的仪表板，但它是实现这一点的唯一方法。 主要是这样我可以对名称和/或通知端点组合有不同的规则。 至少可以说很复杂。

这已经完成了吗？
Grafana 版本 = 4.x

现在 Grafana 版本到 7.x，我没有看到这个功能

这已经完成了吗？
Grafana 版本 = 4.x

现在 Grafana 版本到 7.x，我没有看到这个功能

好天真😁

+1 此功能。
在一个单一的指标上，我想要

1. 警告警报，指示组件未按预期运行，需要 2 线支持人员密切监控
2. 指示组件出现故障并触发对第三线工程的标注的错误警报。
   复制指标很笨拙，并且使我们的仪表板难以监控。

这么多简单的功能经常被这个组拒绝，检查许多其他功能请求..这似乎是基本的。

我再举一个例子。

我运行了一个 Synology 并想提醒它。 Raid Status 的正常值为 1。但它也有 Degraded 值 11，Crashed 值为 12。Degraded 意味着数据仍然可以访问。 崩溃意味着数据丢失的可能性很高。

如果 Raid 降级，我想发出警告，如果 Raid 崩溃，我想发出严重警报。
我有多个卷和存储池，并且每个都需要多个图是不可扩展的。

这也可以应用于像磁盘空间使用这样简单的事情。
如果磁盘使用率达到 80%，我想发出警告，如果磁盘使用率达到 90%，我想发出严重警报。 为我的每个磁盘做多个图表并不是一个合理的要求。

而且我不理解在 UI 中这很难的评论。 您已经有了类似的东西，即仪表板列表。 当您单击警报选项卡时，它应该按名称显示警报规则列表，底部带有“创建新警报”按钮。 每个警报规则的右侧都应该有一个“编辑”、“禁用”或“删除”选项。 通过单击警报或编辑按钮，它应该会将您带到显示的现有编辑页面，但针对该特定警报规则。

为我的每个磁盘做多个图表并不是一个合理的要求。

您可以使用 api 自动创建/更新仪表板及其警报。 如果您愿意，您可以创建一个程序来查询 prometheus（或您拥有的任何来源），方法是定期运行查询以获取目标的服务发现并自动创建警报或警报。

令人难以置信的是，这个功能还没有实现，这个问题有很大的反馈。

我使用 Grafana 作为麦哲伦望远镜的可视化和警报引擎。 如果我有几个共享特征的子系统，这些特征使它们都在一个情节中，当出现问题并且一个开始表现不佳时，我的用户必须得到一个神秘的警告并挖掘失败。

创建虚拟图是一种解决方法，而不是解决方案。 这似乎很基本！

+1 必要功能

+1

与OP完全相同的情况。 应该已经实现的基本功能。

人们可以在不增加任何价值的情况下停止向这个线程问题发送垃圾邮件吗？

使用问题顶部的反应来表示兴趣。

https://github.com/grafana/grafana/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc对于维护者断言哪些问题是“流行”的比垃圾邮件更有用每个人都通过电子邮件收件箱和 github 通知，其中包含仅通过查看问题描述就已经清楚的信息。

如果它是如此基本，也许所有抱怨者中的某个人只是希望其他人为他们免费工作，应该自己实现它，如果维护者不希望它在上游，要么提出拉取请求，要么维护自己的分叉。

@thomasf “人们可以在不增加任何价值的情况下停止向这个线程问题发送垃圾邮件吗？” - 就像你一样？

如果维护者仍然在线程中，新的评论至少会提醒他们。 在这一点上看起来确实有点没用，维护者不可能在这么长时间后实现它，人们应该真正转向更好的工具，比如维护者真正关心的 Datadog，但有数百条评论（特别是当他们有实际场景时） ) 比竖起大拇指的影响要大得多。

如果维护者仍然在线程中，新的评论至少会提醒他们。 在这一点上看起来确实有点没用，维护者不可能在这么长时间后实现它，人们应该真正转向更好的工具，比如维护者真正关心的 Datadog，但有数百条评论（特别是当他们有实际场景时） ) 比竖起大拇指的影响要大得多。

或者维护人员可能因为垃圾邮件而取消订阅有关此问题的通知，这并不是唯一一个有很多 +1/消息但没有更新的人。 请不要比较 Grafana 和 DataDog（我们是两者的用户，没有办法回到 DataDog）

获得这个的最好方法是贡献（或者可能为 Grafana Entreprise 付费）

你是非常非常错误的。 免费与否你不能放一个
forum/slack/github/feedback 频道，然后忽略它。 如果你认为
将软件置于开源许可证上意味着“没有投诉”和“人们
将免费为您的功能开发”您又是非常非常错误的。
我的案例我向他们解释说，有了这些功能，我可以将 grafana 卖给十个
我的客户。 忽略我，这意味着对客户生气。 伟大的
移动可能他们做了“足够”的钱，他们不想要更多，我很高兴
为他们......

Il giorno mer 14 ott 2020 alle ore 15:35 Thomas Frössman <
通知@github.com> ha scritto：

人们可以在不添加任何内容的情况下停止向这个线程问题发送垃圾邮件吗
价值？。

使用问题顶部的反应来表示兴趣。

如果它是如此基本，也许所有抱怨者中的某个人只是期望
其他人为他们免费工作应该自己实施
如果
维护人员不希望它在上游。

—
您收到此消息是因为您发表了评论。
直接回复此邮件，在 GitHub 上查看
https://github.com/grafana/grafana/issues/7832#issuecomment-708406018 ，
或退订
https://github.com/notifications/unsubscribe-auth/AABBIFUYLMIO4WH7LBYQ6FTSKWSLXANCNFSM4DDVAQPQ
.

我愿意花在_任何_软件上的金额与我可以预期的客户服务水平成正比。 无论是提供“付费支持”的开源产品还是商业产品，都无关紧要。

不幸的是，让这个问题保持开放这么久而没有项目维护者的窥视可以推断出对花钱是否会有任何不同的合理怀疑。 如果您正在尝试销售软件，那么考虑这一点可能是明智的。

提出拉取请求或维护自己的分叉

如果开发人员甚至暗示从哪里开始，我相信我不是唯一一个说我会考虑这个的人，不管我是否认为我应该这样做，仅仅是因为它的绝对价值提供。 可悲的是，情况似乎并非如此，我对尝试对产品进行逆向工程以实现维护者似乎并不真正关心的功能几乎没有兴趣。

最后，除非线程被关闭/锁定，否则我认为没有理由不说出自己的想法。 如果不适合您，您可以退订。 我真的很喜欢读到人们感叹这种相对荒谬的事情。 😁

计划用于 8 的警报 NG (NextGen) 警报将支持来自单个警报定义的多个警报实例。 因此，像 prometheus 这样的系统的host=*会为每个主机创建警报。

在添加到https://github.com/grafana/grafana/issues/6983#issuecomment -712915673 的单个统计信息中有关此的一些一般信息

我们仍在设计和原型设计，但要回应一些初步的想法：

每个图表有多个警报

警报定义将是它们自己的实体，因此它们不会绑定到面板。 从警报定义可以成为多个警报实例。 然后面板可以订阅实例或定义。 我想我们仍然希望仪表板面板中有一个很好的 UX 路径来创建警报，因为这是一个很好的流程。

此外，跟踪警报的单独状态并不总是首选（因为最终用户需要知道各个状态背后的详细信息）而不是只知道警报是否被触发。

一旦允许来自一个定义的多个警报，那么如何对它们进行分组就成为一个问题（因为一个人可以获得许多警报）。 我目前看到了两条关于这将如何与 Alerting NG 一起使用的途径：

1. 使用可以处理警报实例分组的 IRM（例如 pagerduty 或 alertmanager）来使用警报 NG。
2. 将您的查询更改为按更大的范围维度进行分组。 因此，例如，如果查询cluster=*而不是host=*,cluster=* （或像数据源这样的 sql 分组）。 或者，如果数据源不这样做，我打算向服务器端表达式添加功能（带有警报 ng）以允许分组/按透视操作。 当不使用 IRM 并直接发送到电子邮件/slack 等服务时，就会出现这种情况。

警告/严重

这个比较复杂。 对于 WIP 设计，我已将其作为一项功能删除（至少对于警报定义，可能会有一种方法来复制警报定义、更改它，以及如何用严重性标记/标记它）

这很难，因为在很多情况下，它非常有用：

• 对我来说，警告/关键有明确的用途：接近损坏/损坏，或降级/损坏。
• 没有它们，许多设置最终会针对不同的严重级别重复大量警报。

那么为什么决定不拥有它们呢？ 它增加了相当多的不明显的复杂性：

• 假设您希望支持来自另一个指标的阈值（或者您的阈值是不同的查询时间范围，而不是值），现在有两个条件可以运行。
• 对于警报实例的状态，我至少要支持：
  
  
  
  • 未知：一个实例消失了
  
  
  • 错误：会发现有关实例的问题的查询已损坏
  
  
  • 警报：条件为真
  
  
  • 普通的。 条件不成立
  
  
• 我们还希望继续使用 FOR 类似的表达式。 当添加更多状态时，设计不会导致错过通知或噪音的飘动是复杂的。 一般来说，随着时间的推移，状态机很容易出现错误并且很难正确处理（如果您喜欢这种事情，请搜索 TLA / 动作的时间逻辑以了解更多信息）。 因此，添加严重级别会增加状态空间，超出人们的猜测。 这意味着我们更有可能出现意想不到的行为，或者更难以建立心理模型的行为。
• 在寻求与其他系统或 IRM 集成时，对严重性有特定概念可能会使集成复杂化。

（至少对于警报定义，可能会有一种方法来复制警报定义，更改它，以及如何用严重性标记/标记它

对于关键/警告区分来说，这是一个完全可以接受的解决方法。 我很高兴保持单独的阈值。 拥有一个组合的警告/严重阈值会很不错，但不会破坏交易。

那么它们应该如何分组成为一个问题（因为人们可以获得许多警报）

由用户管理自己的工单数量和警报生成。 如果您要设置警报，每个警报都应该是单独的电子邮件或通知。 可以这样想，如果您创建一个自动化系统来根据警报触发生成工单，例如，将多个警报分组到一封电子邮件中，这会使这变得困难或令人讨厌。 此外，在一封电子邮件中显示多个警报意味着每个警报不能有自己的电子邮件线程，它需要由用户手动分离并启动新线程。 相反，每个警报触发都应该有自己的通知，以便可以将线程包含到该特定警报中。

希望这可以简化令人担忧的设计，因为您不必担心分组。 这由用户来处理。