Flashduty 作为一款 OnCall 平台，核心解决的是告警分发之后的响应链路，包括收敛降噪、排班、认领升级、分发、协同等。
实际使用中，很多团队还有另一个需求：不想只把外部监控系统产生的告警转发进来，也希望直接在 Flashduty 上管理告警规则，让系统按规则查询数据源、判断异常并生成告警事件。
Flashduty 的监控告警功能就是为这个场景准备的。它类似 vmalert 的工作方式，但覆盖的数据源更广：vmalert 主要面向 VictoriaMetrics 数据查询判定，而 Flashduty 可以支持 Prometheus 兼容数据源、MySQL、PostgreSQL、Oracle、Elasticsearch、Loki、ClickHouse 等。
核心要点
- Flashduty Monitors 负责“产生告警”，OnCall 协作空间负责“处理告警”，两者可以形成一条完整链路。
- 告警引擎模块
monitedge下沉部署在客户环境内部，用来访问私有网络里的监控数据源。 - 同一个告警引擎集群可以部署多个实例，自动分片处理规则，并在实例故障时接管规则处理。
- 上手流程可以按“安装告警引擎、配置数据源、创建告警规则、查看告警事件”四步推进。
架构原理
Flashduty 是一个 SaaS 服务，部署在云上，无法直接访问客户私有网络内部的数据。但是告警阈值判定又必须查询这些数据，因此 Flashduty 采用了边缘告警引擎架构：
- 将告警引擎模块
monitedge下沉部署到客户环境内部。 monitedge通过公网拉取 Flashduty 上配置的告警规则，并缓存到内存里。monitedge访问客户私有网络内部的数据源，执行查询和告警判定。- 判定产生告警后，再把告警事件发送到 Flashduty 进行后续分派、降噪和协同。
其架构图如下：
客户环境通常会有多个机房，比如图上的美东机房和华南机房，每个机房通常有不止一套时序库，比如 Prometheus 或 VictoriaMetrics，当然，Flashduty 也可以对接 ElasticSearch、Loki、ClickHouse 等其他存储库。图上就以 VictoriaMetrics 举例。
每个机房通常要部署一个 Flashduty 告警引擎，用于对本机房内部的监控数据做告警判定。即美东机房部署一个 monitedge，处理美东机房的监控数据，华南机房部署一个 monitedge，处理华南机房的监控数据。当然，如果贵司各个机房之间的网络链路很好，就部署一个 monitedge 处理所有机房的监控数据也是可以的。
如果部署一个 monitedge 担心单点故障风险，也可以部署多个 monitedge 实例组成集群。比如美东机房部署 2 个 monitedge 实例组成集群，实例启动的时候通过 –alerter.clusterName meidong 参数设置相同的集群名字，华南机房部署 2 个 monitedge 实例组成另一个集群，这俩实例启动的时候通过 –alerter.clusterName huanan 参数设置另一个集群名字。
一个告警引擎集群中的多个实例，会自动分片处理告警规则，比如这个集群要处理 100 条告警规则，系统会自动均衡，让每一个 monitedge 实例分别处理 50 条。如果其中一个实例挂掉，另一个实例会接管所有的这 100 条告警规则的处理，既保证了高可用，又避免了告警事件重复发送。
监控管理菜单说明
Flashduty 的监控告警功能，菜单入口就是“监控管理”。进来之后有 5 个菜单，这里我简单介绍一下各个菜单的职能。
| 菜单 | 作用 | 使用重点 |
|---|---|---|
| 概览 | 展示统计信息和系统事件列表 | 系统事件列表需要关注，它会呈现告警引擎执行过程中的错误 |
| 告警规则 | 管理各类告警规则 | 左侧树形分组用于承载较大数量的规则 |
| 规则仓库 | 提供常用告警规则模板 | 可导入到自己的分组下再修改使用 |
| 节点权限 | 管理树形分组权限 | 不同节点可以关联不同团队，团队人员管理对应分组和子分组 |
| 数据源 | 管理告警引擎要连接的数据源 | 数据源地址要配置为 monitedge 可以连通的地址，通常是内网地址 |
| 告警引擎 | 查看告警引擎列表、安装和升级方式 | 引擎安装后会和服务端心跳通信；超过 30s 未通信会被标记为离线 |
快速开始
Flashduty Monitors 的上手路径可以分为四步：安装告警引擎、配置数据源、创建告警规则、查看告警事件。
告警引擎
第一步是安装告警引擎，在告警引擎的菜单下可以看到相关的安装、升级命令：
安装告警引擎之前，需要想清楚你的集群规划。比如把你们公司整体划分为几个网络分区，每个网络分区内放置一个告警引擎。每个分区内的告警引擎可以部署多个实例组成集群，实现高可用，每个分区内的告警引擎共享一个名字，这个名字就是 Flashduty 页面上的“引擎集群名字”字段，这个字段旁边有个小问号，提供了一个 tooltip，里面有详细的说明。Flashduty 很多页面上的字段都有 tooltip，建议大家多看看。引擎集群的名字是随意自定义的，一般是机房名字，比如 meidong、huanan、us01 等。引擎名字修改之后，下面的命令也会自动变化。
另外，告警引擎进程要和 SaaS 服务端通信，就需要有个安全认证机制，需要一个 API Key，第二个字段就是选择 API Key 的，如果当前没有 API Key，也可一点击旁边的“管理 API Key”创建一个。选择不同的 API Key，下面的安装命令会自动变化。
复制我们提供的安装命令，直接安装即可。安装完成之后，告警引擎会自动和服务端建立连接，在“告警引擎状态”页面，就可以看到告警引擎实例列表了。如下图所示：
数据源
第二步是配置数据源。告警引擎需要连接各类数据源，数据源地址要配置为告警引擎（monitedge 进程）可以连通的地址，通常是内网地址。
进入「数据源」菜单，点击「添加数据源」，填写相关信息即可创建数据源。
上面是 Prometheus 数据源的创建页面。虽然数据源类型选择的是 Prometheus，也可以填写 VictoriaMetrics 或 Thanos 的地址，因为这些数据源都兼容 Prometheus 查询接口。
配置时建议注意三点：
- 数据源名称要能体现业务或机房，例如 “Prom-业务a”。
- 数据源要选择合适的告警引擎，例如美东的 Prometheus 选择美东的告警引擎，避免跨机房查询。
- 数据源地址填写告警引擎可以访问的地址，例如
http://10.1.2.3:9090。
最后点击「保存」即可。
告警规则
第三步，也是最重要的一步，就是创建告警规则了。进入「告警规则」页面，首先创建一个分组：
点击这个小加号，创建的分组是顶层分组，可以创建多个顶层分组，也可以在顶层分组下面创建子分组，如果想创建子分组，就是分组节点右键，选择「新增子分组」即可。分组的划分比较随意，可以按照业务来划分，比如 A 业务是一个顶层分组，B 业务是另一个顶层分组，业务分组下面可以创建项目分组等，具体要看你们公司的情况。初步测试阶段，不用不用搞的太复杂，就创建一个顶层分组就可以了。
然后选中刚才创建的顶层分组节点，右侧点击「创建」即可创建告警规则。当然了，也可以点击导入，从规则库导入，或者导入之前导出的 JSON，或者直接导入 Prometheus 的告警规则 YAML。
上图是创建告警规则的页面，截取了一部分，大家可以看到，每个字段旁边几乎都有一个小问号提供了 tooltip 说明，如果你有疑问，请先查看这些 tooltip。仅就上面截图的部分字段做一下说明：
- 规则名称：类似 Prometheus 中的 alertname，就是给告警规则取个名字，未来可以根据这个名字做过滤、聚合等。
- 附加标签：附加到该规则产生的所有告警事件上，未来可以使用这些标签做多维度筛选和事件聚合。输入格式
key=value，可以输入多个标签，每输入一个用回车分隔。如果打了__debug__=1这个特殊标签，monitedge 会打印该规则的详细处理日志，对于问题排查很有帮助。 - 数据源类型：选择 Prometheus，ElasticSearch、Loki、ClickHouse 等数据源类型。
- 数据源：你想把告警规则生效到哪些数据源上，就选择哪些数据源。支持通配符。
查询检测方式
对于 Prometheus 类型的数据源，查询条件这里，就是写 PromQL，然后提供三种告警判定方式：
- 阈值判定：PromQL 中不包含阈值，monitedge 拿着 PromQL 去查询并得到结果，对结果进行阈值判定，阈值是写在 Critical、Warning、Info 那些框里的。上例截图中的配置，表示：如果内存使用率大于 80%，就触发 Warning 级别的告警，如果内存使用率大于 90%，就触发 Critical 级别的告警，如果内存使用率一下子从小于 80% 飙高到大于 90%，会只触发 Critical 级别的告警，不会触发 Warning 级别的告警。
- 数据缺失：根据 PromQL 去查询数据，如果查到了就保存到内存里，下一个周期再查询，下个周期查不到了，就产生告警事件。
- 数据存在：这种方式的话，阈值一般是写在 PromQL 中的，比如
mem_used_percent{service="mon"} > 85，拿着这个 PromQL 去查询，只要查到数据就告警，这种方式和 Prometheus 原生提供的方式完全一样。
其中，阈值判定模式下，Recovery 还支持多种方式，回头再细化讲解，现在初步体验，可以先不用管太细。
| 判定方式 | 核心逻辑 | 适合场景 |
|---|---|---|
| 阈值判定 | 查询结果与 Warning、Critical、Info 阈值比较 | 指标数值越界，例如内存使用率过高 |
| 数据缺失 | 上个周期有数据、下个周期查不到数据时触发 | 采集链路异常、目标停止上报 |
| 数据存在 | 只要 PromQL 查到数据就告警 | Prometheus 原生风格表达式，例如 mem_used_percent{service="mon"} > 85 |
生效配置和事件投递
最后面两部分是检测频率和时间配置。各个重要字段都提供了 tooltip 说明。这里也一并赘述一下：
- 检测频率：cron 表达式，支持到秒（注意，跟 Linux 下的 crontab 不同），即：秒 分 时 日 月 周，比如
1 * * * * *表示每分钟第一秒执行。也可以简写 @every 60s - 自定义字段：和自定义标签很像，只不过标签通常是一些维度信息，用于筛选，而自定义字段，通常是一些属性信息，比如这个告警规则对应的预案链接、Dashboard 链接都可以作为自定义字段
- 关联查询：告警的时候顺带查点相关的数据，就使用关联查询。在“数据存在”告警模式下，可以使用关联查询获取恢复时的值
- 备注描述：类似 Prometheus 的 annotations 中经常配置的 description 字段，用于告警事件的描述
- 协作空间：告警事件产生之后要投递到哪个 Flashduty 协作空间，然后在协作空间里可以继续配置分派、降噪规则来分派、通知告警事件
- 重复通知：如果事件没有恢复，monitedge 每隔 xx 秒可以重复生成告警事件，发给 Flashduty SaaS 端。当然，也不能无限发，所以支持配置最多生成 xx 次告警事件。注意，并非是每次生成事件都会触发通知，是否通知还取决于 Flashduty SaaS 端的降噪配置
查看告警
告警事件生成之后，告警规则的状态就会变成 Triggered，点击 Triggered 就可以看到生成的告警。当然，在故障列表页面也可以看到相关的故障。之后如何发送就是 Flashduty 协作空间里的分派规则的事情了，这里就不展开了。
FAQ
Q1：Flashduty Monitors 和传统 OnCall 能力是什么关系？ A：Monitors 负责查询数据源并产生告警事件；OnCall 能力负责告警进入协作空间后的收敛、分派、通知、认领、升级和协同。
Q2：为什么要部署 monitedge？
A：Flashduty SaaS 服务无法直接访问客户内网数据源，monitedge 下沉部署在客户环境内部后，可以访问内网数据源并完成告警判定。
Q3：一个机房要部署几个告警引擎？
A：通常每个网络分区或机房部署一个告警引擎集群。为了高可用，可以在同一集群里部署多个 monitedge 实例。
Q4：Prometheus 数据源能不能填 VictoriaMetrics 或 Thanos？ A：可以。原文场景中说明，这些数据源兼容 Prometheus 查询接口，因此可以按 Prometheus 类型接入。
视频教程
如果你还是不太明白，可以看一下我们的视频教程，视频教程里面有详细的操作步骤，可以帮助你快速上手。
