Grafana: 为grafana构建警报系统

我很乐意帮忙解决这个问题！ 我的建议是坚持 nagios 风格的指导方针。 这样，这些工具就可以很容易地与其他监控工具一起使用。 例如 Nagios、Zenoss、Icinga 等。

此功能最重要的一点是使基本架构正确。

我想探讨的一些问题
1) 需要哪些组件，它们如何运行（在 grafana 中的 proc 中，在 proc 外），
2）如何协调。
3）我们是否应该忽略“流中”警报，（只关注基于拉的）

更深入地了解 1)
我担心将 grafana-server 变成一个整体。 想找到一种方法将 grafana-server 分离成彼此更加隔离的服务（并且可以在 inproc 或作为单独的进程运行）。 这是一种带有总线抽象的计划。 另一种选择是让警报组件仅通过 HTTP api 与 grafana 对话，可能会限制集成，不确定。

我同意 torkelo。 根据我对“内置”所有内容的其他项目的经验，进行故障排除会变得非常麻烦。 我喜欢服务在外部运行的想法，但是 grafana 中有一个不错的配置页面，它通过 HTTP api 与服务对话以处理管理所有警报。 此外，对于大规模部署，这可能最终成为一项要求，因为性能最终会降低（我至少会将其作为配置选项）。

我们是否与当前的 grafana 图阈值设置（目前仅用于可视化，不用于处理）集成？ 如果表达式是阈值检查，我们可以自动显示阈值线

我认为这可能是一个很好的起点。 如果设置了就提醒，如果没有就不要。

回到第 1 点。我认为，如果 bosun 服务可以单独运行，但仍然能够通过 grafana 完全配置所有内容，在我看来，这将是理想的。

继续出色的工作。

我在 bosun 中看到的唯一缺点是它可以使用的数据源。 如果您可以利用该语言来表达 bosun 警报，而且还可以与通过常规 grafana UI 配置的现有数据源集成，那么这当然是理想的选择。

能够表示警报阈值，当你接近它们时，以及当它们在我脑海中触发时自动推送注释，构成了一个理想的单窗格 UI。

期待在这里完成的工作！

1. 它应该使用仪表板中定义的阈值来提醒
   让我们保持简单； 如果仪表板显示警告颜色，则应发出警报。
2. 这可能是 grafana-server 进程本身之外的事情。
   ... 使用其余 api 来抓取仪表板及其设置并使用外部命令呈现它们和警报的东西。
3. 警报级别； 只是在编辑器中放置一个框，应该监视此仪表板； 它应该每分钟检查一次。 如果没有数据，它应该在一段时间内仍然应该保持警报吗？ （复选框）

最后; 由于我们更多地依赖 Grafana，我承认我愿意说 2. 可能是我愿意支付的费用。

我很好奇为什么人们认为这应该包含在 Grafana 中？
Grafana 既不接收也不存储实际数据，而是“仅”将其可视化。 任何警报系统都应该基于指标存储中的数据。
如果这真的集成到 Grafana 中，我希望可以禁用它，因为在这里我们已经使用 Icinga 进行警报，因此 Grafana 中的任何类型的警报只会使 GUI 更加混乱，即使它根本不会使用。

绝对正确@dennisjac; Grafana 只渲染东西。

但是，随着我们移动服务器端，它不再只是客户端渲染； 可以检查您的指标和警报的工作进程的可能性； 难度较小。

数据在数据库中； 如果它散布着告诉它检查指标的数据......

有些人可能同意或不同意我们不应该越过溪流并使 Grafana 做的不仅仅是可视化（粗略地），但我不是他们。

对于希望集成该功能的人，我并不真正反对该功能，但我希望对于已经拥有可用监控/警报系统的人来说，它可以成为可选功能。

新的 Telegraf 项目（来自 influxdb 的度量收集器）也在研究监控/警报功能，这也是出于同样的原因。 我在这里详细说明了这一点：
https://influxdb.com/blog/2015/06/19/Announcing-Telegraf-a-metrics-collector-for-InfluxDB.html#comment -2114821565

我认为 torkelo 在为我们提供 Grafana2 中不需要启用的功能方面做得非常好。

就 influxdb 而言，他们将不得不以某种方式赚钱； 无论是对 influxdb 和专业服务或产品的支持。

后者听起来更可行

关于这个的另一个角度。 似乎即将支持 elasticsearch 作为 grafana 的度量存储。 Bosun 现在可以查询 elasticsearch 的日志数据。

在设计警报系统以允许来自日志数据的警报时是否有意义？ 也许不是第一个版本的功能，而是可以稍后实现的功能。

我也同意拆分流程的想法。 让 Grafana 界面来查看和创建警报，让其他东西处理警报。 基于警报部分 api 还允许其他工具与之交互。

+1 到警报。 在 DevOps 使用之外，为最终用户构建的应用程序需要提供用户定义的警报。 很高兴在可视化工具中使用它...

+1 这将关闭循环 - 获取指标的建议。

来自 Grafana 的 +1 警报 + 来自 InfluxDB 的水平扩展后端将使它们成为衡量指标警报配置的标准

+1 我喜欢在多个 grafana 节点上水平缩放警报。

如果可以将类似“去抖动”的行为与警报联系起来，那就太好了。 例如，我只想在定义的阈值超过 X 持续 N 分钟时触发警报。

我已经在一些警报工具中看到了这一点，不幸的是我们目前正在使用 Seyren，它似乎没有提供这样的选项。 我们正在使用 Grafana 进行仪表板开发，并期待将警报也引入 Grafana。 保持良好的工作。

我们有两个用例：

• 基础设施团队像往常一样通过配置工具将警报创建到公共监控堆栈中（常见集群检查或 nagios 友好系统中的系统检查）
• 软件开发人员通过 Grafana 创建应用指标

我们希望有一个统一的警报系统来处理警报、摆动检测、升级和联系。 这有助于我们在同一事实来源中记录和关联事件/操作。 很多系统都解决了告警问题。 我希望 Grafana 从长远来看能在这方面做得更好，短期内不重新发明现有系统将有助于交付。

一个建议是 Grafana 可以提供 API 来提取监控定义（警报状态），第三方可以贡献配置导出插件。 这在我们导出 nagios 配置的用例中非常理想。

更重要的是，我也很想看到一些集成的异常检测解决方案！

在2015年7月15日，在17:40，Pierig勒索克斯[email protected]写道：

+1 我喜欢在多个 grafana 节点上水平缩放警报。

—
直接回复此邮件或在 GitHub 上查看。

我同意@activars。 我真的不明白为什么仪表板解决方案应该处理警报，这是许多其他工具或多或少解决的问题，大多是相当成熟的。 做一件事，并把它做好。

恕我直言，专注于 _integration_ 部分会更有意义。

示例：在 grafana 中定义动态警告/暴击阈值（例如在上面的@Dieterbe示例中）并提供一个 API（REST？），该 API 返回该图的状态（正常、警告、暴击）。 nagios、icinga、bosun 等可以请求所有“监控”启用的图（另一个 API 功能），遍历各个状态并执行必要的警报。

在我们的案例中，服务目录和定义的操作是最难的部分 - 哪个服务是业务的关键，将电子邮件发送到哪里，拍打等。此外，您不必担心大多数公司已经在 Grafana 中进行的用户/组管理中心位置（AD、LDAP、Crowd 等）并与警报系统集成。

此外，我们必须考虑到，与仪表板解决方案不同，警报工具的质量要求在可靠性、弹性、稳定性等方面可以被认为要高得多，这会产生不应低估的（测试）工作。

还有非时间序列相关的检查呢，比如调用网络服务、ping 机器、运行自定义脚本……你也想在 grafana 中这样做吗？ 我想水手长领养会提供所有这些，但我并不真正熟悉它。

另一方面，我可以想象一个简单的警报系统如何让许多没有好的替代方案的用户感到高兴，但这可能可以通过其他警报工具的一些示例集成模式来解决。

尽管我希望 Grafana 解决我的所有问题，但我认为 falkenbt 用这个方法一针见血。

用于公开上述数据的 API、bosun 中的一些管道以及与常见警报平台的一些集成模式很有意义。

祝贺你在raintank @Dieterbe 的新工作！ 我已经阅读您的博客一段时间了，您在监控方面有一些非常合理的想法，特别是关于指标及其在警报中的位置。 我相信您会找到一种在 grafana 中实现警报的好方法。

正如您可能会同意的那样，Bosun 背后的人几乎都在以正确的方式进行警报。 Bosun 缺乏的实际上是可视化。 我想在 Grafana UI 背后看到 Bosun。 将 Grafanas 仪表板和 bosuns 警报结合在同一界面后面将形成一个很棒且完整的监控解决方案。

此外，我认为进一步分割开源监控社区是一种耻辱，您对监控的想法似乎与 Bosun 背后的人的想法非常吻合。 如果你能团结起来，我相信结果会很好。

在我工作的地方，我们将 Elastic 用于日志/事件，并且刚刚开始使用 InfluxDB 作为指标。 我们一直在探索不同的监控解决方案，目前倾向于 Bosun。 我们已经将 Grafana 用于仪表板，但希望通过同一界面访问我们所有的监控信息，如果 Grafana 能够成为该界面，那就太好了。

继续努力，祝你好运！

在相关的切线上，我们通过将 grafana 与 riemann 集成使警报部分工作。 了解 grafana 的内部结构是一个很好的练习:)。

这对 riemann 来说更容易，因为配置只是 clojure 代码。 我想这种整合在 Bosun 会更难。

这是它的几个屏幕截图

对 grafana 部分的更改包括添加一个“/alerts”和一个“/subscriptions”端点，并让它与位于顶部的另一个小 api 通信，以便 riemann 执行 crud。

好消息是警报定义中的更改会立即反映出来，而无需向 riemann 发送 SIGHUP。 因此，启用/禁用状态更改的时间段调整只是在 UI 中更改它并将该更改传播到 riemann 的问题。

仍然没有对这种集成进行基准测试，但我认为它不会那么糟糕。 将在我清理代码并上线后写博客。

我们这样做的全部原因是因为人们可以继续从非常熟悉的 UI 设置这些警报和通知，而不必打扰我们编写 riemann 配置 :)。

@sudharsh你的实现听起来很有趣。 你打算把它放回野外吗？

很多好主意，谢谢大家。
受到一些评论和@pabloa的https://github.com/pabloa/grafana-alerts项目的启发，我们决定首先关注 UI 和 UX 来配置和管理警报规则，作为相同工作流程的一部分编辑仪表板和面板。 Grafana 会将这些规则保存在某处并提供对其的轻松访问，以便其他脚本或工具可以获取警报规则。
也许通过文件、API 调用、仪表板配置中的一个部分或数据库中的条目。
（我喜欢将它作为仪表板定义本身的一部分的想法，以便开源项目可以为它们提供 grafana 仪表板 json 文件，这些文件将包含警报规则，但默认情况下不一定处于活动状态。另一方面，将它们放入数据库似乎更健壮）
无论哪种方式，我们都希望提供轻松访问，以便您可以为要使用的实际执行警报规则和处理事件的任何其他系统生成配置。 （从这里开始，我将其称为“处理程序”）。
这样的处理程序可以是 nagios、sensu 或 bosun，您编写的工具或石蕊警报调度程序执行程序，这是一个可以编译到 grafana 中的处理程序，它提供了由 bosun 支持的良好而简单的集成，但我们真的很想确保您可以使用任何您想要的系统。

只要您的处理程序支持查询您使用的数据存储。 我们将从简单的静态阈值开始，但后来也希望可以轻松选择缩减函数、多个条件之间的布尔表达式等。

@sudharsh这是一个非常好的方法。 我喜欢您的解决方案如何直接与远程 API 对话，绕过上述中间步骤（当然，这确实意味着它仅适用于我们试图避免的 1 个给定后端），并且它可以自动重新加载配置。 （你是对的，bosun 目前不支持它，将来可能会支持。FWIW 石蕊处理程序确实处理这个问题，它使用 bosun 的表达式评估机制）。 我从来没有真正深入了解黎曼。 大多数情况下，我一直担心在堆栈中添加这样一种不同的语言，当出现问题时，没有多少人理解或可以调试。 但我很想了解更多关于你的系统和黎曼 CLJ 代码的信息。 （如果我的怀疑是不正确的，我会喜欢它）

@dennisjac是的，这将是可选的。
@elvarb有一张 ES 作为数据源的票。 事实上，目标是如果 grafana 支持从给定数据源渲染数据，它也应该支持为其编写警报规则。 至于查询执行/查询，这当然取决于您决定使用的处理程序。 （对于石蕊处理程序，我们将从最流行的处理程序开始，例如石墨和 influxdb）
@rsetzer ：同意，能够指定在触发之前应超过阈值的时间是一件好事
@falkenbt ：我相信很多事情都可以表述为时间序列查询问题（例如 pings 示例）。 但你是对的，有些事情并不是真正的时间序列相关，这些超出了我们在这里尝试构建的范围。 我认为这没问题：我们希望提供在时间序列上配置和管理警报的最佳方式，并旨在与其他可能针对“misc 脚本”情况（例如 nagios、icinga、sensu、.. .) 至于诸如交付可靠性、升级等问题，您可以使用 pagerduty 等服务。
@activars & @falkenbt这是否符合您的期望，或者您认为可以具体改进什么？
@jemilsson谢谢！ 这正是我的看法：bosun 擅长警报，但不擅长可视化。 Grafana 擅长可视化和 UX，但没有警报。 我正在努力推动一种合作，我认为这种合作会随着时间的推移而增长

有没有人对在电子邮件等通知中发送什么样的上下文有任何想法？
至少，通知应包含您正在发出警报的数据的可视化，但恕我直言，它应该可以包含其他相关图表。 这里我们可以在生成通知内容时使用 grafana 的 png 渲染后端。 我也在考虑利用 grafana 的快照功能。 就像警报触发时一样，拍摄某个仪表板的快照以获取上下文。
并且可能该快照（html 页面）可以包含在电子邮件中，或者这可能有点过多的数据/复杂性。 无论如何，邮件客户端中也无法使用 javascript 功能（因此您将无法放大电子邮件中的图表）。 也许我们可以将电子邮件链接到托管的仪表板快照。

我喜欢 docker 的一般方法 - 包括电池，但可拆卸。 因此，恕我直言，可以替换的基本警报实现将是一个好方法。

将支持 influxdb 进行警报？ 还是只有石墨？

我想看到的一件事是分层警报树的想法。 被监控的方面太多了，独立的警报状态具有无法管理的基数。 使用层次结构树，我可以定义所有这些低级别警报，这些警报汇总到中级警报，然后汇总到高级......

因此，每个卷起的警报都会自动假定其下所有子项的严重性。 通过这种方式，我可以通过更低的分析表面积准确了解 [和管理] 系统健康状况。

这是我从前段时间写的旧文档中借用的示例。 是的，请对“Struts”这个词的使用嗤之以鼻。 老了好吗？ 这为一台服务器提供了一个非常简单的层次结构。

在某些时候，服务器经历了持续 75% 的 CPU 使用率，因此这会使这些警报进入警告状态：CPU-# --> CPU --> 主机/操作系统 --> 系统

