夜莺 V6 的核心变化，是从“开源监控系统”向“开源可观测平台”升级。6.0 beta 版本开始支持 Metrics、Logging、Tracing 三类数据接入思路，可以接入和管理 Prometheus、ElasticSearch、Jaeger 等数据源，并把数据可视化、告警和分析能力放到同一个平台中。
核心要点
- 数据源管理前移到页面：Prometheus 兼容数据源、ElasticSearch、Jaeger 等都可以通过页面管理。
- 服务端架构简化：5.x 的
n9e-webapi、n9e-server在 6.x 中默认合并为一个n9e模块。 - 经验能力内置：内置监控大盘、内置告警规则、机器失联和时间偏移等能力进一步产品化。
- 告警治理增强：告警规则、屏蔽规则、订阅规则继续补齐细节，支持更灵活的运维场景。
- 社区方向明确：夜莺 V6 是项目从监控走向可观测性的关键版本。
可以在页面管理数据源
V6 开始，数据源管理不再主要依赖配置文件中的 Clusters 配置，用户可以直接在页面上管理数据源。除了兼容 Prometheus 查询协议的数据源，也支持 Jaeger 和 ElasticSearch 作为数据源接入。
可以接入 ElasticSearch 数据源
ElasticSearch 接入体验类似 Grafana：配置已有 ElasticSearch 数据源后，可以在夜莺中查看 ElasticSearch 数据，监控大盘中的图表数据也可以从 ElasticSearch 获取。
这意味着夜莺不再只围绕指标数据展开，日志数据也可以进入同一个可视化和分析界面，为后续指标、日志、链路之间的关联分析打基础。
架构做了简化
Nightingale 5.x 的版本，至少需要 n9e-webapi 和 n9e-server 两个模块，6.x 开始默认只需要一个模块了，就叫 n9e。我们先来回顾一下 5.x 的架构：
假设两个集群，Region01是中心机房，部署了一整套夜莺，Region02和Region01的网络链路不好，所以Region02单独搞了一套 TSDB，n9e-server 跟随 TSDB，所以 Region02 也部署了一套 n9e-server。图上其实少画了 Redis，n9e-webapi 和 n9e-server 都依赖 Redis，可以全局用一个 Redis，也可以每套 n9e-server 部署自己的 Redis。
6.x 版本把 webapi、pushgateway、alerting 模块合并为一个 n9e 模块。这个模块可以对接多个数据源，也可以部署多个实例组成集群。对大多数用户来说，默认架构更容易理解，部署和升级的心智负担也更低。
如果某个机房和中心机房之间网络链路不好，也可以在边缘机房下沉部署一套时序库和告警引擎。除了 n9e 模块，V6 也单独提供 n9e-pushgw（数据转发网关）和 n9e-alert（告警引擎）。这两个模块是可选组件，主要用于边缘机房网络链路较差的场景。
| 场景 | 推荐方式 |
|---|---|
| 单中心或网络稳定的多机房 | 默认部署 n9e |
| 边缘机房到中心网络不稳定 | 下沉部署时序库、n9e-pushgw、n9e-alert |
| 需要降低日常维护复杂度 | 优先使用默认一体化模块 |
可维护性提升
除了架构方面做了简化，降低了维护复杂度，很多配置也挪到页面上管理了。比如单点登录相关的配置、告警发送模板相关的配置：
角色管理也挪到页面上了，不用像 5.x 的版本那样，只能通过修改数据库创建新的角色了。
这些变化的直接价值，是把“只有熟悉配置文件和数据库的人才能维护”的工作，变成更多团队成员可以在页面上协作完成的工作。
增加内置监控大盘
5.x 版本已经有内置监控大盘，但需要把内置大盘导入到自己的业务组中使用。6.x 开始提供内置大盘浏览页面，不导入业务组也可以直接查看。
内置大盘的意义不是替代所有自定义大盘，而是把常见组件、常见场景的监控经验先沉淀下来，让新用户更快完成第一轮观测能力建设。
增加内置告警规则
同理，V6 内置了各类组件的告警规则，减少用户从零编写规则的成本。内置规则解决的是通用起点问题，真实生产环境仍需要结合业务重要性、容量水位、值班策略和噪音治理目标进行调整。
继续优化告警规则
附加标签支持变量了，于是，我们可以对告警的vector的标签做一些二次处理。
对于机器失联告警、机器时间偏移做了更好的实现。废弃了原本的 target_up 指标的生成逻辑，在告警规则里直接内置支持了机器失联告警和时间偏移告警，甚至，额外增加了机器失联比例告警。
阈值告警也做了优化：一个告警策略里可以配置多个规则，指定不同级别，并支持级别抑制。高级别告警触发后，可以抑制低级别告警，避免同一问题重复通知。
商业版本则更加强大，不止支持普通的阈值告警，还支持算法告警引擎、SLS告警引擎等。如有需要欢迎 联系我们，做产品交流、试用产品，合作共赢 :)
顺便介绍一下告警规则的多时间段配置，其实 5.15 版本就支持了，但是很多人不知道，借此机会也一并说一下。这个功能是社区提出的，对于一些特定的场景非常有用。
继续优化屏蔽规则
屏蔽规则增加了周期性屏蔽能力，适合定期发布、固定维护窗口、周期性任务扰动等场景。对值班团队来说，周期性屏蔽可以减少已知噪音，避免重复创建临时屏蔽规则。
继续优化订阅规则
订阅规则引入了“订阅事件持续时长超过（秒）”的配置，一定程度上可以实现告警升级效果。不过，相比完整的告警事件中心，它还不包含认领、排班、升级、协同等完整流程。如果需要接收各类监控系统的告警事件，并统一做告警降噪、认领、升级、排班和协同，可以使用 Flashduty。
另外，订阅规则可以重新定义回调地址，可以对一些特定的告警事件做自动化处理，比如把特定的告警事件发给Flashduty~~
夜莺开源社区发展和治理
夜莺监控，于2022 年 5 月 11 日，正式托管于中国计算机学会开源发展委员会（CCF ODC），为 CCF ODC 成立后接受捐赠的第一个开源项目。在计算机学会的支持和带动下，在快猫星云和众多公司的持续投入下，和数千名社区用户的积极参与，截止当前，夜莺开源项目在 Github 上获得了 6K star，1K fork，近 100 位 Contributor，夜莺开源社区展现出了蓬勃的生机。
夜莺 V6，是夜莺监控往全栈可观测性解决方案迈进的关键一步，是夜莺项目管理委员会和夜莺开源社区共同努力的成果。
快猫星云是一家云原生智能运维科技公司，也是夜莺项目管理委员会的核心成员，专注于为企业提供全栈可观测性解决方案以及构建企业级的稳定性保障体系 👉👉 如有需要欢迎 联系我们，做产品交流、试用产品，合作共赢:)
夜莺开源项目大事记
- 2020 年 3 月，夜莺监控由滴滴技术正式在 Github 开源，凭借其优秀的产品设计、灵活性架构和明确清晰的定位，夜莺监控快速发展为国内最活跃的企业级云原生监控方案。
- 2022 年 5 月 11 日，夜莺监控正式捐赠予中国计算机学会开源发展委员会 CCF ODC，为 CCF ODC 成立后接受捐赠的第一个开源项目。
- 2022 年 8 月 1 日，发布夜莺监控开源社区治理架构，并公示相关的任命和社区荣誉。
- 2023 年 3 月 9 日，夜莺 V6 全新发布，夜莺监控升级为开源观测平台。
FAQ
Q1：夜莺 V6 和 V5 最大区别是什么？
A：V6 默认把多个服务端能力合并到 n9e 模块中，同时把数据源管理、权限、模板、内置大盘和告警规则等能力进一步页面化、产品化。
Q2：夜莺 V6 是否只支持指标数据？ A：不是。V6 开始向 Metrics、Logging、Tracing 方向扩展，本文重点提到 Prometheus、ElasticSearch、Jaeger 等数据源接入。
Q3：内置告警规则可以直接用于生产吗？ A：可以作为起点，但不建议不加评估地直接全量使用。生产环境需要结合业务影响、阈值水位、通知策略和告警噪音情况做调整。
交流
欢迎各位小伙伴安装试用 👉 部署指南 👈 可观测性这个事，我们是认真的！
