简介

老版本的夜莺监控是有一个树形结构的，不同的机器可以挂在不同的节点，从 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

关于作者

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