如果真正应用自己，则可以通过一个指标关注整个数据中心。 （是的，不是真的，但这是一个思想练习）

为什么不使用石墨信标？ 我认为您可以将非常轻的石墨信标与 grafana 合并。

@felixbarny我喜欢这个术语。 我们很可能会采用这种措辞。
@JulienChampseix是的，标准处理程序将/将支持 influxdb
@nickman这很有趣。 它实际上符合我们心目中的最终目标，即能够创建非常高级的警报，其中可以包含/依赖于更细粒度的警报规则和信息。 bosun 已经这样做了，从长远来看，我们希望通过更加用户友好的界面来提供此功能，但我们必须从比这更简单的开始。
@amirhosseinrajabi看起来是一个很酷的项目，我认为将石墨信标变成通过 grafana UI 配置的警报的处理程序会很有意义。

@Dieterbe是否可以更新当前状态？ 用于警报系统
为了知道哪个系统是兼容的（graphite/influxdb）？
哪些订阅可用？ 哪种警报类型可用？
感谢您的更新。

我们目前正在对 UX/UI 进行原型设计。 所以我们离它可用还有很长的路要走。

嗨@Dieterbe

警报系统的进度是否有任何更新？

在 Grafana 中进行警报会很棒！ 期待这个功能。 现在有更新吗？

@mattttt你能提供更新你的 UX 工作吗？

是的，一点没错。 明天将上传一些屏幕/用户流。

我们需要警报：规则定义的 UI、规则定义的 API 和警报通知的 API。 会饶有兴趣地看这个话题。 我们有一个多租户系统，喜欢 Grafana UI 和后端。

是的，我也对看到这个新功能非常感兴趣和迫不及待！
非常感谢马特！ ;)

2015-08-27 6:49 GMT+02:00 andyl [email protected] ：

我们需要警报：规则定义的 UI、规则定义的 API 和 API
用于警报通知。 会饶有兴趣地看这个话题。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/grafana/grafana/issues/2209#issuecomment -135290295。

有很多项目在内部落实到位，但我不想忽略这个线程。

这是我一直在研究的面板模型之一。 这说明了随着时间的推移的历史健康状况，将状态合并到工具提示中，并使用面板配置中定义的现有阈值来配置警报。

在此示例中，这是针对具有多个系列的单个查询发出警报。 工具提示被扩展以显示悬停时的状态。

_几个悬而未决的小问题_：工具提示中应该包含多少有关警报通知的信息（如果有） - 或者应该在其他地方以更详细的视图访问这些信息？ 我现在相信后者，但值得大声询问。

配置、警报屏幕、用户流程正在缓慢地出现。 很多来。

@mattttt不错！

喜欢图表下方的绿线和红线！

这与正常运行时间计算有关，希望能够在某处将其视为数字。 所有查询和每个指标的总计。

关于工具提示，您是在谈论将鼠标悬停在线条上时出现的统计数据吗？

该死的@mattttt看起来棒极了。 我什至不会担心在工具提示中放置任何东西。 底部的阈值线和警报状态健康栏绰绰有余。

等它完成后就迫不及待地想看到它了！

我很高兴看到这一切进展顺利！

我们目前使用 Grafana+Bosun+OpenTSDB 作为我们的监控和警报堆栈。 我绝对同意拥有 Bosun 的力量和 Grafana 的出色用户体验会很棒。

以下是 Grafana 的配置 UX 优于 Bosun 的示例：

语境

我们的监控堆栈在多个团队及其服务之间共享。 根据项目规范将一组不同的服务部署到不同的集群/站点。 每个团队/服务都应对自己的仪表板/警报负责。

比较

使用 Grafana 的 HTTP API 团队可以在部署他们的服务时放置他们自己的仪表板。 Bosun 目前只有一个文件来存储配置； 这使得在不同团队和不同项目之间共享变得困难。

@mattttt @torkelo @Dieterbe关于发布警报片（或测试版）的任何想法？

回声^。 他们是为此而发布的 Beta 版还是 Alpha 版？ 我正在研究警报解决方案，但我希望在 grafana 中内置一些东西。 我可以提供很多测试反馈。

警报功能还有几个月的时间，我们仍在对 UI 进行原型设计并考虑不同的实现方式，但在接下来的 2 个月内进展应该会更快，所以我们会知道更多

@mattttt您是否打算使历史健康栏的颜色可配置？ 绿色和红色真的不适合色盲;)

关于警报：我对这是如何进行的很感兴趣。 一段时间以来，我们一直在收集和可视化数据，而警报是我们目前正在尝试解决的问题。 Grafana 可能在那里有一个不错的地方，尤其是因为可视化已经就位。 但我确实想知道：Grafana 应该在多大程度上更了解“实体”而不是用于警报的指标系列？ 除了基于指标的警报之外，我可以想象自己想要自动切换视觉状态更改（ping 或 http 检查失败）或手动（进行维护）在我的情况下将是服务器。

我很高兴看到 Grafana 中的警报在哪里，但是对于那些现在需要某些东西的人，有 nagios 插件，例如https://exchange.nagios.org/directory/Plugins/System-Metrics/Others/check_graphite_metric/details当超过阈值时可以触发警报。

@baaym

但我确实想知道：Grafana 应该在多大程度上更了解“实体”而不是用于警报的指标系列？ 除了基于指标的警报之外，我可以想象自己想要自动切换视觉状态更改（ping 或 http 检查失败）或手动（进行维护）在我的情况下将是服务器。

这是一个很好的问题，也是我们一直在谈论的问题。
我们想要在近期（也可能是长期）采用的解决方案是让 grafana 不知道这些更高级别的概念。 即，作为用户，您有权对指标系列设置警报，并且根据这些警报规则，将生成警报结果（可能包括系列名称中的属性或标签），然后您可以从中构建您喜欢的任何实体。 这是我们必须多考虑的事情，但例如

假设您按照movingAverage(cluster1.web-*.cpu.idle,10) < 20 -> warn的行设置了警报。 这将验证给定集群中所有 Web 服务器的阈值，并针对任何违规行为生成警报，例如movingAverage(cluster1.web-123.cpu.idle,10) is currently 3! 。
也许我们可以让您说“第一个字段是集群名称，第二个字段是主机名”等，以便警报可以包含更好的信息。
但关键是，警报 _outcome_ 包含确定哪个实体有问题所需的信息，但它不在 grafana 的范围内。 Grafana 将更多地是警报规则配置的来源，并且可以配置 Grafana 仪表板来加载注释和你有什么来可视化警报的状态，但它不会有高级概念的概念，例如主机或集群。 我认为这是可以在警报处理程序中处理的事情

@迪特贝

在构建警报功能时，有两种类型的用户/组织关注点：

• 初创公司，他们通常没有时间构建自己的警报解决方案。 一切都将依赖 Grafana 来提醒指标
• 建立了工程组织，他们在内部构建了现有的警报工具，业务规则的警报是基于其他细粒度警报信号构建的（Grafana 就是其中之一）。

Grafana 应该与现有的完善的操作实践一起工作，将其置于循环之外就是忽略警报的目标 - 清楚地了解关键业务实体的健康状况。 警报最好是集中的，以允许建立清晰的环境状态。 允许使用 grafana API（或任何其他解决方案）的高级用户将警报规则导出到其他系统是至关重要的。

当说到操作时，每个警报都应该选择包含一个文档/链接字段来解释警报的目的和历史行为。

@activars我想我同意所有这些。 在我看来，我们正在采取一种方法来促进将 grafana 插入环境的其余部分（主要是由于关注点分离，使用可插入处理程序）。 你认为提议的设计可以以任何方式改进吗？

我认为@deebs031提出了一个很好的观点，但尚未解决太多“为最终用户构建的应用程序需要提供用户定义的警报”。
恕我直言，graal 是基于自助服务指标的监控，在我的情况下，Grafana 是想要查看指标的人们的主要前端，让他们能够在同一个中为自己创建警报是有意义的 - 让我们面对它真棒 - UI。
我个人已经根据指标完成了 Sensu 警报，但与与 Grafana 集成的无缝程度相比，将其作为自助服务提供确实不是小菜一碟。 我还研究了Cabot，因为它具有可视化功能，但在构建时并未考虑自助服务，因此无法按原样使用。
我站在“做好一件事”方面，但我认为在基于指标的自助服务警报的特殊情况下，将该功能与指标可视化层配对很有意义：

• 用户已经熟悉 UI
• 用户已通过身份验证，因此她可以为自己或身份验证启用的任何权限架构创建警报
• 用户可以看到在创建这些基于指标的警报时通常非常有用的图表

我的 grafanacon 演示文稿中关于警报的幻灯片：
http://www.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015
如果没有上下文，它们有点难以理解，视频应该会在大约一周后上线，准备好后我会发布。

我们现在已经开始对实现警报模型/UI/定义/等的方法进行原型设计。 我们对主要工作流程有一个很好的了解，尽管我们仍然试图弄清楚与 3rd 方警报处理程序的集成应该是什么样的。
我们目前的想法是，您将能够使用 grafana 设置阈值/警报规则/定义通知，并可视化警报规则的历史和当前状态。

假设您想使用您选择的警报软件（bosun/cabot/sensu/nagios/...）
因此会有一个单独的工具通过其 http API 查询 grafana 以检索所有警报规则。 然后该工具可以更新您的 bosun/cabot/sensu/nagios/... 配置，以便您可以使用您选择的警报软件来运行和执行警报并发送通知。
但是我们希望能够正确地可视化当前和历史状态，因此您的警报程序需要能够调用脚本或 webhook 或其他东西来通知 grafana 新状态，或者 grafana 必须查询它。 （这看起来很恶心，因为大多数工具似乎都没有很好的 api）
这一切都有些复杂，但必须以这种方式来支持那些对他们来说能够使用他们选择的警报软件很重要的人，同时使用 grafana 来定义警报规则和可视化状态。

能够使用当前选择的警报工具对您来说重要吗？

我们想做的另一件事，也是我们自己编写一个简单的警报执行器，它查询 grafana api 以获取警报、安排并执行它们、执行通知（它将支持电子邮件、slack、pagerduty、自定义脚本和可能还有其他一些）并再次更新 grafana 中的状态。
这对我们来说很容易编写，对你来说很容易使用，而且我们可以有很好的互操作性。

内置警报执行器（见上文）是否足以处理您在 grafana 中设置的所有警报规则？

您还希望能够使用多个警报处理程序吗？ 哪一个 ？

@jaimegago阿门;)

对我来说，第二个似乎更好，因为您可以真正减少为使一切顺利运行而必须配置的东西的数量。 在我们当前的设置中，我们会这样做。

如果其他人不同意，就这么说;)

快速编辑：很棒的幻灯片。 如果最终产品看起来只有一半那么好，那就太棒了。

+1
我同意这种集成的内部通知处理程序是完美的！ 对于最常见的用例。

我会很高兴成为 Beta 测试 :) 并且幻灯片很棒！

我认为@Dieterbe的最后弄清楚了很多，但我想张贴这个快速图表来进一步澄清。

Grafana 中的警报实际上是两件事，自助服务警报配置（感谢@jaimegago ，我自己说得再好不过了）和处理程序本身。

我们将提供 Grafana 警报处理程序，但也会提供与您选择的警报软件集成的框架：

+1 用于建立一种与其他警报系统的桥梁（也许我们可以考虑实现一些通用警报插件系统:-)）

您也可以在“外部警报处理程序”部分添加Prometheus 。 第一个 Prometheus alertmanager 版本正在几家公司生产，目前正在全面重写。 SoundCloud 可能会使用 Grafana 来配置警报，但只有在将 Prometheus 警报管理器用作警报处理程序时才能确定。

@grobie ，很好的捕获，在原始评论中修复。

@mattttt @Dieterbe太棒了！ 看起来您正走在“包含电池但可拆卸”的道路上，恕我直言，这是两全其美的。 您是否已经考虑过如何将授权数据传递给警报处理程序？ 我在想一个这样的故事：
作为 Grafana 用户，我希望在（通过 Grafana 警报 UI 构建的某些条件）发生时通过 _email_ 和/或 _pagerduty_ 和/或 _foo_ 收到警报。
该用户应该只能向他授权的通知系统发送警报，这是自助服务的要求，需要以某种方式解决。 从 Grafana 2 开始，我们有一个 SQL 后端 + 用户身份验证/授权与 LDAP 集成，所以从发出警报的第一天起就拥有该功能似乎并不遥远？
使用 Sensu（这是我要插入的工具）通过处理程序传递警报目标（例如电子邮件地址）应该非常简单，不能说其他人。

大家好，
我很高兴看到这种负担得到推进，因为我喜欢自助服务警报配置方法。

就个人而言，我不需要特定的警报处理程序。 我想看到一个通用的 HTTP POST 处理程序，它会在发出警报后立即触发。 我认为大多数管理员可以快速构建一些能够接受 HTTP 的东西，然后做任何他们需要做的事情（将它发送到 nagios、riemann、younameit）。 所以我会很高兴有一个 HTTP 处理程序，它将有关警报的所有信息作为 JSON 数据发送。

谈到通过 grafana 发出警报，您是否打算添加诸如扑动检测之类的功能？ 或者这是外部监控系统应该处理的事情？

保持良好的工作伙计们！

干杯

我想看到一个通用的 HTTP POST 处理程序，它会在发出警报后立即触发。 我认为大多数管理员可以快速构建一些能够接受 HTTP 的东西，然后做任何他们需要做的事情（将它发送到 nagios、riemann、younameit）

因此，如果触发警报（例如“web123 的 CPU 处于空闲状态！，值 1 低于阈值 15”）并且我们对该数据进行了 http 发布，您将如何在 nagios 中处理它？ 你的意思是 nagios 会把它当作被动服务检查，然后 nagios 会发送通知？

谈到通过 grafana 发出警报，您是否打算添加诸如扑动检测之类的功能？ 或者这是外部监控系统应该处理的事情？

这也是我们需要更多思考的问题。 这可能会变得混乱，如果人们使用 pagerduty 或flapjack 之类的东西，那么他们可以使用它来聚合事件/抑制重复项，因此我们正在寻找是否可以避免在 grafana 处理程序中实现它，尽管我们可能不得不这样做。 还要注意，因为您将能够对任意指标查询表达式设置警报，所以您将有很大的能力在实际表达式中考虑过去的数据，因此您可以在表达式中创建更强大的信号不会经常改变状态。

因此，如果警报触发（例如“web123 的 CPU 处于空闲状态！，值 1 低于阈值 15”）并且我们对该数据进行了 >http 发布，您将如何在 nagios 中处理它？ 您的意思是 nagios 会将其作为 > 被动服务检查，然后 nagios 会发送通知？

的种类。 我实际上期待 grafana 警报摆脱 nagios。 使用 HTTP 处理程序，您需要为 nagios 配置被动检查，以便能够在那里提交结果。 但我希望 grafana 作为您可以配置警报的一个来源。 在我们的例子中，被允许添加警报的人是实际的系统管理员，他们也会在 nagios 中配置检查。

使用 http 处理程序 grafana 将拥有我们需要的一切：用于实时监控的仪表板、API、简单的警报配置和一个 http 处理程序，我们可以将警报转发到我们的内部通知系统。

干杯

