夜莺5.0发版之后，前面两周社区反馈了一些问题，做了集中修复系统很快稳定了，感谢社区小伙伴们的支持。近期又增加了一些新的优化项，这里给大家罗列一下，有兴趣的小伙伴可以升级尝试。

注意：如果是从低版本升级上来，要注意查看github的releases页面，挨个执行各个版本的SQL变更，二进制和前端静态资源文件可以一次性升级到最新版

支持了grafana-agent作为采集器

很多小伙伴可能习惯使用Prometheus的各类exporter，但是这些exporter直接通过prometheus.yml中的抓取规则抓取，数据直接写入了时序库，没有流经n9e-server，这样n9e-server无法从中解析到监控对象，导致页面上看监控对象列表为空，无法使用对象视角看图。

grafana-agent相当于是内置了各类常见的exporter，然后grafana-agent通过push的方式推送监控数据给服务端（走的是remote write协议），无需在prometheus.yml中配置抓取规则，而n9e-server的新版本实现了remote write协议，所以grafana-agent可以直接推送监控数据给n9e-server，这样数据就流经了n9e-server，n9e-server就可以从监控数据中解析出监控对象。

grafana-agent会把所在机器的机器名放到agent_hostname这个标签中，n9e-server会取这个标签的值当做监控对象，rename成ident，n9e-server的接收grafana-agent的接口地址是/prometheus/v1/write，配置到grafana-agent的配置文件中即可。

支持了datadog-agent作为采集器

datadog作为10多年的商业产品，其agent的采集能力是非常丰富的，但是datadog-agent不只支持metrics采集，还有日志、metadata等数据上报，而n9e-server只是实现了其metrics上报的接口，所以其他接口因为没有对应实现会报错，对于处女座用户会比较难受，不知道datadog-agent是否支持配置，只开启metrics上报，如果可以把其他上报逻辑通过配置关闭就好了，对这块感兴趣的小伙伴可以研究下。

另外Telegraf也支持datadog的协议上报，可以使用Telegraf的datadog output plugin上报数据给夜莺，这种方式可以支持token认证机制。

支持open-falcon的数据格式上报

open-falcon数据上报分两种情况，一种是rpc的方式，一种是http的方式，因为夜莺只提供了http接口，所以采用rpc方式的falcon-agent是没法上报数据给n9e-server的，那这个特性是不是完全没用了？也不是，有些falcon的插件，采集到数据之后是通过http接口推送给transfer的http接口的，这种就可以把数据推送给n9e-server了

告警规则持续完善，支持了更多特性

首先是留观时长，原来的逻辑是告警之后如果有一个点不符合条件了就会立马触发恢复通知，新增留观时长配置，可以支持再额外观察一段时间，比如告警之后虽然有一个点不符合条件了，继续观察3分钟，如果未再触发告警才真正恢复。

其次是支持了告警规则只在本业务组生效的配置，默认告警规则是对时序库里的所有数据生效的（并不会依据业务组和机器的归属关系，如果想做更细粒度划分，可以为机器打标签，标签会附到时序数据上，会进入时序库），比如cpu_usage_idle < 5报警，公司的任意一台机器符合条件都会告警。比如有a、b两台机器，a机器属于业务组a，b机器属于业务组b，在a业务组配置的cpu_usage_idle告警规则，b机器如果触发了阈值也会告警。有些朋友觉得这样不合适，希望a业务组的规则只针对a业务组下面的机器生效，b业务组的规则只针对b业务组下面的机器生效，所以增加了“是否只在本业务组生效”的配置项。

其次是修改重复发送（即所谓的通道静默时间）的逻辑，每次重复发送告警的时候，都把当前最新的告警值发出来。

其次是修改钉钉告警的通知方式，支持了markdown的方式，大家可以更方便的定义通知模块，显示效果会更好一些。

其次是支持了飞书告警方式，这样一来，就支持了钉钉、企微、飞书、邮件四种方式，当然，因为告警是用python脚本发送的，大家也可以非常轻易的来扩展一种新的通知机制。

其次是支持了GlobalCallback，这种方式可以和统一的事件管理中心较方便的打通，所有的告警事件，不但会统一走Redis的Pub，也会统一走一次全局callback，未来也会支持把告警事件统一推送给MQ或者Kafka。

完善对后端时序库的读取配置

首先是支持了basic auth认证，增强安全性，其次是对于Prometheus部署在K8S前面有ingress的场景做了支持，把Host头补充上，之前n9e-server对时序库的proxy逻辑里缺少了这块的设置。

其他一些相对较小的改动如下

• LDAP账号登陆之后自动插入user表中一条记录，其角色默认设置为Standard，而且默认角色支持配置

• 大盘变量label_values解析增强，对象列表增加start和end参数，避免不再上报监控数据的索引一直存在

• 修改Prometheus的Querier接口和事件详情的访问控制逻辑，允许通过配置文件控制是否匿名访问

• 业务组创建时，其管理团队是必填项，且至少有一个rw权限的团队

• 管理员可以看到所有团队列表，而不止是看到自己所属的团队，防止团队成员全部离职没有人再来管理这个团队的情况

• 优化了大盘更新逻辑、一键规整逻辑、大盘变量在一条promql中重复出现没有replace的问题

• 还有一些其他的易用性改进以及一些bugfix，这里就不一一列举了，欢迎大家升级到最新版本试用体验

写此文章时，夜莺最新版本是：5.3.4，可以从github的releases页面找到编译好的二进制。有些小伙伴可能还不知道夜莺是什么，附下面一段介绍：

夜莺最初是由滴滴开源，其开发团队和Open-Falcon的开发团队是一拨人，随着云原生的流行，夜莺逐渐专注到云原生的监控领域，和Prometheus生态紧密结合，姑且可以看做是Prometheus的一个企业级版本。

当然了，夜莺不但支持Prometheus作为时序库，还支持VictoriaMetrics、M3DB、Thanos等其他的时序库。采集层面也是兼容并包，支持Telegraf、Grafana-agent、datadog-agent等多种采集器，也支持集成Prometheus生态的各类exporter。

其实Prometheus在云原生监控领域已经是王者，但是会有两个典型的需求：

1、我已经构建了一套Prometheus，自己用着也不错，但是我想把监控能力开放给业务研发同学，让他们能够自运营，比如自己配置告警规则、屏蔽规则、订阅规则、监控大盘等，这就需要有一个权限控制的UI

2、公司业务线众多，有多套Prometheus，我想有个地方来统一管理，形成统一的平台，在一套平台上就可以同时管理多个Prometheus的规则。

夜莺可以解决上面这俩问题，不过她的能力远不止此，夜莺还对设备监控有些额外的视图支持，对告警自愈有支持，这些就需要大家去查看文档了，这里不再赘述，夜莺的文档在 n9e.gitee.io 其架构图如下：

欢迎大家一起到夜莺开源社区探讨监控的经验，我们希望专注在这个领域，把监控告警这个事情，做到极致！