前言
机器这个概念，在监控系统里具有比较特殊的场景。核心是因为两个原因：
机器上面的服务有时会混部，导致机器和业务程序之间的对应关系不好搞（这就是对待机器不能像对待 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 作为采集器，在夜莺的机器列表里就会自动出现机器列表：
image
如果发现内存、CPU、时间偏移等列是 unknown，可能的原因是：
你没有使用 Categraf 采集器
Categraf 配置文件里的 heartbeat 没有开启，或没有指向夜莺
这个表格里，机器标识是可以点击的，点击机器标识，可以打开一个侧拉板，展示机器的元信息：
image
多说一句：有些人会问，机器列表里可以看到机器的 CPU、内存等信息，但是仪表盘是空的，为啥？可能的原因：
Categraf 配置文件里 writer 部分配置的不对，没有指向夜莺
如果配置是对的，那就要看 Categraf 的日志找线索了
机器告警
使用了 Categraf 之后，除了可以看到机器列表、机器元信息、给机器分组、打标签之外，还可以对机器做特殊的告警规则配置。
image
告警规则里，有个专门的 Host 类型，提供三种机器相关的告警规则：机器失联、机器集群失联、机器时间偏移。
注意，机器时间偏移并非是机器和 NTP Server 之间的时间偏移，而是 Categraf 所在的机器和夜莺服务端的时间偏移，如果用了 n9e-edge 边缘模块，就是 Categraf 所在的机器和 n9e-edge 所在机器的时间偏移。
机器时间偏移这个规则较为常用，另一个常用的是机器失联。因为 Categraf + Nightingale 的监控数据流向是典型的 PUSH 模型，没有 Prometheus 中的 up 指标，所以需要额外的机制来判定机器是否失联。
Question：机器挂载了业务组，我想对某些业务组做告警判定，应该怎么配置？
这个问题也很常见。在夜莺的体系里，性能最好的方式是使用变量，配置方式如下：
image
上图中，创建了一个 ident 变量，变量类型是 机器标识，机器范围是 Default Busi Group 和 DevOps 两个业务组下的机器。然后在 promql 中引用了 ident 标签作为过滤条件。
当然，如果你的监控指标里有标签可以很方便做过滤，则直接使用标签也是 OK 的。
上例用的变量模式，还有另一个好处，是用于特殊机器的阈值配置，比如 Default Busi Group 和 DevOps 两个业务组下的机器默认 CPU 阈值都是 80，但是其中有1台机器很特殊，平时负载就很高，CPU 阈值要设置为 88，那就可以再加一个阈值变量，同时继续配置 变量筛选 条件：
image
这个配置方式稍微有点复杂，不过没办法，问题场景本身就是复杂的。
老版本没有 启用变量 这个配置，只有 仅在本业务组生效 的配置，那个方式性能不好。其原理是：
拿着告警规则里的 promql 去查询时序库里的所有满足条件的数据，可能查到很多机器都告警了，然后再根据机器的归属关系做过滤，只保留自己业务组下的机器的相关告警。
仪表盘只查看业务组下的机器
既然在夜莺里维护了机器和业务组的关系，那在仪表盘里查看机器的时候，能否只查看当前业务组下的机器呢？是可以的。
我们可以导入内置的机器相关仪表盘（在 Linux 类别下），打开 机器常用指标 那个仪表盘，默认是查看所有机器，因为 ident 变量配置是 label_values(system_uptime, ident)，如下：
image
然后，我们修改一下 ident 变量，如下：
image
保存仪表盘然后刷新，就会看到机器的变量下拉框里，只有当前业务组下的机器，如果仪表盘所属的业务组下面没有机器，那就看不了数据了。
其他机器相关的功能
开源版本，跟机器相关的功能主要就是上面罗列的那些。商业版会有额外的功能，比如：