虽然我能看出这个整合策略的逻辑，但我不禁觉得它有点矫枉过正。 据我了解（以及我可以在线程中读到的内容），大多数 Grafana 用户继续使用独立警报技术的唯一原因是 Grafana 没有提出这种技术。 因此，首先关注 Grafana Alerting 部分，并将其开发为通过 API 与堆栈的其余部分进行通信的组件，这样其他贡献者将能够模仿行为并创建特定的适配器稍后？

tl;dr：通过首先专注于构建自己的“电池”，Grafana 将拥有一个功能齐全的警报系统，该系统随后可以演变为与 3rd 方警报工具集成的服务。

小问题，如果这还没有得到解决。 传统的警报系统不能很好地扩展云基础设施，因为资源是非常动态的（配置和销毁）。 指标警报应支持诱人或分组功能（除了覆盖例外，有时工作负载不同）。 模板化或分组警报应该能够发现新的组集。

感谢更新！ 在我的用例中，Grafana 中的内置警报是我此时所需要的。 我一直在耐心不耐烦地等待 Grafana 警报。

正如我在 IRC 中承诺的那样，这是我们的用例：

我们有一个旧的 Rails 应用程序，它searches our logs用于patterns并且有一个
HTTP API 来回答是否某个pattern已经越过它是thresholds和
因此具有{OK,WARNING,CRITICAL} 。

Threshold可以是：

• 一个status的CRITICAL如果pattern存在于所有。
• 如果pattern被发现超过 X 次，则status是WARNING
  如果发现次数超过 Y 次，则status为CRITICAL 。
• 如果pattern小于 1 小时，则status为OK ，
  不到 3 小时status为WARNING ，否则status为
  CRITICAL 。

如果我正确理解了这个特性，Grafana 会支持这个用法
模式（当然是通过 Logstash 和 Elasticsearch）当这个特性和
Elasticsearch 数据源实现了吗？

@Dieterbe @mattttt你的幻灯片和模型看起来非常棒！ 这确实是一个游戏规则改变者。
对我来说，内部 Grafana 警报处理程序最适合我们的需求。
原因：

• 自助服务 - 非常重要。 我们的用户大声而明确地表示，他们希望自己在 Grafana 内部创建端到端的警报。
• 统一工作流程 - 我想尽量减少移动部件而不是增加它们。 正如@Dieterbe指出的那样，第 3 方警报处理程序至少需要 4 个步骤，而内部警报处理程序只需要 1 个步骤（如果您需要为每个阈值定义通知方法，则可能需要 2 个步骤？ - 从演示文稿中不确定）。
• 紧密集成且不依赖于第 3 方警报基础设施。

几个问题：

• 什么是频率检查阈值？
• 它如何处理太快而无法取回数据的轮询频率？ 记录、警报和排队或丢弃？
• 对于扩展，担心 Grafana 可能无法跟上绝对数量的检查、快速频率，尤其是我们可能需要添加/扩展 Grafana 服务器以支持内部警报的数据源之间的延迟。 我知道这是因为我们现在需要几个 3rd 方警报处理程序实例。 在这种情况下，我们如何能够在 Grafana 服务器集群之间无缝地分配或排队阈值检查，特别是如果检查来自同一个数据源？ 从用户体验来看，我希望用户通过负载均衡的 Grafana 服务器集群无缝创建阈值，而无需用户前往特定的“分配”Grafana 实例进行特定检查。
• 对于通知，这是否支持某种插件架构，以便可以轻松开发和集成通知？ 一般来说，我们需要一些可以执行 HTTP POST 的东西。 这在 PagerDuty、xMatters、VictorOps、Opsgenie 等中最常见。每一个都需要稍微不同的格式、身份验证等。正如前面在这个线程中提到的，也许一个通用的 HTTP POST 处理程序可以发送到自定义 HTTP 服务能够做任何你想做的事情。 或者，自定义脚本功能也应该起作用。
• 我假设可以通过 API 设置、检索和获取阈值？ 我认为这会有所帮助

我认为能够将警报集成到现有警报系统中是理想的。 已经处理了一些棘手和丑陋的问题，例如前面提到的襟翼检测，从一开始就重新发明一切似乎是浪费。 我不想看到这被隐藏在功能蠕变的重压之下。

但我不认为这真的需要与所有这些警报处理程序紧密集成。 一个好的、有据可查的 api 应该允许熟悉这些系统的人轻松集成。 所以带有“grafana api -> handler”的幻灯片对我来说很有吸引力。

斯科特

大家好 - 我迟到了这个讨论，但我在这个主题上有一些专业知识，而且我是试图解决警报问题的工具之一的首席开发人员。 我们的工具StatsAgg可与 bosun 等程序相媲美。 StatsAgg 旨在涵盖灵活的警报、警报暂停和通知，并且在这一点上非常成熟/稳定（尽管 API 尚未准备好）。

无论如何，关于警报主题的一些想法：

• 通过单个指标发出警报很糟糕。 我在一家管理数千台服务器的公司工作，必须为每个指标系列的“可用磁盘空间 %”创建/配置/管理单独的警报在逻辑上是不可行的。 企业监控工具通常将多个指标系列与正则表达式（或只是通配符表达式）联系在一起。 StatsAgg 建立在相同的前提下； 多个指标系列捆绑在一起，然后该指标组通过单个“警报”对其执行警报阈值检查。 在规模上，这种能力是必要的。
• 如果有人接受我之前的断言，即警报工具不应针对单个指标发出警报，那么该工具必须具有一种机制来快速获取符合条件的指标和指标值的列表。 许多工具依赖于查询数据存储来获取指标和指标值列表，坦率地说，这个解决方案在规模上不能很好地工作。 就其性质而言，警报逻辑需要经常运行（每 X 秒，或随着每个新的合格数据点的出现）。 数据存储（graphite、opentsdb、influxdb 等）并不是为了处理“给我符合此模式的当前指标列表”和“向我显示这些 Y 指标的最后 X 值”的持续查询而构建的。 他们要么没有合适的 API/查询语言，要么根本无法处理负载。 明确地说，当数据存储中有 10,000,000 个可用指标系列时，我指的是针对 10,000 个指标系列运行警报逻辑的规模。 这不是每个人的用例，但它是我公司的用例。
• 我发现通过流处理解决问题是解决我上一个要点所提出问题的唯一可行方法。 这就是 StatsAgg 被构建为位于数据存储前面的原因。 警报逻辑可以在不接触数据存储的情况下针对指标运行，并且指标只会传递到数据存储。 这种方法的主要想法是 1) 新创建的警报不能/不会使用旧的/存档的指标值进行警报评估 2) 如果流处理程序 (ex-StatsAgg) 崩溃，则数据点不会成功3) 警报评估所需的指标值存储在内存中，这可能是服务器稳定性问题。 4) 流处理程序必须能够解构和重建传入的指标（InfluxDB 在过去一年中并不容易......）。 即使有这些自负，这个解决方案对我的公司来说非常有效，而且规模非常大。 有时，我们有 200,000 多个实时指标系列，平均每秒 30,000 多个传入指标，评估数千个指标系列的数百个警报，以及运行 StatsAgg 的服务器几乎没有出汗。 一直以来，根本不会查询数据存储。

这些是我想提到的主要内容。 警报还有许多其他重要方面（通知、暂停等），但是一旦解决了核心问题的架构，这些解决方案就很容易实现。 我意识到我们的需求规模与普通用户不一样，但希望你们都能理解这个观点。

我想建议启动一个可以将数据发送到 Alerta 的通知处理程序： https :

Alerta 有一个非常健全的 REST API 用于接收通知。

我更喜欢只使用精益 grafana 实现！
我认为在每个人都在典型的梦幻般的 Grafana UX 中体验过此功能后，它值得重新评估。

人们将希望集成许多复杂的案例和/或自定义后端系统。 你可以在这个线程上看到很多，大部分是开源的，但也有很多商业产品！ 不要打扰单个处理程序 - 这将是一个整体，您将始终处于捕获模式

我强烈建议只实现两种类型的处理程序。 一个绝对是 HTTP POST，它将是最通用和最灵活的工具。 另一种是自定义脚本，因此用户可以实现与他们选择的特定工具的集成。 插件模型还不错，但它强制使用有限制的特定插件语言。 外部脚本更好——只要你将脚本的所有细节都传递给脚本，脚本可以用任何语言编写——shell 脚本、Python 等。

我和@007reader 在一起

我同意。 只要提供通用的集成方法，自定义实现就可以是单独的项目或部署。

例如，最近的 CloudWatch 版本很不错，但是我很想将它作为一个单独的项目，只将选定的指标同步到替代存储。 它将为我们提供完整的保留，而不仅仅是 2 周的数据。

嘿大家，
我的 grafanacon 演示视频在线！
它位于https://www.youtube.com/watch?v=C_H2ew8e5OM
我认为它会清除很多，但正如你所看到的。 集成的细节仍有待弄清楚，这也是很多人想要讨论的话题。 （虽然时间有限，我请人们在这里继续对话，以便每个人都可以参与）

@simmel是的。 您将使用 ES 查询并为此设置规则。
@activars重新分组和发现，我认为其中很多将取决于您的数据源，但如果您使用石墨或 ES 之类的东西，我知道他们非常擅长“自动发现”以前看不见的指标/系列，则应该解决最常见的要求/documents 匹配给定表达式（带通配符）用于石墨或查询（用于 ES）。 不确定其他来源。 你关于需要对规则应用例外的评论是一个棘手的问题，我们可能需要在某个时候解决这个问题，但我认为可以等到事情变得更加清晰和稳定。 也许我们可以以某种方式避免需要它。
@mgravlin频率将是规则中的一个设置，用于处理太慢的数据源，目前还不确定。 但不要这样做;-)。 也依赖于处理程序。 横向扩展部署应该是可能的，也包括处理程序，所以我们很确定我们会看看。 但可能不是首次发布的优先事项。 是的，通知插件将是关键，我们将确保您可以使用您想要/需要的东西。 重新 API：是的 :)
@sknolin如果我理解正确的话，在您看来，grafana 会执行警报调度、执行、触发通知挂钩等，即使在使用其他系统（如 nagios/bosun）时也是如此。 那么外部系统 (nagios/bosun/...) 的作用究竟是什么。 这似乎也与@Crapworks所说的相似。
@jds86930 StatsAgg 看起来很有趣。 我认为这里与 grafana 的集成也是有意义的。 我认为流处理是一种有效的方法，可以替代重复查询。 但后者更容易上手，而且我认为总的来说更简单。 但两者都应该得到支持。 所以是的，在 grafana 中，您将能够设置与一系列数据相匹配的模式/查询，并有可能在新系列/数据上线时覆盖它。 不过，在我们看来，您只需利用您的数据源具有的任何功能（例如，Graphite 非常擅长它的通配符、glob 表达式等，以及 elasticsearch 丰富的数据和查询模型），或者如果有人会使用 grafana+StatsAgg，他们可以只需使用 StatsAgg 来解决这个问题。 你是说 grafana 本身应该在这里做任何具体的事情吗？ 我认为如果您的数据源不够快，请解决数据源问题。 获得更快的东西，它具有缓存指标元数据，可能是前面的内存服务器或流处理。 但无论哪种方式，就 Grafana 而言，我能想到的变化不大？
@blysik是的看起来很有趣。 这么多警报工具，我们应该与之集成:) 明确地说，您是否喜欢管理警报规则并以迄今为止呈现的方式在 grafana 中将它们可视化的想法，但您想使用 alerta 来处理通知? alerta 是您查看警报状态的主要位置（这似乎是一件合理的事情），但要确保我完全了解您如何看待集成。

@ 007reader，@shanielh，@activars仅仅是明确的，通过一个通用的HTTP发布或脚本，这将是目标这种集成。 告诉外部系统“有一个新规则，这是查询、阈值、频率等。现在请执行它”？ 或者 grafana 是执行规则然后用新状态更新外部系统的东西吗？

@blysik是的看起来很有趣。 这么多警报工具，我们应该与之集成:) 明确地说，您是否喜欢管理警报规则并以迄今为止呈现的方式在 grafana 中将它们可视化的想法，但您想使用 alerta 来处理通知? alerta 是您查看警报状态的主要位置（这似乎是一件合理的事情），但要确保我完全了解您如何看待集成。

正确的。 Alerta 正在成为我们的通知中心。 各种各样的东西向它发送警报。 例如：自定义脚本、Cabot、Zenoss、vCenter 和 Grafana。 这为操作人员提供了一个查看所有警报的地方。 然后这是将通知发送给值班工程师的唯一地方。

@sknolin https://github.com/sknolin如果我理解正确的话，在你的
看来，grafana 会做警报调度、执行、触发
通知钩子等，即使在使用另一个系统时
nagios/水手长。 那么外部系统的作用究竟是什么
(nagios/bosun/...) . 这似乎也类似于@Crapworks
https://github.com/Crapworks正在谈论。

我想我没有很好地解释。 那不是我想要的，grafana 不是
做所有这些事情。 @Crapworks （
服务检查，我只是使用主动轮询。

所以我想要的只是一个 api，我可以在其中读取 Grafana 警报状态。
外部系统做其他一切。

这并不意味着如果它没有以某种方式发展成为一名伟大的将军
警报工具我不会使用它。 正是我现在要做的。

斯科特

@斯诺林

所以我想要的只是一个 api，我可以在其中读取 Grafana 警报状态。

如何在 grafana 中更新该状态？ 什么进程将在 grafana 中执行警报和更新状态？

每次轮询 grafana 时都会更新警报状态，并使用某种缓存间隔来处理轮询它的多个系统。

我认为这仍然需要 grafana 为警报做逻辑并呈现它。 所以考虑一下，不，我不需要任何类型的警报。

如果我能够在图形面板上检索指标的当前值，我想我可以做任何需要的警报。 例如，当我们从几个计数器指标的总和中得出一个比率并将其绘制成图表时，最好通过监控系统轮询当前值。 也许现在这完全可行，而我只是迟钝了。

斯科特

@Dieterbe后者：

grafana 是执行规则然后用新状态更新外部系统的东西

@Dieterbe我同意使用数据源的本机查询语法轮询数据源（Graphite、OpenTSDB 等）是最简单/最简单的，并且可能是将某种形式的警报本地发送到 Grafana 的最快方法。 对于很多人来说，这种解决方案将满足他们的需求，我认为这是最初实施 Grafana 的最佳解决方案（在我看来）。 我的主要观点是，警报可配置性和性能存在上限，使用“轮询数据源”模型将难以克服。

就 Grafana 可用于长期警报解决方案的方向而言，我可以看到一些选择：

