企业官网建设流程全解析

开封网站建设流程与步骤,网站主机的类型,网站域名注册机制,郑州做公司网站的前言机器这个概念#xff0c;在监控系统里具有比较特殊的场景。核心是因为两个原因#xff1a;机器上面的服务有时会混部#xff0c;导致机器和业务程序之间的对应关系不好搞#xff08;这就是对待机器不能像对待 Pod 的原因#xff09;采集器 agent 通常部署在机器上在监控系统里具有比较特殊的场景。核心是因为两个原因机器上面的服务有时会混部导致机器和业务程序之间的对应关系不好搞这就是对待机器不能像对待 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保存仪表盘然后刷新就会看到机器的变量下拉框里只有当前业务组下的机器如果仪表盘所属的业务组下面没有机器那就看不了数据了。其他机器相关的功能开源版本跟机器相关的功能主要就是上面罗列的那些。商业版会有额外的功能比如