已经有 Prometheus 了，还需要夜莺？
谈起当下监控，Prometheus 无疑是最火的项目，如果只是监控机器、网络设备，Zabbix 尚可一战，如果既要监控设备又要监控应用程序、Kubernetes 等基础设施，Prometheus 就是最佳选择。甚至有些开源项目，已经内置支持了 Prometheus 协议的指标暴露，比如新版本的 Zookeeper、新版本的 RabbitMQ、Nginx vts 等等。Prometheus 的影响力可见一斑。
很多场景里讲到的 Prometheus 这个词，其实已经不仅仅是 Prometheus 项目本身了，而是 Prometheus 生态，包括 Prometheus 定义的指标格式、传输协议、查询语言、各类 Exporter 采集器、各类兼容的存储等。
在 Prometheus 生态里，采集可以使用各类 Exporter，存储可以使用 VictoriaMetrics，看图可以使用 Grafana，看起来已经非常完备了，为啥又冒出一个“夜莺（Nightingale）”的开源项目，还声称和 Prometheus 无缝对接？本文尝试探讨一二。
夜莺介绍
从夜莺官网摘出一段夜莺项目介绍：
夜莺监控是一款开源云原生观测分析工具，采用 All-in-One 的设计理念，集数据采集、可视化、监控告警、数据分析于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析和告警能力。夜莺于 2020 年 3 月 20 日，在 github 上发布 v1 版本，已累计迭代 100 多个版本。
夜莺最初由滴滴开发和开源，并于 2022 年 5 月 11 日，捐赠予中国计算机学会开源发展委员会（CCF ODC），为 CCF ODC 成立后接受捐赠的第一个开源项目。夜莺的核心研发团队，也是 Open-Falcon 项目原核心研发人员，从 2014 年（Open-Falcon 是 2014 年开源）算起来，也有 10 年了，只为把监控这个事情做好。
看完项目介绍，只能知道夜莺是一个监控系统，到底和 Prometheus 有哪些差异点，暂时没有看出来。别急，我们先来看看 Prometheus 的问题。
Prometheus 的问题
Prometheus 的采集、存储、看图都已经解决的挺好了。唯独就是告警，对某些公司来讲，可能会有如下痛点：
- 一个公司有很多套 Prometheus，规则分散在多个 yaml 中不方便管理
- 希望能有一套易用的、权限隔离的 UI，把监控能力开放给全公司各个团队并让他们自服务，别啥事都来找监控团队
- 直接使用 Promql 查询数据、配置告警规则要求有点高，能否内置一些规则库、查询语句，让知识可沉淀，让普通用户也能开箱即用
- 告警规则希望能够更灵活一些，比如支持不同的规则不同的生效时间，能够内置提供一些告警自愈的机制等等
夜莺就是为此而生的。其实夜莺老版本是自成体系的，脱胎自 Open-Falcon，但是随着 Prometheus 大势起来，夜莺就开始拥抱 Prometheus 生态了。可以把夜莺看做是时序数据的告警引擎。当然，夜莺也提供看图、仪表盘的能力，甚至可以查看 Elasticsearch、Loki、TDEngine 的数据，不过当前现状就是夜莺的告警能力大家用的最多，仪表盘大都仍然使用 Grafana 居多。典型的夜莺使用的架构如下：
可以用夜莺完全替代 Prometheus 吗？
其实不是替代的关系，是协同的关系。在夜莺看来，Prometheus 主要是作为时序库使用，除了 Prometheus 这个时序库，还可以选择 VictoriaMetrics、Thanos、M3DB、TDEngine 等其他时序库。夜莺呢，则只是作为一个时序库的告警引擎，既可以对接 Prometheus，也可以对接其他时序库，用户在夜莺里统一管理告警规则，对异常数据做判定，产生告警事件，并做后续分发通知、告警自愈等逻辑。
另外，如果你有多个机房，时序库分散在多个机房，机房之间的网络不好，即便发生网络割裂你也希望边缘机房能够自治不影响告警，夜莺也非常合适。这种情况夜莺称为边缘机房部署模式，时序库和告警引擎下沉部署，网络断了也没事，网络好的时候还可以在中心端统一查看数据，统一管理告警规则，其架构图如下：
上例中，演示了 3 个机房的部署架构，其中机房 A 和中心机房之间网络链路很好，机房 B 和中心机房之间的网络链路不太好，各个机房都有时序库。所以，中心机房的夜莺告警引擎直接处理中心机房和机房 A 的时序库，机房 B 的时序库由机房 B 的告警引擎处理，也就是图中的 n9e-edge，n9e-edge 会从中心机房的夜莺同步告警规则，然后对本机房的时序库做告警判定。
这样一来，即便机房 B 和中心机房之间网络割裂，由于 n9e-edge 内存中早就同步到了告警规则，所以机房 B 的告警引擎还是可以正常处理机房 B 的两个时序库的告警判定工作。提升了监控系统整体高可用性。
什么场景用夜莺而非 Prometheus？
关键看你的痛点是什么。如果现阶段使用单点的 Prometheus 也可以很好的解决你的问题，完全没必要换，在任何公司，技术工具的迁移都是会受到各种阻力的，懂的自然懂。
如果你有告警规则管理的痛点、边缘机房告警高可用的痛点，那可以尝试一下夜莺。任何工具都有自己的优缺点，根据场景选择。
夜莺可以接收各类监控系统的告警统一做事件通知吗？
有些朋友看到夜莺可以对接各类时序库，做告警判断生成告警事件并分发，就想说，那我其他的监控系统产生的告警能否也交给夜莺去发送呢？这样就可以统一管理告警通知模板、联系人、认证登录权限等问题。
实际是不行的。这是一个典型的事件 OnCall 需求，收集各个监控系统（比如 Prometheus、Zabbix、Open-Falcon、蓝鲸、各类云监控、ElastAlert 等）的告警，统一做告警收敛降噪、排班、认领升级、按条件灵活分发等，这个需求要想做好，值得用一个单独的产品来搞，我们姑且称这个产品为 OnCall 产品。OnCall 产品和各个监控系统之间的关系是：
即：监控系统（包括各类云监控）重点把数据采集、存储、可视化分析、告警判定这些问题解决好，负责产生告警事件，之后告警事件就交给 OnCall 中心来处理即可，OnCall 中心来负责告警事件的收敛降噪、抑制屏蔽、过滤分发等等诸多事宜。
好的 OnCall 产品都是商业产品，比如 PagerDuty、FlashDuty、Opsgenie 等，大家可以自行 Google，各取所需。
夜莺比 Prometheus 还多了啥有意思的功能？
这里我随便截几张系统图，略作介绍。
夜莺不做采集，可以对接市面上各类采集器，其中，categraf 采集器和夜莺的对接最为丝滑，使用 categraf 作为采集器的话，可以采集机器的各类元信息，构建一个轻量的机器层面的 CMDB。
夜莺内置提供告警自愈的能力，即告警时可以自动到告警的机器上执行脚本，你可以在脚本里写一些自动化的修复逻辑。
夜莺内置提供了指标视图，会在 v7 beta3 版本放出，会内置提供很多常用的 promql，点击查询即可，对小白用户会极为友好。
小结
已经有 Prometheus 了，为啥还需要夜莺（Nightingale）？本文算是对这个问题的一个探索性回复。希望对你有帮助，感谢大家的阅读。