• 与数据存储维护人员合作，为警报用例构建更快/更好的专用 API。 我不喜欢这个选项，因为其中许多项目的进展速度较慢（几个月到几年），而且他们可能不接受部分/全部增强请求。 他们可能还想用他们的数据存储的本地语言编写代码，这些语言并不总是快速的语言（例如 Python 中的 Graphite）。
• 为每个数据存储构建流处理/缓存层作为单独的raintank 项目。 我认为这最终会比试图哄骗各种数据存储维护人员为其项目构建解决方案产生更好的结果。 这也将允许您继续扩展您已经在做的工作（使用现有的数据存储查询机制）。 您甚至可以将自己的自定义 API 构建到流处理/缓存层中，这可以简化 Grafana 对数据存储的查询语法。
• 坚持使用您正在努力的本机解决方案并使其运行良好。 StatsAgg、bosun 等 3rd 方工具将适用于要求更高/专业/复杂的用例。 将 Grafana 与这些工具集成肯定会给用户带来额外的好处，但它会给 Grafana 增加非平凡的复杂性。 也就是说，看起来您最终可能会这样做（我现在正在查看您演示文稿第 35 张幻灯片上的“警报后端”）。 我个人愿意在 StatsAgg 中实现一组 Grafana 友好的 API； 我们只需要弄清楚 API 是什么并起草一些 API 协议文档。 如果您想讨论其中任何一个，请随时给我发消息/给我发电子邮件。

大家好，

@Dieterbe我刚看了你的演讲，这些东西看起来很棒。 我非常感谢您尝试使用大量社区意见以“正确”的方式构建警报系统！ 谢谢！

我还想更清楚地说明我的观点，因为我认为我想说的并不明显。 我_不_要求 grafana 知道任何其他监控系统，如 Nagios、Icinga、Bosun 等。我实际上只需要这个：

• 您在演示文稿中展示的出色用户界面或完成后的任何外观
• 一个完全可配置的通用 HTTP POST 处理程序（就像这里的其他一些人也建议的那样）（稍后我会给你一个例子）

我正在考虑的事件流：

• 你在 grafana 中可视化你的数据
• 您在 grafana 中添加警报阈值
• 一旦超过阈值，就会触发 HTTP POST 处理程序
• 从那时起，grafanas 的工作就完成了

就像提到的@mgravlin和@007reader一样，大多数通知和警报服务使用 HTTP POST，需要不同类型的数据。 所以我能想到的最通用的事情是让用户定义他们的 POST 数据和标题，这样你就可以使用不同的模板通过一个处理程序为多个系统提供数据。 伪代码示例：

"notificator": {
    "httppost": {
        "data": {
            "host": "$hostname",
            "alert": "$alertname",
            "state": "$state"
        },
        "header": {
            "content-type": "application/json"
        }
    }
}

为用户提供足够的变量来使用，将足够强大以提供大量后端。

同样，使用这种处理程序，任何具有一些编码知识的系统管理员都可以构建自己的 http post 接收器并转换他喜欢的方式，例如，馈送不理解 http post 的后端。

由于这是无状态的，它也可以扩展。 只需在后端/api/任何东西前面放置一个负载均衡器，就可以了。

至少，这将解决我的大部分/几乎所有问题；)

干杯

感谢您构建此功能。 它有大概的发布日期吗？

torkelo 在 IRC 上说大约 3 个月。
如果我正确理解他，那是一个非常粗略的估计，应该这样对待。

我很高兴能够使用 grafana 进行警报。 我认为这是阻止 grafana 成为最终监控工具的一个功能。

如果您有早期的 alpha/beta 版本，我很乐意测试并提供生产数据的早期反馈。

++

我 2 哈哈

+1

Em seg，2015 年 11 月 16 日 às 21:03，京东通知@github.com
escreveu：

如果您有早期的 alpha/beta 版本，我很乐意测试并尽早提供
生产数据反馈。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/grafana/grafana/issues/2209#issuecomment -157202686。

+1
如果您有早期的 alpha/beta 版本，我很乐意测试并提供生产数据的早期反馈。

+1 我 2

2015-11-21 14:44 GMT-02:00 混沌通知@github.com：

+1
如果您有早期的 alpha/beta 版本，我很乐意测试并尽早提供
生产数据反馈。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/grafana/grafana/issues/2209#issuecomment -158661279。

+1

很高兴看到所有 +1，但 FWIW 并不真正需要它们。 我们已经知道这是最热切期待的新功能，一旦我们取得切实进展，代码将出现在任何人都可以使用的单独分支中。 顺便说一句，我们还吸引了更多的人在 grafana 上全职工作，所以请大家继续关注:)

是的，有 484 人在“关注”这个问题。 每次您“+1”它时，484 人都会收到电子邮件通知。 只需订阅通知，它就会表明您对这个问题感兴趣。

+1 >; 磷

在 2015-11-30 星期一 10:33:52 -0800，Vadim Chekan 写道：

是的，有 484 人在“关注”这个问题。 每次您“+1”它时，484 人都会收到电子邮件通知。

Sory，我知道你们在这方面非常努力。 首次发布有时间线吗？

我很高兴能够配置警报指标和阈值（通过 Web 界面或 API）以及检查这些指标并使用 JSON 执行 HTTP POST 或在标准输出中使用 JSON 调用脚本的 Grafana cronjob/守护程序。 对于个人来说，编写一个简单的 Python 脚本将这些信息传递给 Pagerduty、Slack、IRC、SMS、电子邮件或其他任何东西是_极其_简单的。

虽然我非常感谢它的便利性，但我认为与第三方工具紧密集成并不是 Grafana 的工作，我宁愿早点看到极简主义的实现，也不愿看到后来充实的实现。

我完全同意@anlutro 。 请提供一些简单的开始。 对我来说最有趣的是让人们自己设置简单的警报（自助服务）。 Grafana 不应该尝试替换现有的警报/升级解决方案。

我也同意@anlutro 。 但不是仅仅提供一个简单的 api，而是让警报部分能够处理与 api 交互的自定义​​插件。 这样，基本包可以包括电子邮件、pagerduty 和其他一些，然后社区可以根据需要添加到其中。 类似于现在处理 Logstash 插件的方式。

+1

有关于警报系统的消息吗？ 有什么估计吗？

+1

+1
值得一提的是，在 collectd 警报上的命中和滞后机制是一个需要考虑的概念。

您是否考虑过高级警报功能，例如异常检测、相关性检测、根本原因检测等？

+1。 警报作为插件子系统 - 这将是最灵活的解决方案。 如果有很多项目可以在后端做得更好，则无需在 grafana 中添加这么多功能。

@Dieterbe @torkelo对此进行非常粗略的“猜测”会很棒。 就我个人而言，我一直坚持，因为在我的案例中，基于指标的自助服务警报是一个非常需要的功能，我相信 Grafana 是适合它的用户前端。 问题是，现在已经 6 个月了，并且有很长一段时间没有 ETA 更新，甚至没有你们中的一个人发表评论，所以我开始有“我只是不得不破解一些东西”的反效果想法。 ..如果我能知道是再过 6 个月而不是再过几个星期，我就可以做出更明智的决定。

谢谢！

+1
2016 年 1 月 18 日晚上 9:54，“Jaime Gago”通知@ github.com 写道：

@Dieterbe https://github.com/Dieterbe @torkelo
https://github.com/torkelo有一个非常粗糙的
对此“猜测”。 就我个人而言，自从指标以来我一直坚持
在我的情况下，基于自助服务警报是一个非常需要的功能，我
确信 Grafana 是适合它的用户前端。 问题是，现在
已经 6 个月了，没有任何 ETA 更新，甚至没有评论
你已经有一段时间了，所以我开始有“我将不得不
破解某些东西”适得其反的想法......如果我能知道它是否
将是另一个 6 个月而不是几个星期我可以赚很多
更明智的决定。

谢谢！

—
直接回复此邮件或在 GitHub 上查看
https://github.com/grafana/grafana/issues/2209#issuecomment -172722684。

+1

+1

@jaimegago真的很抱歉没有在这里更新我们的进展或在这个问题上缺乏进展。 我们以为我们会有时间花在这上面，但它总是被推动，因为有更高优先级的东西出现了。

早在 9 月份，我就开始研究 Elasticsearch 数据源支持，这成为了以数据源为中心的 2.5 版本的基础，之后自 v1 以来 Grafana 中评分最高的问题是表格面板，尤其是在 Elasticsearch 支持之后，我觉得这是一个带有表格的小版本面板比警报更重要，因此成为 2.6 的基础。

最近我们有很多用户和公司想要更多地与 Grafana 集成，这促使我们致力于改进插件 api 和功能，这导致此问题再次推迟。 我真的很抱歉我们没有很好地传达这一点。 我们一直有开始 SOON 的雄心，但是 SOON 一次又一次地被推动:(

但还有希望！ 我们扩大了专注于Grafana的全职团队，12 月

@torkelo感谢您的更新； 我不能说我很高兴，但至少新的我们知道我们的立场。

剩下的一个问题是 2.x 是否会获得更多点发布，或者 3.x 是否会成为下一个版本。 ;)

@RichiH关于另一个点发布，不确定，但 3.0 之前的另一个点发布很可能会在 2 月发布。

@torkelo 非常感谢您抽出时间提供详细的更新。

也许这已经在路线图上，如果没有，请考虑在通知中添加“POST”。
所以我们可以将警报发送到不同的系统来处理它们，比如 kafak

+1 用于 SNMP 通知！

+1 我认为这是 Grafana 最大的缺失功能，使其成为可行的（和一流的）生产监控工具。

+1

任何管理员（@Dieterbe？）都可以锁定非合作者对此问题的评论？ 所以我们只会得到关于功能改进的有趣内容，而不是那些无用的+1...

如果您不知道此功能，这里是临时 GitHub 文档的

谢谢：心：

@Mayeu呃，作为“非合作者”之一，对这个问题做出了超过 +1 的贡献，在其他地方，我不认为将这个问题锁定给合作者是要走的路。 只需在您的电子邮件上创建一个智能过滤器 ;-)。

我还认为 +1 有一个目的，显示对此（和其他地方）的兴趣的数量和范围。
也许缺少的是 UI 中的 +1 按钮，它可以扮演相同的角色，但没有向所有订阅者发送所有通知......所以对@github 的功能请求。

我们正在偏离主题，这是我第一次也是最后一次写这篇文章。

任何对此问题感兴趣的人都应该在右上角订阅； 它会让您随时了解情况，并且您不会向所有人发送电子邮件。

关于防止 +1 累积的投票系统，请参阅https://github.com/dear-github/dear-github - 27 天过时且 GitHub 没有反应。

+1

有关于这方面的消息吗？

我认为目前还没有关于这个问题的任何消息。 但是 Grafana 下一个版本的一个好处是：

Grafana 将能够处理自定义应用程序/插件。 然后我们可以编写我们自己的自定义警报插件/应用程序并将它们导入 Grafana。 在等待大型警报功能时，编写这些小应用程序/插件将是一个快速的胜利。

我喜欢在与可视化相同的位置配置警报的想法。 https://www.youtube.com/watch?v=C_H2ew8e5OM上的精彩模拟，但是否有发布日期？

不错的视频，谢谢！

一些反馈。

我对简单的线性阈值和高级自定义查询的想法感到满意

最有帮助的通知程序：

• exec - 可以使用 ssh 或 sendmail 之类的东西
• webhooks - 用户可以站起一个 webcgi 来拿起 web-hooks 来做事......
• 电子邮件 - 使用通知数据的 json 转储发送一封简单的电子邮件。
• 插件...不是真的需要

api 来拉警报状态......感觉是个坏主意，
但是，以基本 json 格式提取警报配置的 api 可能会很好。
此 json 转储可以转换为其他系统可能会发现有助于转换的内容。

不确定这是否令人不悦.. 无法在任何地方找到捐赠链接，但需要什么样的贡献才能在本月底将其纳入 v3 .. 我们真的可以使用此功能分配但我们的资源被绑 ATM

+1

+1

这是我们在 Work Market 非常需要的功能。

是否推出了特色提醒？

不
在星期四，2016年2月25日在下午11时13 kskaran94 [email protected]写道：

是否推出了特色提醒？

—
直接回复此邮件或在 GitHub 上查看
https://github.com/grafana/grafana/issues/2209#issuecomment -189143056。

假设警报功能将在夏季发布是否安全？

_悬念加剧_
2016 年 2 月 26 日上午 10:23，“Ian Ha” [email protected]写道：

假设警报功能将在
夏天？

—
直接回复此邮件或在 GitHub 上查看
https://github.com/grafana/grafana/issues/2209#issuecomment -189320869。

有关于这方面的消息吗？

+1

+1 已经拥有它会很好，人们已经等待了一整年甚至更多。

:+1: 我喜欢。 感谢您的视频和演示，@Dieterbe。 是否可供测试/早期采用者使用？

@torkelo你宣布

我们希望此功能成为 Grafana 3.0 的标题功能

但是查看 3.0 未发布的分支变更日志 (1) 没有提到警报，我应该开始哭泣还是计划仍然具有警报 3.0 标题功能？

(1) https://github.com/grafana/grafana/blob/master/CHANGELOG.md

我们决定为 grafana 3 制定插件系统，以便我们可以发布 grafana 3，然后开始处理警报，而不是不必要地推迟 grafana 3。

@Dieterbe不能说我很高兴，但这确实有道理。 显而易见的后续行动是是否有任何 ETA-ish 警报； 如果它是 3.1 的已确认和已提交的功能。

另外，作为一种变通方法， http: //alerta.io/ 做了我希望 Grafana 做的部分工作； 等待此功能的人可能想尝试一下。

插件有规范吗？ 可能会很好地在
社区处理警报以配合版本 3 的发布？

贝丝
2016 年 3 月 16 日上午 8:44，“理查德·哈特曼”通知@ github.com
写道：

@Dieterbe https://github.com/Dieterbe不能说我很高兴，但那
确实有道理。 显而易见的后续行动是是否有任何 ETA-ish
警觉； 如果它是 3.1 的已确认和已提交的功能。

—
您收到此消息是因为您订阅了此线程。
直接回复此邮件或在 GitHub 上查看
https://github.com/grafana/grafana/issues/2209#issuecomment -197214149

@Dieterbe我认为能够在客户端创建通知也很好。 例如带有仪表板的公共监视器上的语音消息，因此您无需查看仪表板即可知道存在一些麻烦。 就像 Zabbix 声音警报一样。 为此，我编写了简单的JavaScript 代码来扫描特定的仪表板，如果出现问题，它会使用Web Speech API通知我。 现在它对我很有用。

使用kapacitor作为警报的后端怎么样，他们的脚本语言很简单而且非常强大？ 或者如何支持多个警报后端，并对其进行抽象。

现在 3.0 出来了，我真的很高兴希望在 grafana 中有警报。 警报将使 grafana 成为终极工具。

嗨@Dieterbe ，

正如我从这个版本https://github.com/raintank/grafana （你说它有警报包）看到的那样，repo 现在已被弃用，它说所有新的开发都在https://github 中进行。 com/raintank/worldping-api。 这让我想知道这个警报功能是否仍在开发中，或者已经被计划和更改以用于其他用途（例如

嗨@minhdanh ，我们的目标一直是将警报“正确地”添加到grafana，而不仅仅是在raintank-specific fork中进行黑客攻击，这是您所指的repo（无论如何它只涵盖了一个非常狭窄的域，尽管一旦我们开始在该 repo 拥有的调度程序/执行程序上工作，重用其中的一些代码可能是有意义的）。 所以这就是为什么我们一直在努力使 Grafana 能够在即将发布的 grafana 3 版本中插入。 （因此，允许我们将自己的需求转移到一个独立的应用程序中，这就是您所指的 worldping-api）。
很明显，作为第一步，我们应该构建 UI 来管理 Grafana 仪表板和面板中的规则，并通过某种 api 公开它们，以便插件可以使用它们来执行它们。 这将是启动警报的最快方法。 “电池包括调度程序/执行程序”随后会出现，并且可能会重用您提到的一些代码。

