Flashduty 作为一款 OnCall 平台，核心解决的是告警分发环节的需求，包括收敛降噪、排班、认领升级、分发、协同等。实际 Flashduty 也提供了告警引擎功能，可以在 Flashduty 上管理告警规则，Flashduty 根据规则去查询各类数据源做异常判定，进而生成告警事件，类似 vmalert 的功能，当然了，vmalert 仅是对 VictoriaMetrics 的数据做查询判定，而 Flashduty 可以支持更多的数据源，比如 Prometheus 兼容的各类数据源、MySQL、PostgreSQL、Oracle、Elasticsearch、Loki、ClickHouse 等。
架构原理
Flashduty 是一个 SaaS 服务，部署在云上，无法访问客户私有网络内部的数据，但是要做告警阈值判定，又必须能访问到数据。因此，Flashduty 采用了一种架构，把告警引擎模块（monitedge）单拎出来下沉部署到客户环境内部，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 页面上的“引擎集群名字”字段，这个字段旁边有个小问号，提供了一个 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，那就选择美东的告警引擎，避免跨机房查询。然后填写 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 还支持多种方式，回头再细化讲解，现在初步体验，可以先不用管太细。
最后面两部分是检测频率和时间配置。各个重要字段都提供了 tooltip 说明。这里也一并赘述一下：
- 检测频率：cron 表达式，支持到秒（注意，跟 Linux 下的 crontab 不同），即：秒 分 时 日 月 周，比如
1 * * * * *表示每分钟第一秒执行。也可以简写 @every 60s - 自定义字段：和自定义标签很像，只不过标签通常是一些维度信息，用于筛选，而自定义字段，通常是一些属性信息，比如这个告警规则对应的预案链接、Dashboard 链接都可以作为自定义字段
- 关联查询：告警的时候顺带查点相关的数据，就使用关联查询。在“数据存在”告警模式下，可以使用关联查询获取恢复时的值
- 备注描述：类似 Prometheus 的 annotations 中经常配置的 description 字段，用于告警事件的描述
- 协作空间：告警事件产生之后要投递到哪个 Flashduty 协作空间，然后在协作空间里可以继续配置分派、降噪规则来分派、通知告警事件
- 重复通知：如果事件没有恢复，monitedge 每隔 xx 秒可以重复生成告警事件，发给 Flashduty SaaS 端。当然，也不能无限发，所以支持配置最多生成 xx 次告警事件。注意，并非是每次生成事件都会触发通知，是否通知还取决于 Flashduty SaaS 端的降噪配置
查看告警
告警事件生成之后，告警规则的状态就会变成 Triggered，点击 Triggered 就可以看到生成的告警。当然，在故障列表页面也可以看到相关的故障。之后如何发送就是 Flashduty 协作空间里的分派规则的事情了，这里就不展开了。
视频教程
如果你还是不太明白，可以看一下我们的视频教程，视频教程里面有详细的操作步骤，可以帮助你快速上手。
