概述

夜莺监控（Nightingale）是一款侧重告警的监控类开源项目。类似 Grafana 的数据源集成方式，夜莺也是对接多种既有的数据源，不过 Grafana 侧重在可视化，夜莺是侧重在告警引擎、告警事件的处理和分发。

• 后端(主仓库)：https://github.com/ccfos/nightingale

• 前端：https://github.com/n9e/fe

工作逻辑

很多用户已经自行采集了指标、日志数据，此时就把存储库（VictoriaMetrics、ElasticSearch等）作为数据源接入夜莺，即可在夜莺里配置告警规则、通知规则，完成告警事件的生成和派发。

夜莺项目本身不提供监控数据采集能力。推荐使用 Categraf （也是夜莺官方出品）作为采集器，可以和夜莺丝滑对接。

Categraf 可以采集操作系统、网络设备、各类中间件、数据库的监控数据，通过 Remote Write 协议推送给夜莺，夜莺把监控数据转存到时序库（如 Prometheus、VictoriaMetrics 等），并提供告警和可视化能力。

对于个别边缘机房，如果和中心夜莺服务端网络链路不好，希望提升告警可用性，夜莺也提供边缘机房告警引擎下沉部署模式，这个模式下，即便边缘和中心端网络割裂，告警功能也不受影响。

架构

不考虑边缘模式的话，夜莺只有一个主进程，即 n9e 进程，依赖 MySQL 和 Redis 存储一些管理数据，可以接入多种数据源，技术架构图示意如下：

支持的数据源：Prometheus、VictoriaMetrics（推荐）、ElasticSearch。

实际生产环境里，可能会有多个机房，中心机房和边缘机房的网络质量可能不太好，如果让中心机房的 n9e 负责边缘机房的某个时序库的告警，会不稳定，有时甚至 n9e 直接连不通边缘机房的时序库，这时就需要夜莺的边缘机房下沉部署模式。

假设有 3 个机房：中心主力机房、边缘机房 A 和边缘机房 B，其中边缘机房 A 和中心机房之间有专线，网络链路很好，边缘机房 B 和中心机房之间没有专线，走公网，网络链路不够可靠。

n9e 进程部署在中心主力机房，n9e 依赖 mysql 和 redis，所以 mysql 和 redis 也部署在中心主力机房。如果你想做高可用，中心机房的 n9e 可以部署多个实例，配置文件保持一致，连同一个 mysql 和 redis 即可。