无论如何，我们将首先在 grafana 中进行管理 UI 并通过 API 公开规则，然后我们将从那里获取它。

谢谢@dieterbe。

与往常一样，有一个粗略的时间表问题，即使它只是“不
在 X”之前。

我确实理解这个问题有多烦人，因此在
第二部分。 我希望你明白等待对方是多么令人沮丧
可以一边围栏。

理查德

手机发送； 请原谅我的简短。

大家好，

我希望raintank在这里说它没问题，但我们最近订购了raintank将近一个月的专用编码时间来处理警报。 那么为什么这不会导致最终的警报功能，我们应该很快就会看到一些东西来为 grafana 中的警报奠定基础。 如果其他公司会效仿我们的方法，或者个人也将一些现金投入到这件事上，那应该会更快地思考和优先考虑。

@flyersa ，非常感谢您的贡献！ 我们怎样才能放下现金呢？

乔恩

大家好，

我知道很多人都对这个功能感到焦虑，我很高兴地报告团队已经开始研究它。 我们在Grafana 3.0 测试版公告博客中解释了延迟的原因

我们将分两个阶段发布警报。 第一阶段将允许用户在 Grafana UI 中定义他们的警报和阈值。 Grafana 还将通过 HTTP API 将这些警报定义公开给第三方调度程序和警报后端。 在第二阶段，我们将提供后端服务来使用这些定义并根据这些定义采取行动，以获得完全集成的解决方案。

我们希望第一阶段能在几周内发布。

我们正在努力平衡盈利能力和速度，我们非常感谢@flyersa 等客户的商业支持。 如果其他人希望支持此功能的开发和一般 Grafana，请考虑购买支持计划。 它将帮助我们开发 100% 开源的优秀软件。

在推出该功能时，我们将与所有受支持的客户密切合作，并确保它很好地满足他们的需求。

-raj dutt | 首席执行官/联合创始人| 雨水箱

嗨@nopzor1200 ，

感谢您的更新。 您是否估计何时可以使用警报？

显然，不可能在特定日期进行提交，但非常感谢时间框架（数周、数月等）。

10 倍！

嗨，伙计们，对此感到非常兴奋。 这是我设想如何使用它，如果有人可以检查它是否是标准/支持的模式，我将不胜感激。

• 我要监控的每个主机都会发出“检查”。 “检查”包括：
  
  
  
  • 主机名
  
  
  • 时间戳
  
  
  • 状态，0=OK、1=WARN 或 2=CRITICAL
  
  
• 这些检查可以来自各种任意来源（shell 脚本 + cron、statsd/collectd、Nagios 检查等），并且会在 Elasticsearch 中累积。 相同的检查在不同的主机上可能有不同的配置，但这对 Grafana 来说是不透明的。
• 我将配置 Grafana 连接到 Elasticsearch 并在来自任何主机的任何检查的状态值 >= 1 时发出警报。
• 如果有新主机加入集群，Grafana 中不需要配置； Grafana 只会看到状态 1 或 2 中的任何数据点，而不管它来自哪里。
• 如果主机突然死亡并停止传输检查，我们需要检测到这一点。 为了解决这个问题，当主机启动时，它会将主检查注册为“ON”状态，并且只有在正常停止时该值才会变为“OFF”。 通过这种方式，我可以查找在过去 X 秒内未发出检查的任何“ON”主机。
• 一般来说，我不会对 Graphana 中的时间序列数据使用基于阈值的警报。 换句话说，我不会在 Grafana 本身内进行“检查 CPU 使用率是否 > 80%”，而是，Grafana 将收到“CPU 使用率状态”检查（0 / 1 / 2）并在 1 或 2 状态下发出警报。

嘿@johnnyshields ，

这看起来不错，但是为什么不使用标准级别定义而不是“0=OK、1=WARN 或 2=CRITICAL”呢？ syslog 使用的几乎是这些事情的事实上的标准：

• 值 -> 严重性
• 0 -> 紧急情况
• 1 -> 警报
• 2 -> 严重
• 3 -> 错误
• 4 -> 警告
• 5 -> 通知
• 6 -> 信息
• 7 -> 调试

并有一个（全局？）配置来告诉 grafana 将哪个级别视为警报阈值。

鉴于此，我将在您的帖子中添加以下更改：

• 当来自任何主机的任何检查具有状态值 >= CONFIGURABLE_ALERT_LEVEL 时发出警报。
• Grafana 只会看到状态 >= CONFIGURABLE_ALERT_LEVEL 的任何数据点，无论它来自哪里
• 如果相应配置，Grafana 将收到“CPU 使用状态”检查级别和警报。

@brunorey谢谢，有道理！

日志级别和状态是两个不同的东西。 你可以有一个 6-Informational 日志消息，但是怎么会有 6-Information 状态呢？

OK、WARN 和 CRITICAL 状态都很好，对于那些只关心 OK 和 CRITICAL 的人来说可能太过分了。 添加更多状态会增加混乱，除非它们的含义被普遍理解，我建议上限为 3。

关于仅在“CPU 状态 >= WARN”与“CPU > 80%”上发出警报，我认为有些人希望将他们的 3 级状态保留在时间序列数据库中，以便他们可以看到状态如何随时间变化。 这些人将根据他们的状态时间序列数据发出警报。 其他人会希望在原始 CPU 值超过 80% 时发出警报。 关键是，提醒关闭时间序列数据是唯一需要的。

我选择整数日志状态比率而不是直接使用时间序列数据的原因是我希望能够控制每个节点上被视为警报的内容。

例如，工作服务器的 CPU 通常接近 100%，这不是问题——我希望它们在所有内核上全速启动。 但是 Web 服务器的 CPU 不应超过 20%。 因此，如果我要制造一个 > 80% 的通用 CPU，它对于网络来说太高了，而对工人来说太低了。 （这只是一种情况）。

@johnnyshields我不明白你为什么不在时间序列数据上使用基于阈值的警报，IMO 这就是向 grafana/graphite 添加警报的真正强大（唯一？）价值所在。 你的“支票”风格的东西听起来更适合像 monit 这样简单的东西——我在这里错过了什么吗？

如上所述，我有许多具有不同角色的服务器，每个服务器的阈值也不同。 最终的问题是阈值是在 Grafana 中还是在服务器本身上定义的，我认为在我的情况下服务器更容易。

此外，一些检查是“是或否”，例如进程 X 是否正在运行，是否对端口 Y 进行 ping 响应等。

明白了。 有时确定这些状态很简单 (>80%)，有时又很复杂。 当它们很复杂时，一些代码将确定级别并将级别发送到 TS 数据库中。 这是一种常见的做法，将数据转换为信息。 我的观点是，这与警觉感没有区别。

如果您的警报需要复杂的规则，请不要将规则构建到警报引擎中，而是将规则构建到 TS 管道中以创建新的 TS 数据，然后发出警报。

简化警报系统。 隐藏 TS 管道中的复杂性。

与基于规则的警报系统相比，在管道中创建新的 TS 数据的好处在于，它使人们设置和获取警报的警报保持直观和简单。 有一个可视化可以通过电子邮件或短信发送，仅显示收到警报的内容 - 即使它是一个简单的状态图，他们看到状态在 20 分钟前从 WARN 变为 CRITICAL。

我认为，如果您想在每个主机/角色的基础上控制哪些被认为是值得警惕的，那么您就可以为被认为是 WARN 和被认为是 CRIT 的内容添加逻辑，因为您正在为严重性添加 8 层粒度警报。

几乎所有其他现代警报系统似乎都集中在 OK/WARN/CRIT 上，尽管部分原因可能是希望与 Nagios 检查兼容，但我认为只想保持简单的想法更为重要。 如果 Grafana 也这样做，与其他警报/监控服务的集成将更容易。 例如，在我的情况下，我可能最终将 Grafana 警报提供给 Sensu，然后它会发送电子邮件、slack 消息或其他任何内容。 Sensu 只有 OK/WARN/CRIT，所以任何更多的粒度都会被浪费。

同意日志警报级别似乎过度设计。 好的，警告，在大多数情况下，暴击可能会完成这项工作。

在警报阈值上，我希望能够进行基于标准偏差的警报。 它们在实践中最有用。

在2016年5月12日，在8:49，RWhar [email protected]写道：

@johnnyshields我不明白你为什么不在时间序列数据上使用基于阈值的警报，IMO 这就是向 grafana/graphite 添加警报的真正强大（唯一？）价值所在。 你的“支票”风格的东西听起来更适合像 monit 这样简单的东西——我在这里错过了什么吗？

—
您收到此消息是因为您发表了评论。
直接回复此邮件或在 GitHub 上查看

就我个人而言，我一直期待使用现有的 TS 数据作为输入进行警报，尤其是在指定的时间范围内（通过 StatsD）从应用程序指标中汇总统计数据。

此外，最好有一个选项，其中可以在阈值和超过阈值的指定间隔触发警报 - 例如设置“rpl_delay”警报阈值 200 int 50 - 将在 200、250、300 等没有需要手动指定额外的阈值级别。

@johnnyshields我不明白 1=WARN 或 2=CRITICAL 之间的区别。 警报被触发或未触发。 您要么高于 80%，要么不高于 80%。 所以我只看到两个状态 0 和 1。
如果有更智能的警报，您可以检测到连续 5 分钟高于 80%，这样您就不会收到临时峰值的警报。 更高级的是移动阈值之类的东西，例如，您监控网站流量，您会获得 X 量的流量，然后缓慢增加，例如每月 1%，但突然之间，您的流量激增了 10%小时。 您还希望能够监控相反的流量突然下降。 类似于https://github.com/etsy/skyline 的东西，因为 Skyline 已不复存在。

伙计们，我在这里的帖子不是关于要使用的警报状态的确切数量——我更笼统地问“Grafana 会支持枚举状态作为警报用例吗？”

由于在最佳数量上存在分歧（Nagios 使用 3，syslog 使用 7，有些人喜欢 2，等等）Grafana 应该支持任意数量的状态。

只是重申我之前说过的话，我认为每个警报触发 1 或未触发 0 应该只有两种状态。如果您想知道是否接近阈值，请为较低的值设置一个额外的阈值。

WARN 与 CRITICAL 的原因是你采取的行动是不同的。 通常在 WARN 上通知一组人和动作，在 CRITICAL 上通知另一组/不同的动作。

这是一个非常有价值的区别，我不想放弃 0-1 系统。

@lorenwest如果您想对不同的阈值进行不同的检查，请为该单独的组设置一个额外的阈值。
所以每个阈值要么是 0，要么是 1。
例如，您希望以这种方式设置警报的另一个原因是，当阈值大于 70% 时您需要电子邮件，而阈值超过 80% 时需要一个页面。 就像您想要不同的组一样。 WARN 与 CRITICAL 有太多的歧义。

@doanerock这是有道理的。 允许对任何一个 TS 指标或事件发出任意数量的警报可实现最大的灵活性。 由于没有针对多个级别的多个操作，这简化了警报的定义。

所以：

• 指标可以有任意数量的状态（包括十进制/时间序列值）
• 指标可以有多个警报操作附加到同一指标
• 每个警报都是布尔值 true 或 false - 它要么被触发，要么不被触发。

举个例子：

• 我有一个特定的指标，其值为 0 = OK，1 = WARN，2 = CRITICAL
• 我配置了 3 个警报：
  
  
  
  • 如果 value = 1，则在我的仪表板中显示黄色标志
  
  
  • 如果 value = 2，则在我的仪表板中显示红旗
  
  
  • 如果值 >= 1，给我发一封电子邮件
  
  

大家好，

我不知道询问这个话题是否合适，但我会尝试任何有关即将推出的 Grafana 警报模块的方法。
在我们的组织中，我们有所有的安全警报传感器为 Logstash/Elasticsearch 提供事件，我们使用Yelp/elastalert执行具有以下标准的特定模式的警报：

"Match where there are X events in Y time" (frequency type)
"Match when the rate of events increases or decreases" (spike type)
"Match when a certain field matches a blacklist/whitelist" (blacklist and whitelist type)
"Match on any event matching a given filter" (any type)
"Match when a field has two different values within some time" (change type)

此外，当检测到警报标准时，我们会执行带有参数的外部 python 脚本，这些参数将参数从 Elastalert 传递给脚本，其中包含源/目标 IP 字段、事件和时间戳字段等信息，我们的 NAC 系统会从那里开始处理。

现在查看 Grafana Upcoming Alerting 模块并以 Elasticsearch 作为数据源，我想知道 Grafan Alerting 模块是否可以与 Elastalert 合作并最终替换为上述信息？
请指教

谢谢

我知道 Grafana 团队正在努力工作，这个线程很长，但我想指出 Kapacitor 刚刚合并了一个功能，将大大简化前端警报配置应用程序的开发：influxdata/kapacitor#577

据我了解，Grafana 方面的目标是使警报后端可插入（与 Grafana 支持多个 TSDB 存储的方式相同），但我想提一下，希望在 Grafana 的警报功能发布时 Kapacitor 获得一流的支持。 它看起来非常合适，InfluxDB + Grafana 也是如此。

@thom-nic 感谢您的提示 Kapacitor 正是我正在寻找的...

黎曼也很伟大，也很强大。 telegraf -> riemann (alerting) -> influxdb <- grafana

我们正在 alerting_definitions 分支取得进展。

我们现在有一个简单的警报规则模型，您可以在 UI 中和通过 HTTP api 定义它。 您可以通过 HTTP api 获取规则、规则更改、规则状态。 简单的警报规则调度和查询执行以及规则执行也开始结合在一起。

现在对我来说一个很大的问号是当前的警报模型是否过于简单和死胡同。 我的意思是，将来扩展警报规则模型需要进行大量更改。

当前规则模型：

description
query: #A  (referencing a query in the metrics tab)
aggregation: avg
timerange:  3600   (seconds from now to look back when fetching data)
frequency: 60  (how often to execute alert rule query and evaluation rule)
critLevel: 80
warnLevel: 50

这个存储模型在 UI 和实际的数据库表中都有表示。 我担心这个简单的规则模型没有充分利用时间序列数据。 您不能指定动态阈值（其中阈值本身是查询的结果）。 当然这个
可以稍后添加，但需要非常不同的规则模型和执行引擎。

所以我的想法是废弃这个简单的模型，并提出一个新的更复杂和动态的模型，以后可以支持不同时间范围的多个查询。

简单查询：

"alert": {
   "name": "CPU usage last 5min above 90%",
   "frequency": "1m",      
   "expr": "query(#A, 5m, now, avg)",
   "operator": ">",
   "critLevel": 90,
  },

// 现在使用基于传递值的动态阈值的警报

"alert": {
   "name": "CPU usage last 5m is 20% higher compared to last 24hours avg",
   "frequency": "1m",
   "expr": "query(#A, 5m, now, avg) => percentDiff() => query(#A, 1d, now, avg)",
   "operator": ">",
   "critLevel": 20,
  },

