滴滴夜莺监控发布 v5 正式版，定位 Prometheus 企业版

大家好，经过几个月的研发，夜莺 v5 正式版跟大家见面了，这个版本做了巨大的产品定位调整，不再是一个运维平台，而是专注监控告警这个细分领域，拥抱 Prometheus 生态，争取把监控这个事情，做到极致！这是新版的截图，给大家一个直观的认识先。

这个版本的功能设计全部是围绕监控告警来的，比如告警规则、屏蔽规则、订阅规则的管理，活跃告警、历史告警的查看，监控数据查看，提供不同的看图视角，监控对象的管理，告警自愈机制，人员权限等等

为啥开始拥抱 Prometheus 生态呢？

核心是 PromQL 的能力，作为一款完备的监控产品，一定要具备 QL 的能力，否则灵活性将大大降低，之前 Open-Falcon 或者 Nightingale 的老版本，只能通过标签做匹配，灵活性不好，需要把一些计算逻辑前置到采集侧，新版本我们想解决这个问题，但是重复造轮子也不可取，所以就沿用了 PromQL 的能力。

这个版本非常的开放，不止可以和 Prometheus 深度集成，也可以和 Telegraf、Grafana、Grafana-Agent、Datadog-Agent、VictoriaMetrics、M3DB 等良好协同，没有软件绑定问题。

与 Open-Falcon 的区别

因为开发 Open-Falcon 和 Nightingale 的是一拨人，所以很多社区伙伴会比较好奇，为何要新做一个监控开源软件。核心点是 Open-Falcon 和 Nightingale 的差异点实在是太大了，Nightingale 并非是 Open-Falcon 设计逻辑的一个延续，就看做两个不同的软件就好。

Open-Falcon 是 14 年开发的，当时是想解决 Zabbix 的一些容量问题，可以看做是物理机时代的产物，整个设计偏向运维视角，虽然数据结构上已经开始设计了标签，但是查询语法还是比较简单，无法应对比较复杂的场景。

Nightingale 直接支持 PromQL，支持 Prometheus、M3DB、VictoriaMetrics 多种时序库，支持 Telegraf 做监控数据采集，支持 Grafana 看图，整个设计更加云原生，虽然也保留了机器归组的逻辑以应对物理机时代的需求，但是设计上，更倾向于使用标签来分组，而不是 HostGroup 或者树形结构。

与 Prometheus 的区别

Nightingale 可以简单看做是 Prometheus 的一个企业级版本，把 Prometheus 当做 Nightingale 的一个内部组件-时序库，当然，也不是必须的，时序库除了 Prometheus，还可以使用 VictoriaMetrics、M3DB 等。各种 Exporter 也可以继续使用，不过我们更推荐使用 All-in-one 的 Telegraf，运维代价会更小一些。

Nightingale 可以接入多个 Prometheus/M3DB/VictoriaMetrics，可以允许用户在页面上配置告警规则、屏蔽规则、订阅规则，在页面上查看告警事件，配置告警自愈机制，管理监控对象，配置监控大盘等，就把 Nightingale 看做是 Prometheus 的一个 WEBUI 也是可以的，不过实际上，它远远不止是一个 WEBUI，用一下就会深有感触。

夜莺 v5 版本架构

夜莺 v5 的设计非常简单，核心是 server 和 webapi 两个模块，webapi 无状态，放到中心端，承接前端请求，将用户配置写入数据库；server 是告警引擎和数据转发模块，一般随着时序库走，一个时序库就对应一套 server，每套 server 可以只用一个 server 实例，也可以多个实例组成集群，server 可以接收 Telegraf 上报的数据，写入后端时序库，周期性从数据库同步告警规则，然后查询时序库做告警判断。每套 server 依赖一个 redis。架构图如下：

对夜莺有兴趣的小伙伴可以加入我们的钉钉群交流（微信群二维码只有 7 天有效期，所以用钉钉群了）：

新版本的文档放到了 gitee.io，地址是 https://n9e.gitee.io/ 感谢开源中国提供的平台，访问速度挺快的 :)