1 夜莺-Nightingale 项目介绍
夜莺监控是一款开源云原生观测分析工具，采用 All-in-One 的设计理念，集数据采集、可视化、监控告警、数据分析于一体，与云原生生态紧密集成，提供开箱即用的企业级监控分析和告警能力。夜莺于 2020 年 3 月 20 日，在 github 上发布 v1 版本，已累计迭代 100 多个版本。
夜莺最初由滴滴开发和开源，并于 2022 年 5 月 11 日，捐赠予中国计算机学会开源发展委员会（CCF ODC），为 CCF ODC 成立后接受捐赠的第一个开源项目。夜莺的核心研发团队，也是 Open-Falcon 项目原核心研发人员，从 2014 年（Open-Falcon 是 2014 年开源）算起来，也有 10 年了，只为把监控这个事情做好。
项目代码：
1.1 项目截图
1.2 V7 版本介绍
夜莺最新版本是 V7，V7 重点做体验优化，和 V5、V6 完全兼容，升级方法见这里。当前已经发布 10 几个 V7 beta 版本，虽然名义上是 beta 实际已经非常稳定，可以用于生产，只是因为运营营销的诉求，固定每年 7 月底发布正式版。V7 会是一个 LTS 版本，社区会在未来两年持续维护，而 V5 以及之前的老版本将不再提供支持，建议尽快升级到 V7。V7 已完成的一些关键改动如下：
- 全站支持暗黑主题
- 新增指标视图，内置上百个 promql，无需手写 promql 即可方便地查看监控数据
- 新增模版中心，支持创建和修改模板，模版可以在一个地方集中维护和查看，模板中预置了各类组件的仪表盘、告警规则、指标等，参看这里
- 优化边缘机房机器失联告警的实现逻辑，真正做到边缘机房告警自闭环，注意架构上做了微调，n9e-edge 需要用到 redis
- 全局回调地址页面展示优化，增加详尽的文档提示信息
- 支持通过回调地址直接发送告警信息到钉钉、飞书、企微等，进一步简化告警规则配置，参看这里
- 内置集成故障自愈能力，不需要再单独部署 ibex 模块，ibex 的 DB 和 n9e 的 DB 合二为一，你会看到 DB 中出现 100 多张 ibex 用到的表
- 仪表盘变量支持和本业务组的机器联动，不同业务组组下的仪表盘只展示本业务组内的机器
- 机器列表和指标视图打通，可以选择多台机器直接看图，无需任何提前配置
- 告警规则，支持配置恢复时的 Promql，告警恢复通知也可以带上恢复时的值了，参看这里
- 支持集成仪表盘，可以将 grafana 的仪表盘集成到夜莺中，参看这里
2 架构介绍
夜莺依赖 MySQL 存储各类用户配置，比如告警规则、屏蔽规则、仪表盘，依赖 Redis 存储一些机器心跳上来的元信息以及 jwt token，除此之外，没有别的依赖。
2.1 仅把夜莺作为告警引擎
如果只是把夜莺当做页面化的告警引擎，对接多个时序库做告警判断，其架构如下：
- 这个架构下，夜莺就类似 Grafana（Grafana 侧重看图，夜莺侧重告警），可以接入多种不同的数据源，比如 Prometheus、VictoriaMetrics、M3DB、Loki、TDEngine 等等，在夜莺中配置管理告警规则，夜莺周期性去查询各个存储，判定异常数据，产生告警事件
- 夜莺可以直接通过钉钉、企微、邮件等方式发出告警事件，也可以对接 FlashDuty，做告警聚合降噪之后再由 FlashDuty 做后续分发。
- 这个架构下，数据不流经夜莺，n9e 进程的配置文件中无需配置
[[Pushgw]]相关配置，只需要 MySQL、Redis 就位即可启动 - 如果你之前的数据采集是使用 Prometheus 生态的各类 Exporter，数据已经完成采集进入了 TSDB，那就很适合这种使用姿势。这种方式下，核心就是使用夜莺作为告警引擎，把各种监控数据源的告警规则集中管理，统一告警事件的分发，而监控数据的采集、传输，夜莺都没有介入。
- 这个方式下，无需 categraf 组件，机器列表为空，无法使用告警自愈功能，不过基本的告警、看图都是支持的。这种模式下的用户，其实看图一般会继续沿用 Grafana，仅使用夜莺作为告警引擎，统一管理各个时序库的告警规则配置。
如果我们想让夜莺把监控数据的采集、传输也做了，那就要使用 2.2 了。
2.2 时序数据流经夜莺
夜莺本身其实不做监控数据采集，只是提供各类监控数据接收接口，然后转存到时序库。监控数据采集社区有很多选择，夜莺社区推荐大家使用 Categraf 作为采集器，通过心跳方式自动上报信息，填充夜莺里的机器列表，也支持使用告警自愈功能。当然，也可以使用其他采集器，比如 Grafana-agent、Telegraf 等，使用这些采集器的话，也可以在夜莺中看到机器列表，只不过机器列表中的大部分字段都是 unknown，无法使用告警自愈功能，基本的机器失联告警、指标告警、看图等，都没问题。
社区经常有人问，夜莺可以监控 xxx 吗？从上面的解释可以看出，夜莺啥都可以监控，又啥都监控不了，因为夜莺本身不做监控数据采集，只要你通过某个采集器采集到了监控数据，夜莺就可以对这些数据做告警判断。这个方式下，其架构图如下：
上例中同时举例了指标和日志两种数据的处理流程。
- 指标使用 Categraf 采集（就是那个猫爪样式的图标），推送到夜莺（通过 Prometheus remote write 协议，需要在夜莺的配置文件中配置
[[Pushgw]]，可以配置多个时序库，即配置多份[[Pushgw.Writers]]，夜莺就会把数据同时分别转发给 Writers 中的地址），夜莺把数据转存到时序库（此处以 VictoriaMetrics 举例，也可以写入 Prometheus 等其他时序库），之后把 VictoriaMetrics 作为一个数据源接入夜莺 - 日志使用 Vector 采集推送给 ElasticSearch，然后把 ElasticSearch 作为一个数据源接入夜莺。开源版本中，日志类型的数据不流经夜莺，采集器建议使用 Vector，也可以使用 Filebeat、iLogtail、Loggie、Fluentbit、Categraf 等其他采集器，最终数据进入 Loki 或者 ElasticSearch，然后把 Loki 或者 ElasticSearch 作为数据源接入夜莺
当然了，实际生产场景可能会更复杂，比如有多个数据中心，每个数据中心都有多个时序库多个日志库，不同数据中心之间要考虑机房网络割裂的问题，如果发生网络割裂，希望机房内部告警自闭环不受网络故障影响，平时网络链路好的时候，又希望在中心端统一查看指标、日志。这些问题都是可以解决的，后续在其他章节详述更复杂的架构设计。
3 对比Prometheus
如果您当前使用的是 Prometheus，而且没有痛点，那么就不需要考虑夜莺了，用好现在的体系就可以了。如果您用了多个时序库，比如 Prometheus、VictoriaMetrics、Thanos 等等，需要一个统一的平台来管理告警、看图，夜莺是一个选择。如果您想把监控的能力开放给公司所有研发团队，让研发团队自助服务，觉得 Prometheus 使用配置文件的告警规则管理方式不方便，夜莺是一个选择。如果您需要更为灵活的告警策略配置，比如控制生效时间、一套规则生效多个集群，夜莺是一个选择。如果您需要告警自愈能力，告警之后自动执行个脚本啥的，夜莺是一个选择。如果您需要一个统一的事件 OnCall 中心，聚合各个监控系统的告警，做统一的告警聚合降噪、排班认领升级、灵活的分发和协同，FlashDuty 是一个选择。
另外，相比 Grafana，夜莺的看图能力还是差一些，因为 Grafana 是 agpl 协议，我们也没法封装 Grafana 进夜莺，所以夜莺的看图是自研的，和 Grafana 没法 100% 兼容，当然，夜莺支持导入 Grafana 的仪表盘 JSON，基础的图表都是兼容的（但是导入体验做的还不好，这是一个巨大无比的工程）。另外，夜莺设计了内置告警规则和内置仪表盘，方便用户开箱即用，现在覆盖了常用组件，后面随着时间推移，这个体验也会越来越好，期待大家一起共建。
以笔者观察来看，很多公司是一套组合方案（成年人的世界，没有非黑即白，都要）：
- 数据采集：组合使用了各种 agent 和 exporter，比如使用 Categraf，辅以各类 Exporter
- 存储：时序库主要使用 VictoriaMetrics，因为 VictoriaMetrics 兼容 Prometheus，而且性能更好且有集群版本，对大部分公司，单机版就足够用了
- 告警引擎：使用夜莺，方便不同的团队管理协作，内置了一些规则开箱即用，告警规则的配置比较灵活
- 看图可视化：使用 Grafana，图表更为炫酷，社区非常庞大，从 Grafana 站点可以找到很多别人做好的仪表盘，直接导入即可
- 告警事件 OnCall 分发：使用 FlashDuty，聚合了 Zabbix、Prometheus、夜莺、Open-Falcon、云监控、Elastalert 等各类告警事件，统一聚合降噪、排班、认领升级等。开源夜莺不提供日志告警能力，很多人会白嫖 FlashDuty 的日志告警能力，参看这里。