现在你可能会质疑这一点，说我们正在这里重新发明 Graphite，像这样的表达应该由 TSDB 处理。 但是没有 TSDB 支持对不同时间范围的查询进行计算（timeShift 只移动相同的时间跨度）。 动态阈值的一些问题是如何对其进行可视化。 它还可以使警报规则与面板中实际可视化的内容更加分离。

我非常不确定 GAL（Grafana 警报语言）应该是什么样子。 应该只是表达式链，其中每个部分都可以是返回一个或多个系列的查询（每个系列聚合到一个点），然后是一个可选的减法或百分比函数，可以与另一个查询进行比较。 整个表达式产生一个值，然后可以与运算符和暴击/警告级别一起使用以获得警报状态。

或者表达式应该包含运算符和级别？

其他选项将使用完整的编程语言并执行以下操作：

expr: "
let last5mAvg = query(#A, 5m, now, avg)
let last24hAvg = query(#A, 1d, now, avg)

return percentDiff(last5minAvg, last24Avg)
"

@托克洛：

1. 您是否将其构建为独立组件？ 最终，您正在为 Influxdb ** 构建一个类似于
2. 同样，grafana 是否可以选择不使用上面的信号引擎，而是从第三方源（例如 Nagios 插件）接收 0/1/2 信号，其中许多已经存在？

** = 授予 Kapicator 使用时间序列流处理，而您是基于轮询的引擎，但它仍会发出信号。

感谢您征求意见。

我的观点是让 grafana 警报保持简单，而简化的最佳衡量标准是可视化。 如果您无法将警报可视化为现有 TS 图形上的一条线，那就太复杂了。

将复杂性留给 TS 图。 如果警报有更大的需求，则根据这些需求构建另一组 TS 数据，并将警报放置在该数据的图形上。

如果您只有一个指导原则，则需要对警报进行简单的可视化。

另一个问题是“我应该配置多少警报”？ 此主题已在此线程上讨论过，我认为一旦您开始将多个警报放入一个警报（警告、错误、高警告、低错误等），您就会开始失去灵活性。 警告和错误是不同的东西——它们有不同的级别，不同的人关心它们，它们有不同的通知方法。

保持警报简单，让人们将多个警报放在一个图表上。

我认为 #3677（时间序列查询结果的通用转换）在这里会非常方便。 使用这些 TSDB 独立函数，您可以创建一个复杂的“警报图”，您可以在其中使用简单的固定值阈值进行警告、暴击等。

那时只需要简单的警报规则模型即可。 然后在图形的创建和组合中“隐藏”了复杂性。

我完全赞成保持简单。 我不是开发人员，我更喜欢轻触式开发操作，我希望能够将我的 Grafana/Graphite 平台交给我的管理员团队来管理。 在这种情况下，与现有警报构建器类似的警报构建器将更容易使用。 如果它引入了大量新指令，只要仍然可以以与当前图形查询相同的方式构建规则，就不必太担心，它会很容易掌握。

tl;博士一门全新的语言可能是矫枉过正而且太复杂了。 使用 mouse=good 构建规则。

除了构建一种全新的语言之外，我认为这主要是现有警报平台（如 Kapacitor、Reimann 和 Bosun）的前端，类似于 Grafana 提供前端来组合 InfluxDB 查询的方式。 例如，繁重的工作由第三方警报系统完成，而 Grafana 提供 UI。 也许事实并非如此？

IIRC，Grafana 希望采用“包含电池但可拆卸”的方式。 即它应该与包含的警报引擎独立工作，但也应该可以插入现有平台。

我会说它需要附带几个内置方法 - 电子邮件（提供 SMTP 主机）和 WebAPI/Webhook。 然后其余的可以带有插件，例如集成到 PagerDuty 中。

@felixbarny您能描述一下可插入现有平台的意思吗？ 当然，警报通知将与许多现有的警报工具集成。 但是对于其他系统来处理警报规则的调度和执行可能会很棘手，这是可能的，只需从 Grafana HTTP API 读取规则即可。 但是它需要大量代码来处理规则调度和执行。 但我们当然会提供一个选项，只在 Grafana 中定义规则，并让另一个系统不断读取规则并执行它们

@GriffReborn你在不同的层面上思考。 我提到的现有警报后端_已经_支持输出，例如 SMTP、PagerDuty 等：
https://docs.influxdata.com/kapacitor/v0.13//introduction/getting_started/#a -real-world-example
http://riemann.io/api/riemann.pagerduty.html

这些产品_已经_能够很好地完成复杂的动态警报。 他们没有的是一个很好的视觉前端，用于配置和管理警报，直观地识别哪些警报是活动的，等等。我想要的是一个前端 UI，它基本上将配置推送到例如你的（Grafana 支持的）警报选择系统然后实际上完成所有工作。

@thom-nic 我同意。 主要重点应该是构建可以使用现有警报信息提要（“提要不可知”）的警报仪表板。 制作 Grafana 赞助的轻量级信号处理引擎（最好是独立的）应该是次要的问题。

@johnnyshields制作显示来自现有警报后端的信息的新面板很容易，任何人都可以这样做。 我们试图做的是让 Grafana 用户可以轻松地在他们在图表/singlestat 面板中定义的指标查询上定义警报规则。 然后在 grafana 后端有一个警报引擎，用于调度、执行和评估这些规则、更新警报状态、触发通知等。

我也认为简单的模型应该足够了，并且也会尽快实现期待已久的功能。 grafana 是用于指标的，基本警报应该足够了。

@torkelo说实话，我对像 bosun 这样的警报平台不是很熟悉，我不知道正确的集成具体是什么样子的。 我指的是@Dieterbe所说的，例如在他的 Grafanacon 演讲中： http ://de.slideshare.net/Dieterbe/alerting-in-grafana-grafanacon-2015#50

@felixbarny好吧，这也是我们计划做的。 为其他警报后端提供 API 以读取 Grafana 中定义的规则。 但是我们不会提供从 Grafana 读取警报规则并将它们转换到另一个规则执行引擎的桥梁。

所以我们现在的一个想法是定义这样的简单规则

但也能够有动态阈值并与另一个查询或相同的查询进行比较，但不同的时间范围和聚合。

另一个复杂的“预测”查询。 使用查询来获取趋势线，然后及时预测该趋势线并对此发出警报。

似乎是两全其美的。 喜欢这个主意！ “评估反对”功能是 Grafana 的一部分还是特定于 TSDB？

@felixbarny它们是 Grafana 警报规则模型的一部分，将由 Grafana 警报规则评估引擎处理。

您能否将多个规则附加到单个图形上？ 我喜欢一个规则中警告/关键级别的简单性，并且一些图表同时具有高阈值和低阈值，这可能需要一个警报中的多个级别，或者一个图表上的多个警报。

虽然我喜欢复杂的规则功能，但这一切都可以通过构建不同的图并使用简单的规则在该图上发出警报来实现。 将复杂性排除在警报系统之外的好处是导致规则触发的环境历史记录保存在 TSDB 中。

这使您可以将警报可视化为图表上的一条简单的水平线，并查看该规则将如何（或确实）随着时间的推移而触发。

对于普通人来说，它保持简单的警报，对于每个人来说都足够复杂，并且对于那些以视觉方式理解事物的人来说是可以访问的。

@lorenwest是的，我们会保持简单，并且每个面板只允许一个警报规则。 但是规则可以使用返回许多系列的查询，这基本上会将规则拆分为多个（因此，如果查询返回每个服务器的系列，您可以使用单个规则来检查每个服务器）。

虽然我喜欢复杂的规则功能，但这一切都可以通过构建不同的图并使用简单的规则在该图上发出警报来实现。

不确定你在这里的意思。 另一个图根本无法解决您希望在不同时间范围内对与自身相比的查询发出警报的情况，与完全与另一个查询相比（也许另一个查询是从数据库中获取动态阈值的另一个数据源）。 这种情况无法在 TSDB 中解决，也无法通过将规则拆分为两个单独面板中的两个规则来解决。

但主要目标是解决简单的案例并使之简单直观，但我们也希望，至少在以后，支持一些更复杂的警报规则，这些规则真正利用您正在处理 TSDB 数据的事实以及事实不同的查询可以针对不同的数据源

我认为@lorenwest的观点是，警报规则是简单的阈值，规则适用于在图表中可视化的数据。 因此，如果您覆盖阈值，您可以清楚地看到过去根据当前阈值触发警报的位置

对于更复杂的警报模型，不再有阈值会导致警报的可见指标。

坚持使用简单模型，您可以实现许多复杂的监控要求，前提是数据源提供了该功能。 对于“比较的百分比变化”，您可以构建一个石墨查询（不同的图表），将当天与前一天进行比较，然后设置简单的阈值。 创建警报当然要复杂得多，但它确实有效。

很高兴我们在同一页面@torkelo。 这与原始帖子中的描述相符。

我不喜欢创建一个全新的警报平台来与 Grafana 相关联。 我希望 Grafana 警报能够取代 NewRelic，但具有 Grafana 带来的强大功能。 能够在我的一个图表达到阈值时触发警报（无论是电子邮件还是 API）......那是金。 改变生活的东西。

即使是简单的阈值警报也是一个很好的简单解决方案。

如果您遵循这一规则，您将成为黄金：

切勿允许无法通过叠加在面板上来可视化的警报。

如果你无法想象它，那就太复杂了。 构建一个体现这种复杂性的图表，并在该图表上发出警报。 这迫使我们构建体现这种复杂性（一件好事）的可视化，同时让警报构建者（和消费者）很容易看到他们正在进入什么。

@woodsaj我同意我们希望鼓励您提醒的内容与您所看到的内容之间的联系，这不是我们曾经讨论过要放弃的内容。 试图集思广益的是单个查询静态阈值能走多远，它们对于 Grafana Alerting 的 v2 或 v3 是否足够好？ 并引发关于单一查询和静态阈值可能存在的警报规则类型限制的讨论。

目前 TSDB 在您可以执行哪种嵌套查询方面非常不灵活（例如，将一系列与其自身进行比较）。 Graphite 是唯一一种支持嵌套查询的。 但即使是 Graphite 也无法比较针对不同时间窗口的两个查询（时移只是移动相同的窗口，而不是大小不同的时间窗口）。 但是我越是想这个，我就越同意大部分问题都可以在 TSDB 查询中解决，因为它足够强大。

提出此讨论的主要原因是集思广益如何对规则建模，组成规则的组件是什么，它包含哪些抽象（查询、时间窗口、聚合、级别等）。 我们怎么可能在 v2 或更多功能丰富的警报查询中支持动态阈值，以预测未来的趋势。 模型和规则评估引擎需要如何改变？

关于“警报应该映射到面板” - 我认为这可能是一个有用的选项，但即使对于 v1.0 也是一个糟糕的设计约束。

我认为警报更棘手的方面之一是范围，一旦你开始谈论可视化，问题就会变得明显。

我认为范围是警报覆盖的系统的表面积/深度作为范围。 因此，例如，您的警报可能有以下范围：

• 服务（应用程序指标）
• 组成服务的整个集群
• 集群中的单个节点
• 集群中的主机/进程
• 进程/应用程序子系统（中间件指标）
• 主机子系统（即磁盘、cpu）（系统指标）

我不相信关于第一层应该警告的“正确”单一答案。 有时它取决于团队、服务的重要性、通用基础设施（即云与硬件、集群与单体）等......因此，给定分层范围，警报层次结构似乎很好。 但我认为定义这些层次结构通常是不可维护的。 这需要大量的工作和变化，而且在现实世界的系统中，通常存在无法生成漂亮树的关系。 谷歌的 SRE 图书攻击：

"""
谷歌 SRE 在复杂的依赖层次结构中只取得了有限的成功。 我们很少使用诸如“如果我知道数据库很慢，则警告数据库缓慢；否则，警告网站通常很慢”之类的规则。 依赖依赖的规则通常与我们系统中非常稳定的部分有关，例如我们用于将用户流量从数据中心排出的系统。 例如，“如果数据中心已耗尽，则不要就其延迟向我发出警报”是一种常见的数据中心警报规则。 Google 很少有团队维护复杂的依赖层次结构，因为我们的基础架构具有稳定的持续重构速度。
"""

与范围相关的还有警报类型（即发送电子邮件与记录它/显示在仪表板上供某人在早上巡视时处理）

因此，对于 Grafana，我的警报可能映射到：

• 面板
• 一组面板
• 仪表盘
• 一组仪表板（我想会有深入研究）

有时我希望这些警报发送通知，有时我希望它们只是 Grafana 中某个范围内某个地方的视觉指示器（即越过阈值，或作为注释标记的状态更改）。 对于不同的公司，甚至公司内的不同团体/服务，情况会有所不同。

@kylebrandt在 Grafana 中使用警报的整个想法是将其与面板和可视化联系起来。 您可以在其中使用图表和面板来可视化具有不同范围（如服务、集群、单个主机）的指标，并且通过这些图表和面板，您可以在任何级别或范围内发出警报。

不知道如何将警报链接到面板和可以可视化的东西将停止定义不同级别的警报。 当然，您将为每个警报指定应该使用哪些通知。

@torkelo警报的决定将始终归结为（真/假）布尔值。 可能有不同的级别（警告、暴击等...）甚至模糊逻辑，但最终它是一个布尔决定。 在单个面板中单独绘制该布尔值并不总是有帮助的。

因此， $metric > $threshold是最基本的警报，当然，如果指标超过阈值，它就会返回 true。 这非常适合面板（可视化指标并可视化面板内的阈值）。 但是，为了消除警报噪音，在大多数情况下，范围和条件往往会超出这个范围（当我们开始研究 Bosun 时，我认为这些情况将是少数，如果你想控制噪音）。 所以你可能会说：

在以下情况下发出警报：

• CPU 在 X 分钟内高于 80%
• 作业 A 没有运行（我们知道会提高 CPU 并且我们不在乎）并且作业 A 没有运行超过一个小时
• 在过去的 24 小时内，Dieter 喝了超过 3 杯星巴克（因为当他喝更多时，他会做一些愚蠢的事情来提高 CPU，我们不想提醒这些）

因此，当有多个条件时，仅将警报可视化（真/假）并没有那么有用。 我们需要可视化每个条件（然后可能甚至更多的支持信息）。

将所有这些条件变成一个新的指标目前对可视化并没有真正的帮助，因为它只是真/假，而您真正需要看到的是所有底层信息。 因此，我们所拥有的不是可视化度量+阈值，而是可视化可能处于不同尺度的度量+阈值。

所以在这种情况下，是的，警报 _can_ 映射到单个面板，但是根据可视化和警报，在很多情况下这并不是人们真正想要的。 我希望组成警报的每个布尔项都有一个面板，以查看哪些项被绊倒了 - 但为了避免警报疲劳，我只需要一个关于所有条件组合的通知。

似乎某种具有简单布尔逻辑的警报木匠可能会使这变得容易。

alert1:
  select: CPU is above 80% for X minutes
  output: null
alert2:
  select: Job A is not running
  output: null
alert3:
  select: Job A has being running for more than an hour
  output: send alert
alert4:
  select: Dieter has had more than 3 cups of starbucks in the last 24 hours
  output: null

(alert joiner does simple true/false logic and perhaps can graph it.)
alert5:
  database: alerts
  select: alert1 & alert2 &!alert4
  output: send alert

@torkelo我从 Github 拉取 alerting_definitions 分支并根据说明构建它。 但不幸的是，我在图表面板中看不到任何“警报”选项卡（如上所示）。
此外，我在“服务器管理”的“服务器设置”中找到了“警报：启用=假”。 这会影响警报功能吗？ 我应该使用任何构建或运行时标志吗？
请指教。

我尝试了最新的代码（ebada26b85d8410142c2942ef7ba78b17e88313c），启用了警报并获得了用户界面。

但是有很多错误

EROR[06-17|14:38:23] Failed to extract alerts from dashboard  logger=alerting.extractor error="missing query.query"
EROR[06-17|14:38:23] Failed to save alerts                    logger=context userId=1 orgId=1 uname=admin error="Failed to extract alerts from dashboard"

我在 Proyy 和直接模式下尝试使用 InfluxDB 数据源。

这是预料之中的事情吗？

是的，它还没有准备好进行测试。

好的，很高兴知道。

我会不时跟踪更新。
等待这个分支合并到 master 中可能会更好，这样就可以使用了吗？

是的，我们希望在 7 月中旬左右合并它以掌握它

你有这方面的进展更新吗？
你还要打七月中旬吗？
尽快在生产中使用此功能真的会很有帮助！

即使是仅带有电子邮件提醒功能的轻型版本也很棒！
更新您的进度会很棒（我需要在实施自定义警报系统或依赖 Grafana 之间做出选择，我绝对更喜欢第二个选项！）。
谢谢你们

冬天来了，警报也来了:)

2016 年 7 月 12 日星期二凌晨 1:41，c-val [email protected]写道：

即使是仅带有电子邮件提醒功能的轻型版本也很棒！
更新您的进度会很棒（我需要在
实施自定义警报系统或依赖 Grafana，我绝对
更喜欢第二个选项！）。
谢谢你们

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/grafana/grafana/issues/2209#issuecomment -231975390，
或静音线程
https://github.com/notifications/unsubscribe/AAY0-eQ6jCI8a-k_U05xbcfFcYuGy4YVks5qU1NDgaJpZM4FJUTl
.

迪帕克

我会认为这是一个“业务需求”，并建议在“企业架构”级别对其进行评估。 通过应用_一些_用于企业软件架构的实践和模式，您将能够通过敏捷建模传达您的想法，这反过来又促进了利益相关者和开发团队的更高质量的理解。

在我们开始谈论技术和架构秘诀之前，我们至少需要就以下几点达成一致：

1. 我们从“业务流程管理 (BPM)”的角度考虑我们的功能； 和
2. 我们使用“业务流程建模语言 (BPML)”，因此我们可以使用 UML 在同一位置开始对需求和实现进行建模。
3. 我们使用企业级规程定义我们的架构。

现在是有趣的部分！ 拥有在全球范围内进行监测的丰富经验，我建议我们考虑以下几点：

• 不理会grafana，它是表现层！ 如果您想添加一个用于建模和定义生成警报的规则的工作流，那是可以的，但就这样吧。 毕竟，这就是面板和插件实现的原因吗？
• 将数据留在注定的位置。 打电话回家的指标应该被视为一等公民，并且持续存储其价值是首要任务。 无论是在cache、documentdb、tsdb，还是sql server中，都没有关系。 隐含了容错......当然，为架构做出了正确的“技术选择”）。
• 为了让我们设置可用性 + 可扩展性，我们需要使用专门为此设计的正确框架：满足面向服务的架构（“SOA”）。 在非常高的层次上，我们可以使用消息队列协议通过“AMQP”协议传输和接收事件和消息。 暂时忘记 REST 和 HTTP 吧。 使用像RabbitMQ或ZeroMQ这样的消息队列服务器，我们有一个分布式、容错、高可用的通信管道，数据的发布者/发送者和工作人员/接收者都可以使用它来处理它。 这就是“企业服务总线”。 （查看这个解释 ZeroMQ 的
• 使用专门为不同的、未链接的复合数据模型创建的查询语言。 通过使用“图形数据库”和“ SparQL ”查询接口：

SPARQL 允许用户针对可以松散地称为“键值”数据或更具体地说，遵循 W3C 的 RDF 规范的数据编写查询。 因此，整个数据库是一组“主语-谓语-宾语”三元组。 这类似于某些 NoSQL 数据库使用术语“文档-键-值”，例如 MongoDB。
[..]
因此，SPARQL 为数据提供了一整套分析查询操作，例如 JOIN、SORT、AGGREGATE，其模式本质上是数据的一部分，而不需要单独的模式定义。 然而，模式信息（本体）通常在外部提供，以允许以明确的方式连接不同的数据集。 此外，SPARQL 为可以被认为是图和图的数据提供了特定的图遍历语法。
..
https://en.wikipedia.org/wiki/SPARQL

请记住，Grafana 给我们的 Nagios 从未做过的事情归结为单点故障：缺乏可扩展性。 正如您所说，Grafana 是“快速的”，但您没有考虑到您仅存储和处理时间序列数据这一事实——而不是元数据层！ 我们需要 SparQL 的语义和 Elasticache + 图形数据库引擎的强大功能。

这听起来可能很复杂......它很容易变得比这两个页面更复杂，但我让你免于多年的蛮力、试验和错误，并消除了噪音（即：企业架构有 30 种设计模式，12 种用于uml 等等，我们只需要讨论 3 就可以解决这个问题——目前）

这应该会让齿轮转动.. 我需要睡一觉（拉了一夜），我将在第 2 部分工作。请随时在 Skype 上 ping 我

在此期间的一些款待：

• 我使用 SOA 创建的示例参考架构。
• Microsoft Azure Service Fabric：构建和运行永远在线、可扩展的分布式应用程序。

@talbaror理想情况下，您将使用像 PIX 防火墙这样的代理来捕获 NAC 的日志消息，并让它们通过 rsyslogd 或事件处理服务器使用的任何协议简单地发送/重播。

如果您没有事件处理服务设置，您可以使用Snort - Network Intrusion Detector的规则处理。 如果您需要帮助，请联系我 .. 我在一家安全即服务公司工作了 4 年；)

