滴滴夜莺是新一代智能监控系统，经受了滴滴生产环境海量数据验证

一、开源项目简介

夜莺是新一代国产智能监控系统。对云原生场景、传统物理机虚拟机场景，都有很好的支持，10分钟完成搭建，1小时熟悉使用，经受了滴滴生产环境海量数据的验证，希望打造国产监控的标杆之作，一起参与进来吧！

Nightingale在2020.3.20发布v1版本，目前是v5.0版本，从这个版本开始，与Prometheus、VictoriaMetrics、Grafana、Telegraf等生态做了协同集成，力争打造国内最好用的开源运维监控系统。

二、功能概述

人员组织

虽然人员组织这个菜单是放到了最后，但是文档里还是要先讲一下，绝大部分功能都依赖业务组这个概念。不过一旦业务组创建完成，就基本不怎么变动操作了，所以菜单放到了后面。

用户管理

简单，就是管理系统中的所有用户，系统默认会初始化进去一个root账号，这个root账号是个管理角色，可以创建其他普通用户、修改其他用户的信息。用户认证也可以对接LDAP，这样就无需管理员去创建用户了，LDAP的配置在webapi.conf中。

团队管理

团队就是用户组，包含多个用户。主要有两个作用：1、作为告警接收组，配置告警规则的时候，可以通过指定告警接收组的方式告诉系统当发生告警的时候通知哪些人；2、管理业务组，业务组下可以有多个团队，有的团队是ro权限，即只读，有的是rw权限，即读写权限。

业务组管理

业务组相当于一个namespace，下面可以包含用户组、监控对象、告警规则、订阅规则、屏蔽规则、监控大盘、自愈脚本等，是一个可以自闭环的组织，类似一个BU，或者大的业务线。当然，一些小的组织，如果管理（主要是指管理监控对象、告警规则等）上可以自闭环（无需假手其他团队，自己这个团队就能搞定），也可以创建一个单独的业务组。比如夜莺研发团队，管理了100台机器，部署了夜莺的服务，这些机器、这些服务/机器的告警规则都是夜莺研发团队自己搞，那完全可以创建一个夜莺的业务组自己去管理。

对象管理

对象管理主要是针对机器和网络设备的管理，如果监控数据推送给n9e-server，n9e-server会从监控数据结构中解析出监控对象的标识信息（标签中的ident或host字段），然后把监控对象信息写入数据库，之后，用户可以在对象管理页面，对监控对象做管理：包括分配这些对象给指定的业务组、给这些监控对象设置标签、修改备注等。

这个版本的夜莺，取消了之前版本的树状结构，主要是靠业务组+标签的方式来配合解决机器分组的问题，关于这块的设计，有一篇文章来专门探讨：《探讨业务组的设计和最佳实践》

监控看图

为了让大家尽量用一个平台搞定监控告警的所有事情，夜莺中内置了查看监控数据的能力，包括即时查询（就是类似PromDash的看图能力）、监控大盘（是类似Grafana的Dashboard配置，不过图表类型支持较少）、对象视角看图（是一个先选择监控对象再看相关监控数据的特殊视角，运维工程师会很喜欢）

即时查询

解决以下问题：

• 检查某个监控数据是否在正常上报
• 测试promql，测试好的promql用于配置告警规则
• 生产环境故障，临时查一些监控指标的数据

监控大盘

解决以下问题：

• 日常巡检
• 知识传递，由专业的人做好大盘，新同事看这些大盘能更便于理解和达成监控目标
• 生产环境故障，查看监控数据

对象视角

在夜莺系统里，认为监控对象是个很关键的概念，值得赋予一定的管理功能。比如很多监控数据都隶属于某个监控对象，比如某个机器的磁盘利用率，或者某个交换机的某个网口的流量，那在查看这些监控数据的时候，我们会倾向于先找到对应的监控对象，再根据监控对象查找相关监控指标。对象视角的看图方式，就是为此而生。

什么样的监控数据认为是隶属于某个监控对象的？就看监控数据中是否有ident这个tag，如果有，就认为ident指定的是监控对象的标识，就认为这条监控数据是关联到某个监控对象的，当然，Telegraf采集的监控数据，会打上host标签，标识这个监控数据是来自哪个机器，host这个标签会被夜莺rename成ident。

告警管理

夜莺对告警的处理，分为3个规则的管理：告警规则、屏蔽规则、订阅规则；活跃告警和历史告警的展示；以及告警自愈。

告警规则

最主要用的是告警规则，用于配置告警阈值，有些监控数据可能不想告警，比如有规划的维护周期，可以配置屏蔽规则，某个告警除了某个组的人关心，可能其他人也关心，就配置订阅规则，比如K8S平台的运维人员要作为告警接收人来接收所有K8S的告警，但是K8S的一些重大网络故障会影响整个K8S集群，上层业务也会关心这类告警，此时业务方就可以订阅K8S集群的部分重大告警。

对于订阅规则，还有一种场景，比如运维团队管理了公司所有的告警规则，比如内存利用率的告警，不同业务线的人只关心自己的，那不同业务线的人就可以通过订阅规则，只订阅自己业务线的机器的告警。只需简单的为这批机器打上业务线标签，就可以通过这些标签做过滤。

告警事件

活跃告警，即当前未恢复的告警，这个信息很关键，通常每天都要巡检，甚至投到作战大屏上，时刻关注；历史告警，就是所有历史告警，包括报警消息和恢复消息，算是一个存档。

告警自愈

告警自愈是类似夜莺v4里边的job平台，可以在告警发生的时候，自动触发某个脚本的执行，比如某个宿主机报警说硬盘不够用，可以自动跑个脚本清理一下无用的数据，比如K8S宿主机的话，可以清理一些没用的镜像。

三、技术选型

• Go 94.2%
• TSQL 4.9%
• Smarty 0.5%
• Shell 0.3%
• PLpgSQL 0.1%

系统架构

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

与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，用一下就会深有感触。

四、界面展示

五、开源协议

使用Apache2.0开源协议