对于 IT 的稳定性保障，越来越受到重视，据国外数据统计，监控、可观测性相关的支出大概占总体 IT 支出的 5%～8% 左右。CNCF 作为知名基金会，旗下最有名的项目当属 Kubernetes，其次两个重点项目 OpenTelemetry 和 Prometheus 都与监控、可观测性相关。
可观测性领域通常讲有三大支柱：Metrics、Logs、Traces，也就是三类数据。
为了建设这些可观测性数据基座，各个公司会建设各种零零散散的系统，比如：
- Metrics：Zabbix、Prometheus、VictoriaMetrics
- Logs：ELK、ClickHouse、OpenSearch、Splunk
- Traces：Jaeger、Skywalking、SigNoz
再加上公有云上的云监控、云日志等系统，随便一个中型公司，其相关系统的数量都会超过 5 套。
于是，就衍生了一个自然而然的问题：
哪些能力是可以整合为一个系统的？不要这么分散，体验不一致，体验太差
其实是有的，开源社区的 Grafana 就是把看图可视化能力给整合到一起了。存储领域，ClickHouse 也有一统江湖的雄心，事件 On-call 领域则是 PagerDuty、FlashDuty 的战场。
今天为大家介绍另一个开源项目：Nightingale，是在尝试整合告警能力，支持对接常见数据源，让用户配置告警规则，周期性查询这些数据源里的数据，对数据做异常判定进而生成告警事件。
夜莺项目简介
夜莺监控（Nightingale）是一款侧重告警的监控类开源项目。类似 Grafana 的数据源集成方式，夜莺也是对接多种既有的数据源，不过 Grafana 侧重在可视化，夜莺是侧重在告警引擎、告警事件的处理和分发。
夜莺监控项目，最初由滴滴开发和开源，并于 2022 年 5 月 11 日，捐赠予中国计算机学会开源发展委员会（CCF ODC），为 CCF ODC 成立后接受捐赠的第一个开源项目。
其开源仓库地址：
夜莺架构介绍
夜莺的职能就是做告警引擎，所以架构很简单，当然，因为夜莺也支持转发指标数据、支持告警自愈、支持边缘模式告警引擎，因为这些长尾需求让架构上也变复杂了。但是长尾需求毕竟是长尾需求，用的人少，今天我们就介绍夜莺最经典精简的架构，这也是所有夜莺用户都应该了解的。
我画了一张架构图如下：
首先，夜莺可以对接各类数据源（这个设计和 Grafana 很像），比如上图下方的 Prometheus、VictoriaMetrics、ElasticSearch、MySQL、ClickHouse、Doris、OpenSearch、PostgreSQL 等等。
然后，夜莺内置一个告警引擎，根据用户配置的告警规则周期性查询数据源并生成告警事件，生成的告警事件需要分发出去，也就是通过右侧的 FlashDuty、Slack 等等通知媒介。
夜莺要让用户配置告警规则、查看告警事件，需要需要一个 UI 和用户交互，所以夜莺内置一个 API 模块。另外，夜莺要把用户配置的告警规则存入 MySQL，一些缓存数据需要用到 Redis，所以，夜莺依赖 MySQL 和 Redis 两个存储。
Nightingale-Web-API 和 Nightingale-Alerting-Engine 都是夜莺进程里的两个职能，并非是两个单独的进程，这两个职能都在一个 n9e 进程里。
上面的架构是夜莺不介入数据采集和传输环节，需要你自行采集数据，夜莺只是去查。如果你想让夜莺来采集数据行么？也行，不过仅限于指标数据。夜莺本身其实没有数据采集的能力，但是夜莺可以和另一个开源项目 Categraf 协同，来采集 OS、数据库、中间件、SNMP 等各类监控数据。
Categraf 会把采集的数据推送给夜莺，不过夜莺没有内置时序数据的存储（即 TSDB），所以夜莺实际是把数据做了转发，转存到其他时序库（比如 Prometheus、VictoriaMetrics）。
如果把数据采集和转存的逻辑也画到架构图上，那新的架构就变成了：
上图没有画出通知媒介，也没有把夜莺进程内部的两个职能画出来，是因为画布太小，重点突出数据采集、转存链路。
Categraf 需要部署在所有待监控机器上，因为 CPU、内存、磁盘、网络、IO 等监控数据需要读取本机的信息。然后，所有的 Categraf 把采集的监控数据推送给夜莺，夜莺转存入 TSDB，上图的话，是转存到了 VictoriaMetrics，这是和 Prometheus 兼容的时序库，性能更好而且有集群模式。
具体而言，是在夜莺的配置文件里 config.toml 配置了一个 Pushgw.Writers 部分，指向了时序库的 Remote Write 地址，夜莺收到监控数据之后，就是转发给了这个地址。
最后，我们再讲一下边缘架构模式。
边缘架构模式
边缘架构模式的起因是：
- 公司有多个机房，不同的机房之间网络链路不太好，甚至是单向连通的
- 不同的机房可能单独部署了时序库、日志库等数据源
- 希望在中心端的夜莺 Web 上统一管理告警规则
- 但是告警引擎要频繁访问数据源，就需要单独提取一个边缘告警引擎的模块，部署到边缘机房，部署到边缘数据源的旁边，这样性能好，不会因为网络问题影响告警
于是，除了部署在中心端的 n9e，边缘机房还可以部署 n9e-edge，引入了 n9e-edge 之后，架构变成了：
上图为例，中心机房部署了夜莺 n9e 进程，机房 A 和中心机房之间有良好的网络质量，那就可以把中心机房的 Prometheus、VictoriaMetrics 都直接交给中心的 n9e 进程负责告警判定。
但是机房 B 和中心机房之间的网络链路不好，而机房 B 内部也有 Prometheus、VictoriaMetrics，此时建议在机房 B 内部部署一个 n9e-edge 进程，负责机房 B 的两个时序库的告警判定。
n9e-edge 会从中心端 n9e 同步告警规则到内存里，这样后面如果网络断了，顶多是告警规则短期不更新了，没有其他太大的影响，n9e-edge 根据内存里的告警规则，周期性查询本机房的时序库，产生告警事件，通过外网出口，投递给钉钉、飞书、Slack、FlashDuty 等外网通知媒介。
总结
本文通过几张图，试图讲清楚夜莺监控的架构，更多信息请参考夜莺的 官方文档。