你能像banshee一样集成异常检测吗？
带有视觉标记和警报。

@torkelo请在发货时间表上给我们一个市场标记？

@johnnyshields我现在每天都在做这件事。 这是一件棘手的事情，并且真的希望获得正确的基础，以便警报系统可以发展并在未来变得更加丰富。 我正在使用的当前模型看起来非常好，将在下周发布基于新条件的警报规则模型的更新。

如果事情进展顺利，希望在 2 周内将其合并到 master 并使其可用（在功能切换之后）。 我们还没有确定下一版 Grafana 的日期，要么是 9 月发布 3.2 版本，要么是 10 月底发布更大的 4.0 版本。

@torkelo希望我们尽快收到警报。 等待它。
将 grafana 用于 kubernetes。

对于已经拥有 statsd/graphite/grafana 并且正在等待 Grafana 警报系统准备好发出第一次警报的其他人，我找到了一个很好的替代方案，可以同时使用，Seyren： https :

它可以轻松地与 PagerDuty 集成，您只需复制 Grafana 仪表板中已有的图形目标，用于指定警告和错误阈值的警报。

看起来该团队在警报功能方面取得了很大进展。 我相信“只做一件事，但要做好”的哲学。 不太确定将整个警报逻辑放在 Grafana 中是否是最好的主意。 无论如何，我只是写了一个小节点 js 守护进程“flapjack-grafana-receiver”来将 grafana 事件发布到flapjack。我可能会开源它。有人感兴趣吗？

https://github.com/Charles546/flapjack-grafana-receiver

进度更新！

自 4 月以来，至少有一个人一直在全职从事警报工作，由于多次重写，进展没有我们希望的那么快。 尽管我们的目标是初始版本的基本警报功能，但我们认为获得正确的基本警报规则模型很重要，这样我们就可以在未来版本中扩展警报规则定义和警报规则评估引擎，而无需进行大修。

从非常简单的警报开始的目标使我们陷入了一些感觉不对的死胡同，并且需要进行一些大的重写。 但是我们现在回到了正轨，并在我们更满意的基于条件的规则模型上取得了良好的进展。

规则定义

新的警报规则模型由一个或多个条件组成。 条件可以是不同的类型。 现在只有一种查询类型。 但是我们稍后可以添加诸如Time of day或Day of week ，或者更有趣的是Other alert （因此您可以将另一个警报规则的状态包含为条件）。

查询条件由查询和时间范围组成，reducer 将获取查询返回的每个系列返回的所有数据点，并将其缩减为单个值以用于阈值比较。 减速器将来也可以是“预测”，它对数据进行线性回归并预测未来值。

查询条件的评估部分可以是大于、小于、介于等。您将能够拖动图中的手柄来设置阈值。

基于条件的模型提供了许多令人兴奋的可能性，可以在未来使警报规则更加强大，而无需对引擎进行全面检修，而且查询条件具有这些可插拔组件，允许扩展（带有参数的减速器和带有参数的评估器）。

通知

这一周过去了，我们一直在处理通知，事情开始好起来了！

我们有电子邮件、网络钩子和松弛通知类型。 松弛通知看起来很不错:)

想帮忙？

您已经可以测试并提供反馈，代码位于警报分支中，您还需要在配置文件中启用它。

[alerting]
enabled = true

合并到主

我们非常接近将其合并到 master 并继续那里的工作。 我曾希望在我的暑假（刚刚过去 1 周）之前这样做，但在合并到 master 之前我仍然想做一些小的 SQL 模式更改。 合并到 master 将在 8 月 19 日之前发生，我保证:) 在那之后，警报将在最新的 4.0 夜间构建中出现，因此您可以轻松地测试和报告错误和反馈。

剩下什么？

有许多我们想要的 Beta 版本缺少的功能。

• 更多减速器和更换减速器的能力（现在仅平均）
• 电子邮件通知看起来像废话
• 锁定 webhook 的架构
• 警报列表页面的设计
• 查看警报历史记录
• 以图表上的注释的形式查看警报历史记录
• 警报调度程序和引擎稳定性
• 警报调度程序改进以分散负载（因此警报不会同时执行）
• 警报调度程序集群

我真的很抱歉这个功能需要这么长时间。

@torkelo请有能力在测试版中将机器置于维护模式一段时间。

@torkelo感谢您的更新。 据我所知，这是为了在 Grafana 中提供警报。 您是否仍在遵循https://github.com/grafana/grafana/issues/2209#issuecomment -149351263 中列出的模块化课程？

还要感谢在这方面工作的隐藏精灵。 我怀疑@Dieterbe ，但我不知道。

@RichiH我们不确定这将如何运作，我们试图弄清楚如何做一个像该评论中那样的系统，但不确定它将如何运作。 我们现在专注于强大的开箱即用警报体验，随着时间的推移会变得更好。 具有现有警报处理程序的用户可能会禁用 Grafana 中的警报执行程序，并让 Grafana 将需要评估的警报发送到另一个系统。 不过，要实现这种集成，需要在第三方系统上进行大量工作。

@torkelo我的想法是一样的，这就是我决定问的原因。

就个人而言，我关心 Prometheus 的警报，但会欣赏与 Grafana 的良好视觉集成。 我不太关心在哪里定义规则，只要它们由 Prometheus 存储和执行即可。

@bergquist正如您将参加 promcon，坐下来讨论可能的方法可能是有道理的。 如果您愿意，我会向 Prometheus 开发人员询问什么时间最合适。 在清理之前和/或之后的晚上，可能有也可能没有一些安静的时间坐下来； 如果你愿意，我可以让你知道。

你好@torkelo - 这看起来很棒。

我刚刚拉了你的分支，当我测试 ElasticSearch 的警报时，我收到错误

firing false
timeMs 0.225ms
error tsdb.HandleRequest() error Could not find executor for data source type elasticsearch

...这是否意味着尚不支持 ElasticSearch :cry:

ps 在进程输出中我得到这个：

EROR[08-04|09:15:00] Alert Rule Result Error                  logger=alerting.engine ruleId=1 error="tsdb.HandleRequest() error Could not find executor for data source type elasticsearch" retry=nil LOG15_ERROR="Normalized odd number of arguments by adding nil"

@Workshop2到目前为止，我们只支持石墨进行警报，但我们最终会支持 Elasticsearch :) 我会为此添加更好的错误消息。

如果查询没有返回数据，警报系统将如何运作？ 默认情况下会触发警报吗？
此外，一个简单的count减速器会很酷，它只返回查询返回的数据点数。

@bergquist我认为警报对于使用的数据源是透明的。 我们多久可以开始预览/测试非石墨数据源的警报功能？ （我意识到“多久......”问题没人喜欢，抱歉）

@RichiH一种选择是像 bosun 一样创建一个 grafana 应用程序。 https://grafana.net/plugins/bosun-app 但这并不能以简单的方式启用查询/仪表板重用。 让我们在 promcon 上更多地讨论它。 期待与您见面！ :)

最初也没有 influxdb 支持？

我不知道它与石墨的具体结合:(我们也在使用流入和
弹性搜索;)

2016 年 8 月 8 日星期一下午 2:18，elvarb [email protected]写道：

最初也没有 influxdb 支持？

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/grafana/grafana/issues/2209#issuecomment -238218714，
或静音线程
https://github.com/notifications/unsubscribe-auth/AEKf_4yp6-34PaOE2z4ynSriRxQpjKcvks5qdx59gaJpZM4FJUTl
.

恩里科·科恩

首席系统工程师

格利斯帕有限公司
索嫩伯格大街 73 号
10437 柏林，德国

电话：+49 30 5557130-17
传真：+49 30 5557130-50
Skype：传单。 [email protected]

---

Sitz Berlin, AG Charlottenburg HRB 114678B

只是最初，我们可能会在发布前添加 Prometheus。 也许 InfluxDB 或 Elasticsearch 也是如此，由于警报调度和执行是在后端进行的，请求和响应代码是从头开始编写的（在 Go 中），前端数据源插件代码（用 js 编写）无法重用。

我们正在使用 influx，我认为我们可能会放弃 Grafana 集成并使用 Kapacitor 和一个简单的 Web 前端来创建和管理警报。

+1 警报 + InfluxDB。

2016 年 8 月 8 日星期一上午 6:01，Thom Nichols通知@github.com
写道：

我们正在使用 influx，我想我们可能会放弃 grafana 集成和使用
Kapacitor 具有用于创建和管理警报的简单 Web 前端。

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/grafana/grafana/issues/2209#issuecomment -238228133，
或静音线程
https://github.com/notifications/unsubscribe-auth/AAY0-VP--Ysoxu5IV0hslQrP8cvF5ePSks5qdyi_gaJpZM4FJUTl
.

迪帕克

不幸的是，我们在构建数据源插件方面所做的工作仅对客户端有用。

考虑到支持针对不同数据源发出警报、构建 go 插件架构等的近期和长期工作，在 NodeJS 中构建警报服务器的工作量是否几乎相同（如果不少的话），因此它可以使用现有的数据源插件？

撇开关于 go 与 nodejs 的意见不谈，这可以显着减少代码重复，以针对不同数据源发出警报。

如果你真的不喜欢 node，我敢打赌 go 中有一个调用机制来加载和执行 JS。

ElasticSearch 的 +1 警报

