夜莺监控设计思考（四）关于机器那些事儿
这将是一个系列，讲解 夜莺监控 的设计思考，可以理解为原理+最佳实践+产品设计时的折中取舍。
本系列其他文章：
本篇聊聊夜莺里跟机器相关的那些事，机器的数据采集、机器的归组打标签、机器的元信息、机器的告警分派等。
前言
机器这个概念，在监控系统里具有比较特殊的场景。核心是因为两个原因：
- 机器上面的服务有时会混部，导致机器和业务程序之间的对应关系不好搞（这就是对待机器不能像对待 Pod 的原因）
- 采集器 agent 通常部署在机器上，对于机器的管理也会影响采集器的管理（很多新的可观测性厂商在宣传的 Fleet 机制，就是侧重在采集层面，agent 最终要部署到机器上，所以机器和采集器有很多关联）
Zabbix、Open-Falcon 等，对机器概念都有额外的抽象建模，Prometheus 生态则完全忽略机器概念的特殊性，走向了另一个极端。
夜莺监控（Nightingale）则站在二者中间，既想遵从 Prometheus 生态的玩法，又想给机器场景做一些额外的支持，稍微有点拧巴。不过产品是为业务场景服务的，场景就在那里，不是说想砍就能砍掉的。
夜莺体系里，对机器的相关支持比较零散，本文也会显得有点凌乱，望诸位看官见谅。
机器分类管理
夜莺里有个告警自愈功能，可以去机器上执行脚本，所以需要非常小心设计机器的权限。最简单的是每个机器跟人、角色绑定，但是不方便管理，所以给机器设计了一个业务组的概念。机器可以归属业务组，业务组关联的管理人员，这些人员可以对机器做操作。
业务组可能会划分的很细，比如每个 Service 作为一个业务组，比如 DBA/MySQL/Proxy 是也一个业务组，DBA/MySQL/DataNode/Mall 是另一个业务组。而同一台机器可能部署多个 Service，所以，机器要支持同时挂在多个业务组。
Prometheus 生态里，监控指标的各类维度信息都是通过标签来描述的（业务组是没法直接作为标签的，因为 Prometheus 里的标签不允许同 Key 多 Value），那夜莺要支持给机器打标签（在机器列表页面进行操作），给机器打的标签，会自动附加到机器的监控指标上。
所以，夜莺里，机器的归组提供了两个机制：
- 业务组，通常以 Service 颗粒度划分，跟权限相关
- 标签：如果想把某些维度信息附加到监控指标上，那就把这些维度信息做成标签
当然，这一切的前提，是你要使用 Categraf 作为采集器，并且把 Categraf 的 heartbeat 和 writer 的 url 都指向夜莺。
如果你没有使用 Categraf 采集器，机器列表里就是空的，用不了机器的归组、打标签的能力。其实也不是啥大事，不用 Categraf 也不会影响你对时序库中的数据做告警、看图。只是，使用 Categraf 会让体验更丝滑，可以获得额外一些能力。
Categraf 部署到所有待监控的目标机器上，采集机器的元信息、基础监控指标、执行脚本做告警自愈。
机器信息上报
如果使用 Categraf 作为采集器，在夜莺的机器列表里就会自动出现机器列表：
如果发现内存、CPU、时间偏移等列是 unknown，可能的原因是：
- 你没有使用 Categraf 采集器
- Categraf 配置文件里的 heartbeat 没有开启，或没有指向夜莺
这个表格里，机器标识是可以点击的，点击机器标识，可以打开一个侧拉板，展示机器的元信息：
多说一句：有些人会问，机器列表里可以看到机器的 CPU、内存等信息，但是仪表盘是空的，为啥？可能的原因：
- Categraf 配置文件里 writer 部分配置的不对，没有指向夜莺
- 如果配置是对的，那就要看 Categraf 的日志找线索了
机器告警
使用了 Categraf 之后，除了可以看到机器列表、机器元信息、给机器分组、打标签之外，还可以对机器做特殊的告警规则配置。
告警规则里，有个专门的 Host 类型，提供三种机器相关的告警规则：机器失联、机器集群失联、机器时间偏移。
注意，机器时间偏移并非是机器和 NTP Server 之间的时间偏移，而是 Categraf 所在的机器和夜莺服务端的时间偏移，如果用了 n9e-edge 边缘模块，就是 Categraf 所在的机器和 n9e-edge 所在机器的时间偏移。
机器时间偏移这个规则较为常用，另一个常用的是机器失联。因为 Categraf + Nightingale 的监控数据流向是典型的 PUSH 模型，没有 Prometheus 中的 up 指标，所以需要额外的机制来判定机器是否失联。
Question：机器挂载了业务组，我想对某些业务组做告警判定，应该怎么配置？
这个问题也很常见。在夜莺的体系里，性能最好的方式是使用变量，配置方式如下：
上图中，创建了一个 ident 变量，变量类型是 机器标识，机器范围是 Default Busi Group 和 DevOps 两个业务组下的机器。然后在 promql 中引用了 ident 标签作为过滤条件。
当然，如果你的监控指标里有标签可以很方便做过滤，则直接使用标签也是 OK 的。
上例用的变量模式，还有另一个好处，是用于特殊机器的阈值配置，比如 Default Busi Group 和 DevOps 两个业务组下的机器默认 CPU 阈值都是 80，但是其中有1台机器很特殊，平时负载就很高，CPU 阈值要设置为 88，那就可以再加一个阈值变量，同时继续配置 变量筛选 条件：
这个配置方式稍微有点复杂，不过没办法，问题场景本身就是复杂的。
老版本没有 启用变量 这个配置，只有 仅在本业务组生效 的配置，那个方式性能不好。其原理是：
拿着告警规则里的 promql 去查询时序库里的所有满足条件的数据，可能查到很多机器都告警了，然后再根据机器的归属关系做过滤，只保留自己业务组下的机器的相关告警。
仪表盘只查看业务组下的机器
既然在夜莺里维护了机器和业务组的关系，那在仪表盘里查看机器的时候，能否只查看当前业务组下的机器呢？是可以的。
我们可以导入内置的机器相关仪表盘（在 Linux 类别下），打开 机器常用指标 那个仪表盘，默认是查看所有机器，因为 ident 变量配置是 label_values(system_uptime, ident)，如下：
然后，我们修改一下 ident 变量，如下：
保存仪表盘然后刷新，就会看到机器的变量下拉框里，只有当前业务组下的机器，如果仪表盘所属的业务组下面没有机器，那就看不了数据了。
其他机器相关的功能
开源版本，跟机器相关的功能主要就是上面罗列的那些。商业版会有额外的功能，比如：
- Categraf 的采集规则中心化管理和下发
- 专门的网络设备管理里需要采集器探针的管理，会和机器管理有联动
