戏惶坷苏整体定位了解一个开源项目最应该了解的就是其定位或者说它要解决的问题域。夜莺的定位就是四个字告警引擎。夜莺对接多种数据源比如 Prometheus、VictoriaMetrics、MySQL、ClickHouse、Postgres、ElasticSearch根据用户配置的告警规则判定并产生告警事件然后对事件做 Pipeline 处理最终通过各类通知媒介发出告警。可以对比 Grafana 来理解Grafana 也是对接多种数据源不过 Grafana 侧重在数据可视化夜莺侧重在告警。image没有夜莺之前各个数据源的告警是怎么处理的Prometheus 是直接配置在 prometheus.yml 里管理起来稍有不便VictoriaMetrics 是使用 vmalert和 Prometheus 是类似的逻辑ElasticSearch 社区里用的比较多的是 elastalert 开源项目做告警判定ClickHouse、MySQL、Postgres 等貌似没有专门的告警引擎有了夜莺之后就可以在夜莺里统一管理告警规则、通知媒介、消息模板、用户联系方式等。而且夜莺可以对告警事件做 Pipeline 处理比如Relabel类似指标的 Relabel夜莺可以对告警事件做 RelabelEnrichment事件丰富比如调用 CMDB 的接口为事件附加更多丰富的上下文信息Drop一些特定的告警事件要丢弃掉等等夜莺的核心功能部件确定了定位之后如果你是夜莺的设计者要如何设计其功能部件呢首先需要一个 webapi。用于和用户、第三方交互用户需要做一些配置比如数据源的配置用户、角色的管理用户联系方式管理比如电话、手机号等未来在告警触发时要打电话发告警短信等各类规则配置比如告警规则、屏蔽规则、订阅规则通知媒介、消息模板的管理Pipeline 的管理查看历史告警事件做一些统计分析等其次需要有一个后台任务执行的逻辑根据用户配置的告警规则周期性执行去查询数据源判定数据异常并生成告警事件最终发送。最简单的就是一个告警规则一个 goroutine轻量级线程后台执行如果执行失败通过某些监控指标反应异常同时打印执行失败的日志需要考虑高可用如果某个实例挂了其他实例要顶上来需要考虑 sharding比如有两个实例有 1000 条规则那每个实例要处理 500 条规则不能重复执行而且要均匀分配如果某个实例挂了剩下的实例要能承接原本宕机的实例负责的那些规则对于某个实例而言就要知道当前总共有多少实例哪些实例存活哪些实例挂了否则我不知道谁挂了我就没法接管。这需要一个中心状态存储或者引入 Raft 等协议这个功能部件主要是负责告警姑且称之为 alert。所以夜莺至少有两个功能部件webapi alert。实际上夜莺还有其他功能部件后文再说。单进程还是多进程刚才讲夜莺至少包含两个功能部件webapi alert。那是做成一个进程还是做成两个进程如果是公司内部的系统我更倾向于做成两个进程方便维护。但作为一个开源项目还要考虑普通用户的部署复杂度则更倾向于做成一个进程。高可用设计对于 webapi 功能部件而言是一个无状态的组件接收 api 请求然后对数据库做 CRUD所以 webapi 可以水平扩展部署多个前面架设负载均衡就是高可用了。alert 模块需要协调分配告警规则是有状态的既然我们不可避免要使用数据库存储各类配置信息那就顺便用数据库存储 alert 的心跳信息得了比较简单。所以所有 alert 复用一个 MySQL周期性心跳这样 DB 的心跳表里就可以查到所有实例列表以及最近一次心跳时间从而得知哪些实例活着哪些已经挂了长时间没有心跳就认为挂了。这样的架构极为简单每个实例的配置都是相同的要做高可用就搞多个机器部署多个实例即可。社区用户用起来也简单。后记本文介绍了夜莺的定位、架构、单进程还是多进程的抉择、高可用设计如果你们公司只有一个机房或者有多个机房但是机房之间有很好的网络专线那就部署一套夜莺就可以了如果有多个机房但是机房之间的网络链路很差就需要考虑夜莺的边缘机房架构模式咱们下一节详细介绍。