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