Nightingale|夜莺监控机器分组的设计逻辑

秦晓辉@快猫星云 2022年11月10日

简介

老版本的夜莺监控是有一个树形结构的,不同的机器可以挂在不同的节点,从 v5 版本开始,取消了这个设计,转而使用一维的业务组和标签,为何要这么设计呢?树形结构是否还会重新引入?这个问题经常会有社区的小伙伴有疑问,这篇博文就来介绍一下个中考虑。

机器分组机制

机器分组机制,典型的有3种。各有优缺点,我们分别来看一下。

扁平一维的 HostGroup

Zabbix、Open-Falcon都是这么设计的,在HostGroup上绑定采集规则、告警规则,可以对组内所有机器生效。这种方式简单直观,但是灵活性不够,比如我创建了三个分组:

cloud.sre - 放置所有的 sre 的机器
cloud.sre.n9e - 放置所有的 n9e 的机器,因为 n9e 是 sre 团队搞的,所以用了一个 cloud.sre 的前缀
cloud.sre.n9e.mysql - 放置所有的 n9e 用到的 mysql 的机器
  • 问题1:添加机器的时候要同时操作多个分组。比如 cloud.sre.n9e.mysql 下要更换一台机器,除了要操作 cloud.sre.n9e.mysql 之外,还要操作另外两个分组,比较麻烦。
  • 问题2:这种分组机制比较固化,是按照组织结构和服务模块的关系来制定的,如果想获取所有 mysql 的机器(不止 n9e 的 mysql 机器,还想一起查询到其他服务用的所有 mysql 机器),这种其他维度的筛选需求,就很难实现了。

树形结构

树形结构相比 HostGroup 一定是更有优势的,至少可以解决 HostGroup 的第一个问题,上面的三个分组,转换成树形结构,是下面的方式:

cloud
  |- sre
    |- n9e
      |- mysql

mysql 节点下面的机器如果有调整,就只调整这个节点即可,未来根据树节点查询,比如查询 cloud.sre 下面的机器,自然也能把 mysql 下的机器查到。但是树形结构仍然有问题,典型问题有2个:

  • 问题1:这种方式仍然比较固化,无法解决其他维度的过滤问题。和 HostGroup 的问题1是一样的。当然,你可以说,我再单独创建一个 mysql 的节点,放置所有 mysql 的机器不就行了,是的,但是未来的维护就越来越麻烦,毕竟创建节点是个比较重的管理操作
  • 问题2:树形结构的各个节点,实际是带有业务语义的,是有意义的,后面我们做告警规则的编写、监控大盘的配置,都极有可能使用这些节点来做过滤。比如告警规则配置,我想要所有 n9e 的机器的 cpu.idle 小于 10% 告警。这里就会有个问题,时序数据是在时序库里的,但是机器的元信息是在树形结构上维护的,非常割裂,我们需要先根据树形结构查到 n9e 的机器列表,然后拿着这个机器列表去时序库里查数据做告警判断,非常麻烦,另外如果你要使用其他看图工具,比如 Grafana 去直接查询时序库,就很难复用到树形结构的元信息,因为时序库里没有这个元信息

标签的方式

标签的方式,是指对机器打标签,比如某个机器,打了这么几个标签:dept=cloud team=sre product=n9e service=mysql 这个信息表意就很丰富了,我们可以很容易知道这个机器是来自 cloud 这个部门,sre 这个团队,用于部署 n9e 这个产品,部署 mysql 这个服务模块。

相比 HostGroup,标签的方式类似于一个机器属于多个分组,同时增加了维度信息,标签 Key 就相当于维度信息。树形结构相当于固定标签 Key 顺序的一种组织方式。标签的方式是最为灵活的。但是标签的方式也问题。

标签方式最核心的问题就是不直观。比如公司有1万台机器,放到一个表格里呈现,每个机器有七八个标签,虽然可以用标签做非常灵活的筛选,如果对标签体系不了解的人,压根就不知道有哪些标签,这就很尴尬。

