夜莺监控 v8 第一个版本来了，开始做有意思的功能了

干不动了伙计们，老板说每天导它个 5000 App 下载

夜莺 v8 大版本已经启动开发，预计 25 年 7、8 月份发正式版，相比 v7 大概会做四五个大功能，每个功能做完了做稳定了都会提前放出来供大家体验，虽然以 beta 来命名，实际是稳定的，大家可以放心升级。

夜莺 v5 v6 v7 三个大版本算是一脉相承，一直在打基础，最后一个稳定版是 v7.7.2，可以看作是这个系列的终极版。其实这个系列中有些功能早就想改进了，但是由于兼容性、迁移成本、人力的考虑，一直没有动作。现在基础打好了，从 v8 开始，我们计划开始做一些有意思的功能。当然，也不会完全不兼容 v7，v7 用户还是可以直接升级的，只是我们会通过 feature flag 等方式，在某些功能上引入一些新的做法。

v8 重点想做的事情如下：

• 改造部署方式，减少依赖，没有 mysql、redis 也可以一键拉起，这样做功能测试就简单多了
• 机器相关的告警规则不止可以通过 promql 来定义，还可以和业务组打通，比如不同的业务组机器，阈值不同
• 大幅重构告警通知逻辑，支持灵活的分派策略、更方便的自定义通知媒介、同一媒介支持多个通知模板
• 支持更多数据源的告警，比如 ElasticSearch、ClickHouse 等，力争把夜莺打造成一个统一的告警引擎
• 提供新的、更直观的仪表盘功能，虽说无法像 Grafana 那样支持如此多的图表类型，至少把现有的做稳定好用

当然，还会有很多其他小改动计划，这里就不一一列举了。这两天发了 v8.0.0-beta.1 版本，已经完成了一些有意思的功能。下面给大家介绍一下。

部署方式改造

v8.0.0-beta.1 版本中，我们引入了 sqlite 和 miniredis，不再依赖 mysql、redis，这样就可以用一个二进制一键拉起了，测试时就方便多了。不过这种方式仅适合个人功能测试，还不能用于生产环境。生产环境还是需要 mysql、redis 的。

下面我来演示一下如何一键拉起 v8.0.0-beta.1 版本。

到如下地址下载 v8.0.0-beta.1 版本的发布包：https://flashcat.cloud/download/nightingale/

我本地有一个 arm64 的 linux 虚机来做测试，所以下载了 arm64 版本的发布包 n9e-v8.0.0-beta.1-linux-arm64.tar.gz。解包之后直接运行夜莺的二进制即可。操作如下：

 wget https://download.flashcat.cloud/n9e-v8.0.0-beta.1-linux-arm64.tar.gz mkdir n9e-v8.0.0-beta.1-linux-arm64 tar zxvf n9e-v8.0.0-beta.1-linux-arm64.tar.gz -C n9e-v8.0.0-beta.1-linux-arm64 cd n9e-v8.0.0-beta.1-linux-arm64 ./n9e 

哦了。超级简单。接下来可以在夜莺的页面上接入数据源，类似 Grafana，然后即可对数据源的数据做告警、查询分析等。

如果你想采集监控数据，选择就比较多了，比如：

• 复用你以前的 Prometheus 摘取 Exporter 的模式，只要数据进入 Prometheus 了，你就可以在夜莺里配置告警规则、看图查询
• 使用 Categraf 采集监控数据，尤其是机器层面的监控数据。此时 Categraf 的 writer 的地址和 heartbeat 地址都配置为 n9e 的地址，然后 n9e 的配置文件中配置时序库的地址即可，即 Categraf 通过 heartbeat 请求把本机的元信息上报给 n9e，n9e 存入 mysql 和 redis，Categraf 通过 writer 请求把监控数据上报给 n9e，n9e 存入时序库（在 n9e 的配置文件 config.toml 中指定，就是 Pushgw 相关的那些配置项）。

告警规则支持使用业务组筛选机器

这是一个重大的改造。想解决特殊机器的阈值配置问题。举个例子，假设 DBA 团队有 100 台机器，默认情况下，希望 cpu_usage_idle < 20 告警，但是有几台机器比较特殊，CPU 核数较多，希望 cpu_usage_idle < 15 才告警。此时应该如何解决？

原本在 Prometheus 生态中，一切皆标签，故而我们可以把这几台机器打上特殊标签表示这几台机器配置高，比如打上 hardware=high 的标签，然后其他普通机器打上 hardware=normal 的标签。然后配置两条告警规则：

 cpu_usage_idle{hardware="normal"} < 20 cpu_usage_idle{hardware="high"} < 15 

看起来可以解决，实际会有如下一些问题：

1. 新增标签会让原本的 TimeSeries 断掉，会影响其他告警逻辑，比如原本活跃的告警会报恢复（因为原来的数据断了查不到数据了，告警引擎以为恢复了）
2. 新增机器都要打上 hardware 标签，特殊的机器较少，手工打上 hardware=high 感觉尚可接受，但是普通机器较多，每次新机器启用都要打上 hardware=“normal” 标签，着实有点烦
3. 标签通常是定义维度信息，这类硬件特性信息，姑且也可以看做是一种维度信息，但是这类信息也放标签里，总感觉稍显混乱，而且后面如果某个 normal 的机器升配了，还要改标签，一旦改标签，TimeSeries 又会断掉