嗨，我们一直在等待... OpenTSDB 的警报系统！ 我们可以吗
希望尽快为 OpenTSDB 获得它？ （也许什么时候？）

非常感谢团队！

2016-08-08 17:28 GMT+02:00 Slava Vishnyakov通知@github.com：

ElasticSearch 的 +1 警报

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/grafana/grafana/issues/2209#issuecomment -238273405，
或静音线程
https://github.com/notifications/unsubscribe-auth/ARsY50v7meI_EuzSAJGtvDMDareYKSDhks5qd0sggaJpZM4FJUTl
.

ElasticSearch 的 +1 警报
是否有可能在警报时执行脚本？

你们在 docker 镜像中有警报分支吗？

1. 警报查询是否仅适用于查询“A”？ 这是硬编码吗？
2. 我们什么时候可以期待一个完全可用的警报版本？ （19号还是目标）
3. 我们什么时候可以期待 Elasticsearch 与警报一起工作？

编辑：

1. 我可以为每个图表添加多个警报规则吗？
2. 我可以在 HTTP 消息中添加一些有关警报的信息吗？ (dashboard/graph/observed_query/alarm_config/alarm_query/threshold/warn_or_crit/value/observed_timeframe/time_of_occurence)

@DEvil0000

1) 您可以更改为指标选项卡中的任何查询。
2）完全工作，取决于你的意思。 我们计划在本周将其合并到 master。 然后人们可以开始测试每晚构建并提供反馈。 Alpha 版在 2-3 周内发布，Beta 版和稳定版取决于反馈以及稳定的速度
3) Elasticsearch 很棘手，需要大量代码来查询和解析响应为时间序列，因此可能会在添加对 Prometheus 和 InfluxDB 的支持后出现

@托克洛
我是 elasticsearch、grafana 和 go lang 的新手。 我想你已经在寻找客户了，但你见过那些吗？
https://github.com/olivere/elastic
https://github.com/mattbaird/elastigo
这些库可能会减少工作量。

还要感谢在这方面工作的隐藏精灵。 我怀疑@Dieterbe ，但我不知道。

警报现在主要是@torkelo和@bergquist （和@mattttt ）。 我已经将注意力转移到我们即将推出的石墨后端， https://github.com/raintank/metrictank

我很高兴看到这个功能取得了进展。 很想支持 OpenTSDB，因为其他警报解决方案 (Bosun) 不够用户友好，无法在这里经常使用。

希望能够在下一个正式版中看到报警，向那些辛苦编码的程序员致敬。

希望能够在下一个正式版中看到报警，向那些辛苦编码的程序员致敬。

@superbool sorry can't read this and google translation was not very helpful

Merge to master WILL happen by August 19, I promise :)

@torkelo hehe next time I bet. Is there a new date?

Can we expect the alerting for OpenTSDB to be scheduled? We may find
(modest) founding to encourage dev.

2016-08-22 10:05 GMT+02:00 A. Binzxxxxxx [email protected]:

希望能够在下一个正式版中看到报警，向那些辛苦编码的程序员致敬。

@superbool https://github.com/superbool sorry can't read this and
google translation was not very helpful

Merge to master WILL happen by August 19, I promise :)

@torkelo https://github.com/torkelo hehe next time I bet. Is there a
new date?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/grafana/grafana/issues/2209#issuecomment-241340597,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ARsY59771TaHEIaqCHbf-4TKWc4OdjVXks5qiVhdgaJpZM4FJUTl
.

@DEvil0000希望看到警报功能能够在下一个稳定的 Grafana 版本中发布，并向所有开发该工具的人致以崇高的敬意。
对不起，我的英语不是很好，希望你能理解我的话

@DEvil0000计划是上周五合并，但由于一些计划外事件（https://twitter.com/torkelo/status/766514688997732352），我们不得不推迟一点：）我们还有一些小事要做。

@torkelo恭喜！
@bergquist @torkelo我需要在 10 月之前使用弹性警报（alpha 对我来说没问题）。 我可以帮你实现吗？ 您只需要向我提供一些信息即可作为起点；)

警报分支现已合并到主分支。 :raised_hands:

我们感谢从这个问题中收到的所有反馈。 感谢你们所有人！
未来讨论和反馈，请在相应的警报问题中发布或创建一个新的。 这有助于我们组织和优先考虑我们未来的工作。 我正在关闭这张票以支持新票。 但是请随时继续讨论这个问题。

下一个是什么？

• Alpha 版本（文档和博客文章）
• 收集社区的反馈。
• 继续处理剩余的警报问题
• 发布带有警报的 Grafana 4.0。

试试看？

• 您必须在config 中启用警报。
• 您现在可以在侧边菜单中找到警报。
• 您可以通过转到图形面板并选择警报选项卡来添加警报。
• 使用 _Test alert_ 按钮验证您的警报。
• 要保存警报，您只需保存仪表板。
• 在 /alerting/notifications 上设置通知以收到有关触发警报的通知。
• 将通知程序添加到警报选项卡中的警报。

当前限制

• 到目前为止，我们只支持石墨。
• 对于此版本，只有图形面板支持警报。

示例仪表板

您可以在示例文件夹中找到示例仪表板。
示例仪表板基于来自我们假石墨数据编写器的数据。 您可以从我们的 docker-compose 文件中启动 Graphite 和 fake-data-writer。

cd docker/
./create_docker_compose.sh graphite
docker-compose up

这应该只是一个粗略的指南，我们将在接下来的几周内添加更多关于警报的文档。

快乐提醒！ ：鸡尾酒：：多田：

@bergquist恭喜。

关于此功能的未来，我们有什么可以关注的问题吗？

@Workshop2 https://github.com/grafana/grafana/issues/5858

警报条件中只有一个“AND”而不是“OR”来在一个面板中添加“高于”或“低于”，还是有其他方法来支持这一点？

我认为有一个“超出范围”/“在范围内”选项。 但我也想看到一个“或”。

大家好！ 非常感谢您为这个有用的功能做出的贡献。

这对我来说真的很有趣，但在很多情况下，我需要在警报条件中添加一个“OR”，因为不可能在一个gragh中创建多个警报。

我认为没有那个“或”我将无法为这种图表创建警报：

任何的想法？ 您是否打算添加“或”选项？

BR

@jmgonzalezp是的，我们也希望支持 OR（还不确定混合 AND 和 OR）

我们有 2 个剩余的警报设计决策，我们希望得到一些关于（分类和严重性/状态）的反馈。

这是我们当前想法的问题，非常感谢您的反馈。
https://github.com/grafana/grafana/issues/6007

大家好！ 感谢 grafana 提供如此出色的功能！

我有一个关于此警报系统的问题。 目前，我们在 AWS 中使用 Auto Scaling 组来部署 grafana，如果我在多台机器上运行 grafana 会不会有问题？ 我指的问题是，多台 grafana 机器会发出多个相同的警报吗？ 或者grafana已经处理了？

@torkelo我和@akurniawan 有同样的问题。 让我们考虑一下这个设置：1 个负载均衡器，负载均衡器后面的 3 个 Grafana 实例，1 个 Mysql DB，所有 3 个实例共享。 在这种类型的设置中，Grafana 服务器将如何处理警报？ 我们应该只在 1 个实例上启用警报，还是 Grafana 跟踪警报以便多个节点不检查和发送相同的警报？

@utkarshcmu @akurniawan在grafana 中的警报还不支持HA。 我们的计划是在未来增加对服务器之间分区警报的支持。

@bergquist感谢您的回答。 :)

@bergquist关于何时为此添加 InfluxDB 支持的任何预计

@thisisjaid从这个https://github.com/grafana/grafana/milestone/40判断它应该在 10 日在这里。

@Dieterbe 是否有任何 ETA 警报支持 OpenTSDB？

@sofixa谢谢，应该自己查看路线图，如果不是 RTFMing。 还是很欣赏的。

@Dieterbe 是否有任何 ETA 警报支持 OpenTSDB？

我不再从事警报工作。 也许@torkelo或@bergquist可以回答。

@torkelo @bergquist

用于 OpenTSDB 警报支持的任何 ETA

@LoaderMick @naveen-tirupattur OpenTSDB 警报已添加到 Grafana，应该是下一个版本的一部分。 此外，OpenTSDB 的警报正在夜间构建中工作。

任何用于警报支持 influxDB 和 prometheus 的 ETA 吗？

两个数据源的@nnsaln警报已经在主分支中。

我似乎无法通过（Grafana v4.0.0-pre1（提交：578507a））与OpenTSDB一起使用警报。 我测试了电子邮件系统（工作），但即使我的阈值很低，警报也不会触发。 无论如何手动运行查询并查看它正在提取的数据？

Grafana v4.0.0-pre1（提交：9b28bf2）
错误 tsdb.HandleRequest() 错误 Influxdb 返回状态码无效状态码：400 错误请求

@托克洛
“webhook 警报通知”可以发布警报指标、json 或表单类型吗？

嗨，伙计们，Grafana 是否支持使用模板变量发出查询警报，或者是否有针对此的目标版本？

所有，请尝试 4.0 测试版； 如果缺少某些内容，请打开新问题。

理查德

手机发送； 请原谅我的简短。

我已经尝试了 4.0 测试版，但仍然出现此错误
错误 tsdb.HandleRequest() 错误 Influxdb 返回状态码无效状态码：400 错误请求

我无法保存警报通知 - 发送到，保存后，行发送到再次变为空白

@nnsaln您应该在那里填写通知目标，而不是电子邮件地址。 打开 grafana 侧边菜单并将鼠标悬停在警报菜单选项上，然后点击通知菜单选项。 在那里你可以设置一个通知目标，你可以从你的警报规则中使用它。

是否有任何计划支持模板变量和警报？ 我愿意
理解一个（或一组）模板变量生成的每个图对应
到不同的图形，因此针对静态值生成警报是
不正确。

2016 年 12 月 5 日星期一上午 2:06，Tomas Barton通知@github.com
写道：

@nnsaln https://github.com/nnsaln你应该填写通知
目标是那里，而不是电子邮件地址。 打开 grafana 侧边菜单并将鼠标悬停在
警报菜单选项，然后点击通知菜单选项。 那里
您可以设置可以从警报规则中使用的通知目标。

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/grafana/grafana/issues/2209#issuecomment-264813888 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AAY0-X4UkyVE0MeBlSiYD9892OuruGcVks5rE-I6gaJpZM4FJUTl
.

——
迪帕克

不，目前不支持这样做。 也许在遥远的未来，但

99% 的仪表板使用模板变量。 他们是用模板设计的
变量以避免“仪表板爆炸”问题。

2016 年 12 月 5 日星期一晚上 8:20，Torkel Ödegaard通知@github.com
写道：

不，目前不支持这样做。 也许在遥远的未来，但

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/grafana/grafana/issues/2209#issuecomment-265056805 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AAY0-T9iFrqUcq4KbIECDe526040U6DHks5rFOJ4gaJpZM4FJUTl
.

——
迪帕克

是的，但通用探索仪表板与警报规则的仪表板设计不同。

到目前为止，还没有关于如何以直观/可理解的方式支持模板变量的建议。 带有变量的警报查询应该做什么？ 使用当前保存的变量值进行插值？ 是否应该将每个值视为单独的规则并为每个等保留状态。支持模板变量为复杂性和潜在的混淆行为打开了一个蠕虫罐。 如果有人想出一个简单易懂的方法，可能有一天会添加。

与此同时，没有什么能阻止您创建单独的警报仪表板。
警报是新的，是 grafana 的一个重要补充。 它会随着时间的推移而发展，
但在实施的短时间内，它为 grafana 增加了巨大的价值，
并感谢所有贡献者！

上午 06.12.2016 11:14 nachm。 schrieb "Torkel Ödegaard" <
通知@github.com>：

是的，但通用探索仪表板与仪表板不同
警报规则的设计。

到目前为止还没有关于如何支持模板变量的提议
以直观/可理解的方式。 什么应该用变量提醒查询
做？ 使用当前保存的变量值进行插值？ 应该是
将每个值视为单独的规则，并为每个等保留状态。 支持
模板变量为复杂性和潜在的
令人困惑的行为。 如果有人想出一个
简单易懂的方式。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AEKf_5VldwX2fG-USjnmlMH2qOZIDdKpks5rFd5DgaJpZM4FJUTl
.

+1 托克尔。

它确实使警报变得相当复杂。

2016 年 12 月 6 日星期二下午 2:14，Torkel Ödegaard通知@github.com
写道：

是的，但通用探索仪表板与仪表板不同
警报规则的设计。

到目前为止还没有关于如何支持模板变量的提议
以直观/可理解的方式。 什么应该用变量提醒查询
做？ 使用当前保存的变量值进行插值？ 应该是
将每个值视为单独的规则，并为每个等保留状态。 支持
模板变量为复杂性和潜在的
令人困惑的行为。 如果有人想出一个
简单易懂的方式。

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/grafana/grafana/issues/2209#issuecomment-265290049 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AAY0-UgrMH9u7sI-FmPVgFhMVXJBvzTvks5rFd48gaJpZM4FJUTl
.

——
迪帕克

@bergquist关于此评论

grafana 中的警报尚不支持 HA。 我们的计划是在未来增加对服务器之间分区警报的支持

是否有跟踪进度的票？ 有什么分支可以贡献吗？

非常感谢您的出色工作！

克恩，

<3 格拉法纳。

我只是想分享关于使用模板警报的想法
仪表板。

2016 年 12 月 9 日星期五凌晨 2:53，Dmitry Zhukov通知@github.com
写道：

@bergquist https://github.com/bergquist关于此评论

grafana 中的警报尚不支持 HA。 我们的计划是添加
支持将来在服务器之间划分警报

是否有跟踪进度的票？ 有什么分支可以贡献吗？

非常感谢您的出色工作！

—
您收到此消息是因为您发表了评论。
直接回复本邮件，在GitHub上查看
https://github.com/grafana/grafana/issues/2209#issuecomment-265986808 ，
或静音线程
https://github.com/notifications/unsubscribe-auth/AAY0-aQXFZUeEfVl0MSQP7FQpMZGIh0mks5rGTMsgaJpZM4FJUTl
.

——
迪帕克

@torkelo @Dieterbe终于在 Grafana 中内置了警报真是太棒了！ 以编程方式创建警报的推荐方法（如果有）是什么？

@jaimegago使用仪表板 API 以编程方式创建警报，警报与面板和仪表板一起保存。

@torkelo通知目标如何（例如通过 API 创建新的通知电子邮件）？

编辑：在这里回答我自己，我找到了 api/alert-notifications 端点。 我认为它只需要记录在案

当然有一个 http api，只需转到警报通知页面，添加通知并检查 http api 调用 grafana

@torkelo ，是否有任何 api 可用于以编程方式创建警报（而不是创建警报通知）

@CCWeiZ警报是仪表板 json 的一部分。 因此，您只能创建包含警报而非警报的仪表板。

您可以在http://docs.grafana.org/http_api/dashboard/上阅读有关仪表板 api 的更多信息

这是否可用：我想设置一个警报，如果一个值与 3 天前相比，该值没有增加。 （说请求，如果现在值 - 3 天前请求 < 100，那么我们说没有太多请求。）。 这该怎么做？