夜莺的方式

夜莺的方式,其实是综合了 HostGroup 和标签的方式。为何是这样的呢?其实刚开始设计的时候,我连业务组都不想要,就直接让机器打标签就好了,那这种方式不是不直观么,其实有解,比如可以在UI上做一些文章,把常见的标签展示在筛选区域,用户可以直接点击标签做筛选。挺好。

但是,夜莺还是想把故障自愈,批量执行脚本的能力放出来,但是这个功能是需要很强的权限限制的,不能让用户随便去机器上跑命令,太危险了。所以,得有一种方式来做配置,哪些人可以对哪些机器做操作。当然,最简单的办法就是每台机器都配置哪些人可以有权限,但是这样就比较麻烦,还是需要对机器有个分组,一次配置一批机器的权限。那好,那就用标签呗,比如为 dept=cloud 的所有机器配置权限。看起来OK,但这个时候就要对 dept=cloud 标签和机器的对应关系有个管理,要不然,谁都可以轻易的把机器打上这个标签,或者轻易的把一起机器去除这个标签,都会造成权限失控。

难道,要为标签设置管理员?标签的管理员确实可以避免有人擅自把机器从标签下面去除的问题。但是哪些机器可以打上这些标签?也不能让标签管理员随意来操作。所以,这个时候超级管理员,Admin角色就要出手了,由Admin来分配机器,所谓的分配机器,就是打上一些特殊的标签(这些标签是有人管理的)。

另外,标签和管理人员挂钩,直观感受上非常奇怪,标签毕竟应该是一个很轻量和灵活的东西,现在还要配置上管理员,而且有些标签有管理员,有些又没有。话说,权限这个事情是个偏管理范畴的事情,标签呢,又只是一个维度分组机制,二者这么紧密耦合,总感觉怪怪的。

要不,我们用分组的手段来管理机器权限,用标签的手段来管理机器分组?

这个话题先暂停,先考虑一下另一个关联问题,告警规则、监控大盘、订阅规则、屏蔽规则,这些配置类的信息,其实也是需要分组的,要不然公司有几千条告警规则,都放到一个表格里显得很混乱,同时也需要控制权限,我们团队的规则,其他团队不能乱改。

机器的权限管理需求和告警规则的权限管理需求,其实是类似的,可以统一用一个概念来解决,这就是后来夜莺里边的业务组。一个业务组下可能有很多机器,不同的机器想做更细粒度的划分,就用标签,有些业务组下可能也没有机器,只是管理告警规则、监控大盘等,也OK。

以上就是设计思路的演进过程。虽然上面看起来有点烧脑,但是请你务必看完并理解,如果看不懂,可以再看一遍。不要再在群里或Github问我这类问题了,我已经用本文几千个字来解释了,我没有办法再在群里用几十个字解释的更清楚。

总结

  1. 业务组既可以管理机器,也可以管理告警规则、屏蔽规则、订阅规则、自愈脚本、监控大盘
  2. 业务组下可以有机器,也可以完全没有机器
  3. 用于管理机器的业务组,可以按照资产归属的范围来划分。比如你们公司的机器是归属各个业务线的,那这类业务组就按照业务线来划分即可
  4. 用于管理规则、大盘的业务组,不用按照资产归属的范围来划分。可以按照产品、服务等维度来划分,或者,看你个人爱好,没所谓
  5. 业务组虽然是一维的,命名的时候,建议用前缀做出一些关联关系,比如管理 n9e 基础告警规则的业务组,可以叫 n9e-rules,管理 n9e.mysql 的告警规则的业务组,可以叫 n9e-mysql-rules

关于作者

本文作者秦晓辉,快猫星云合伙人,文章内容是快猫技术团队共同沉淀的结晶,作者做了编辑整理,我们会持续输出监控、稳定性保障相关的技术文章,文章可转载,转载请注明出处,尊重技术人员的成果。