再举一个例子。假设现在有部分机器有混部的情况。比如同时部署了 redis 和 etcd 服务。etcd 的服务对硬盘 IO 比较敏感，所以想配置一个 IO 使用率超过 80% 就告警的规则，你可能会这么想：

 diskio_util{service="etcd"} > 80 

然后其他的服务所在机器的大于 90% 才告警，于是：

 diskio_util{service!="etcd"} > 90 

对于混部有 etcd 和 redis 的机器，希望同时打上 service="etcd" 和 service="redis" 的标签。但是很遗憾，Prometheus 生态里不允许出现这种同 Key 不同 Value 的做法。这就非常棘手了，相当于没法使用标签体系来描述混部的场景。

怎么搞？

夜莺从 v7.4.1 开始，支持把机器挂载到多个业务组，其实就相当于可以用业务组来描述现实中的混部的场景。当然，对于刚提到的硬件不同规格的场景，也可以用业务组来描述，业务组很灵活，想怎么划分就怎么划分。

但是，仅仅把机器挂到不同的业务组，只是方便我们去分类查看，和告警规则并没有联动。告警规则强依赖 promql，而 promql 还是需要使用标签来做过滤。从 v8.0.0.-beta.1 开始，我们提供了一个新的手段。

即，在告警规则的 promql 中支持配置变量，变量类型可以设置为机器，然后告警规则中也支持配置机器的筛选方式（支持通过机器名或业务组来筛选），于是就可以让告警规则和业务组联动起来。这么说可能比较抽象。下面举个例子。

告警规则中增加了一个 switch 开关：启用变量。如果你启用了变量就会出现一堆比较复杂的配置。

在上例中，我定义了两个变量，一个是 host，类型是机器标识，默认值是所有机器，另一个是 threshold，类型是阈值，默认值是 30。然后我在 promql 中引用了这两个变量。如果没有下面的变量筛选部分，仅有变量配置 + promql 的话，告警引擎的行为是：

拿到 host 变量的所有值，即全部机器，假设是 100 台，然后就是 for 循环 100 次，每次把 promql 中的 $host $threshold 变量替换掉，执行检测，看这个最终的 promql 是否查到了数据，如果查到了数据并满足持续时长的配置，就产生告警。

而我上例中还配置了变量筛选以及一个子筛选。最终的效果就是：

• DBA-redis 业务组的机器，并且机器标识是 mac-vm-001，则以阈值 10 代入 promql 做判断
• 除了 mac-vm-001 之外的 DBA-redis 业务组的其他机器，则以阈值 20 代入 promql 做判断
• 除了 DBA-redis 业务组的机器，剩下的公司的其他全部机器，则以阈值 30 代入 promql 做判断

promql 中那个下划波浪线先不用关心，并非是你的 promql 写的不对，而是这个编辑器自身的问题。

建议：如果可以按照之前的普通 promql 就可以解决的告警场景，建议继续使用老方式，如果老方式实在不好解决，可以尝试这种启用变量的告警规则，这个方式和业务组联动，性能会稍差，但是灵活性更好。另外业务组是夜莺的特有的东西，所以一旦你这么用了，就和夜莺深度绑定了，将来如果想迁移到其他告警引擎也会麻烦一些，这点也请注意。

关于这个告警规则启用变量的更多信息，可以参考 文档。

Webhook 支持代理

有些公司的网络环境比较复杂，可能会有代理的需求。夜莺的 webhook 一直不支持代理，如果夜莺的机器不通外网，发钉钉、企微等就没法搞了，虽说可以走自定义通知脚本的方式，但是就比较麻烦。

实际从 v7.7.2 开始就支持了代理模式，不过一直没宣传，借由 v8.0.0-beta.1 版本的发布，做一下周知。

比如你希望通过代理调用钉钉和企微，可以配置三个环境变量，HTTP_PROXY、HTTPS_PROXY、N9E_PROXY_URL，前面两个环境变量指定代理地址，N9E_PROXY_URL 指定要被代理的 URL，比如：

 N9E_PROXY_URL=qyapi.weixin.qq.com,oapi.dingtalk.com 

多个 URL 用逗号分隔，每个 URL 不用写全，只写一部分就行，能匹配到就行，就像上面，我只写了域名，没有把整个回调地址写上。

其他改动

v8.0.0-beta.1 还有一些其他改动，比如告警规则支持 Cron 表达式配置执行周期，可灵活设置定时执行策略，更多改动请参考 Changelog。

结语

一个新的大版本启程了，兄弟们跟上脚步，一起打造最好用的国产开源监控系统。如果你有什么建议，欢迎在 https://github.com/ccfos/nightingale 上提 issue，如果能来个 star 就更好了，让更多人知道并参与，即便现在还有瑕疵也会越来越好。