Flashduty 监控告警功能简介
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 协作空间里的分派规则的事情了,这里就不展开了。
视频教程
如果你还是不太明白,可以看一下我们的视频教程,视频教程里面有详细的操作步骤,可以帮助你快速上手。