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

夜莺 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。解包之后直接运行夜莺的二进制即可。操作如下:

bash 复制代码
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,比如:

bash 复制代码
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 就更好了,让更多人知道并参与,即便现在还有瑕疵也会越来越好。

相关推荐
夜莺云原生监控1 天前
夜莺监控设计思考(二)边缘机房架构思考
开源·监控告警·nightingale·夜莺监控·运维监控
SRETalk2 天前
夜莺监控设计思考(二)边缘机房架构思考
监控告警·nightingale·开源监控·夜莺监控
SRETalk4 天前
夜莺监控设计思考(一)整体定位、架构设计、单进程多进程选择、高可用设计
监控告警·开源监控
SRETalk2 个月前
夜莺监控新版表格配置图文讲解
nightingale·夜莺监控
SRETalk2 个月前
开源夜莺里如何引用标签和注解变量
开源监控·模板语法·告警变量
SRETalk2 个月前
Grafana侧重可视化,那多数据源告警呢?
grafana·nightingale·开源监控·夜莺监控
SRETalk2 个月前
夜莺监控的几种架构模式详解
prometheus·victoriametrics·nightingale·夜莺监控
SRETalk2 个月前
为 Prometheus 告警规则增加 UI 管理能力
prometheus·监控告警·夜莺监控·运维监控
SRETalk2 个月前
如何监控多个进程的存活和CPU、内存占用
进程监控·夜莺监控·运维监控
SRETalk4 个月前
夜莺监控V8发版,内置支持 DeepSeek 对接
aiops·监控告警·夜莺监控·运维监控·deepseek