核心要点
- Flashduty 告警引擎可以对接企业内部存储并生成告警事件，使平台不只被动接收外部告警。
- 告警引擎本身如果失联，相关数据源可能无法继续产生告警，这是告警链路中的可用性风险。
- 引擎失联告警用于在引擎不可用时自动生成告警事件，并通知对应协作空间的维护人员。
- 新规则创建时已经填充默认字段，用户通常只需要根据实际情况调整并配置目标协作空间。
Flashduty 作为一个一站式告警平台，其核心功能是事件 OnCall，即对接各个监控系统（云上的、云下的、开源的、商业的），收集告警事件，然后统一做降噪、分发。去年我们扩展了 Flashduty 的功能，使其支持告警引擎，可以对接企业内部各类存储，做告警判定。
告警引擎的推出，让 Flashduty 的告警能力更完整：Flashduty 不止可以被动接收告警事件，也可以基于数据源主动生成告警事件。通常一个公司都有多套监控系统，看图方面可以利用 Grafana 做整合，告警方面则可以利用 Flashduty 做统一处理。
为什么需要引擎失联告警
Flashduty 告警引擎本身也处在告警链路里。如果引擎出现问题，相关数据源就都无法告警。虽然可以通过 systemd 自动拉起进程，或者通过部署多个 monitedge 实例来做高可用，但这里仍然缺少一环：当引擎失联时，平台应该主动发出告警。
引擎失联告警补上的就是这一环。它的作用是让团队知道“告警生产者本身不可用”，避免因为引擎失联而误以为系统没有异常。
如何配置引擎失联告警
如上图，我们在告警引擎菜单里加了一个 tab，叫做“引擎失联告警”，用于管理引擎失联告警规则。你可以点击「新建」按钮，创建一个引擎失联告警规则：
里边各个字段都已经填充了默认值，你可以根据实际情况修改，大部分字段见名知意，个别字段右侧带有小问号的 icon，提供了 tooltip 说明。我们可以维持默认配置，只是在最下面配置告警要推给哪个协作空间即可。至于事件进入协作空间之后如何发送，那就取决于协作空间内部的分派规则了。
配置后的处理链路
配置完成后，Flashduty 可以在引擎失联的情况下自动发出告警。告警进入指定协作空间后，会继续遵循该协作空间的分派规则，通知相关人员尽快处理。
这类告警的关键价值不是多发一条通知，而是提高告警链路自身的可观测性：当负责生成告警的引擎不可用时，维护人员可以及时知道并恢复它。
FAQ
Q1：已经用 systemd 自动拉起进程，还需要引擎失联告警吗？ 需要。systemd 负责尝试拉起进程，引擎失联告警负责通知人知道告警链路出现异常。两者解决的是不同问题。
Q2：引擎失联告警推给谁？ 规则创建后需要配置目标协作空间。事件进入协作空间后，具体通知给谁取决于协作空间内部的分派规则。
Flashduty 这种告警机制支持云上云下联动，欢迎注册体验，注册即送两周的免费试用时间：https://www.flashduty.com。
