一、夜莺系统简介
夜莺监控（Nightingale 简称 N9E, 类似K8S，所需其中的N个字母，方便阅读）与 Grafana 类似，支持对接多种数据源。Prometheus 是最常用的数据源（其他兼容 Prometheus 接口的数据源，如 VictoriaMetrics、Thanos、M3DB 等，均可视为 Prometheus 类型数据源），因此夜莺与 Prometheus 关系密切。
夜莺监控（Nightingale）是一款专注于告警的监控类开源项目。与 Grafana 类似，夜莺也采用数据源集成方式，支持对接多种现有数据源。两者的区别在于：Grafana 侧重于数据可视化，而夜莺侧重于告警引擎、告警事件的处理和分发。
Grafana: 侧重点在于进行监控数据UI页面的展示，支持多数据源(Promethues、Loki、ES等)
N9E夜莺: 侧重点在于适配多数据源的告警引擎， 可以集成告警规则、告警收敛、告警聚合、告警分发， 支持多数据源(Promethues、Loki、ES等)
后端：https://github.com/ccfos/nightingale 12.8K⭐
官方文档: https://n9e.github.io/zh/docs/prologue/introduction/
二、工作模式
1、模式一[单纯只做告警引擎、不做数据采集、不做数据存储] (目前集成的方式⭐️)
当用户已具备指标和日志数据采集能力时，可将现有存储系统（如 VictoriaMetrics、ElasticSearch 等）作为数据源接入夜莺，在夜莺中配置告警规则和通知规则，实现告警事件的生成和分发。这种模式下，夜莺不采集数据、不存储数据，仅作为告警引擎。
我们已经在各个私有云场地使用K8S进行部署，并且使用Promethues进行指标数据采集、存储， 天然存在多数据源。无需再使用夜莺自身的Categraf采集组件,所以使用此模式，夜莺仅用于做告警引擎、不做数据采集、也不做数据存储。
2、模式二[附加夜莺专有的Categraf 采集数据功能，兼备告警引擎]
如果对于尚未采集监控数据，也可以使用 Categraf 作为采集器，Categraf 可以与夜莺丝滑对接。Categraf 支持采集操作系统、网络设备、各类中间件和数据库的监控数据，通过 Remote Write 协议将数据推送至夜莺。这种模式下，夜莺仍然不存储监控数据，而是充当数据转发网关，将监控数据做一些处理然后转存至时序数据库（如 Prometheus、VictoriaMetrics 等）。
对于网络链路不稳定的边缘机房场景，为提升告警可用性，夜莺提供边缘机房告警引擎下沉部署模式。在此模式下，即使边缘机房与中心机房网络中断，告警功能仍可正常运行。
上图中，机房 A 与中心机房网络链路稳定，因此直接由中心端的夜莺进程执行告警引擎功能；机房 B 与中心机房网络链路不稳定，因此在机房 B 部署 n9e-edge 作为告警引擎，对机房 B 的数据源进行告警判定。
三、N9E的部署架构
1、单节点架构[N9E Golang编写的单个二进制文件主进程，依赖MySQL、Redis]
【N9E主进程】 HTTP监听端口17000， RPC接口监听20090、告警引擎(一堆后台告警规则执行任务，每个任务就是一个go 协程)
【MySQL数据库】 存储告警规则、用户信息、用户组信息、系统相关元数据等等
【Redis服务】 存储一些缓存数据库、Categraf相关、JWT相关数据
2、多节点+高可用架构
N9E的集群高可用很简单， 只需要启动多个N9E实例进程即可，并且这些N9E进程连接到相同的MySQL数据库、Redis服务，一个高可用的N9E夜莺监控系统就搭建完成了。 告警规则任务会进行均摊，例如有100个告警规则，那么存在5个N9E实例，那么平均每个实例会分到20个告警规则任务，执行告警规则查询任务。 如果其中某个节点挂了，那么其他节点承担之前宕机节点的告警规则任务。