【连载】说透运维监控系统-3.1夜莺页面功能介绍

【连载】说透运维监控系统-3.1夜莺页面功能介绍

本章，第三章，讲解夜莺监控系统的功能，姑且只提供第一篇，如果哪些地方还不懂，可以反馈给我，我酌情录制更多使用教程

看图相关功能

监控数据最常见的一个用处就是绘制图表展示，我们可以从图表上看到数据的趋势和异常情况，Grafana就是专门用来看图的（当然，现在已经不止是看图了），市场占有率非常高，在开源监控领域影响力巨大，就是因为看图确实是非常高频的一个需求。

即时查询

我们经常会有一些临时需求，来查看一些数据的情况，比如部署了一个采集器，想看看都采集了哪些指标，应对这种临时查询需求，就是使用即时查询功能：

结果有两种展示方式，默认是表格方式，展示当前这一时刻的最新值，也可以使用图表方式查看：

快捷视图

即时查询，查询任何数据都要输入promql，这个对于资深工程师还好，但是如果对相关指标名称没那么了解，就很难受了。我们希望通过快捷视图的功能，把填空题做成选择题，要看什么监控数据，直接点点点就可以看，这样用户体验会大幅提升。

下面的截图，是配置了一个HTTP探测列表，选中不同的探测目标，就可以查看相关监控数据：

针对即时查询和快捷视图，录制了一个视频教程，供大家参考：

监控大盘

即时查询、快捷视图都是想看什么指标的时候就去选择什么指标，看一个就要选一个，而监控大盘，是提前把要看的图配置好，未来想看的时候点开就可以直接查看一批图表，无需一个一个选择了。这在一定程度上起到了知识传递的效果，比如MySQL的监控，资深DBA配置好监控大盘，把重要的图、应该着重关注的图都放到大盘里，其他人看到这个监控大盘就能学到很多知识。

夜莺在etc/dashboards目录下内置了一些常用监控大盘，大家可以导入直接使用，大家做的比较好的监控大盘，也欢迎提PR。

监控大盘相比老的版本，确实增加了很多新功能，专门录制了一个视频来讲解：

规则配置

夜莺支持3类规则：告警规则、屏蔽规则、订阅规则。其他监控系统的设计也是类似的，只是各家产品在细节和思路上会有一些差异。

告警规则

虽然监控系统采集到了很多数据，但是什么样的数据是异常的，监控系统并不知道，比如采集了一个监控指标叫http_target_status，平时采集到的监控数据为0或1，到底是0表示正常还是1表示正常？监控系统其实无从得知。

此时就要人为的告诉系统，什么情况是异常情况，怎么告诉系统？就是通过配置告警规则，比如配置了一条告警规则：

http_target_status != 0

上面这个告警规则表示，值不等于0就告警，说明平时的正常情况，值应该是0，只要值非0了就异常了。

告警规则本质上就是一条promql，故而可以做一些条件筛选和四则运算，在这个时代的监控系统中，条件筛选和四则运算已经是一个必备功能了，比如下面的告警规则：

http_api_request_success{region="beijing"} / http_api_request_total{region="beijing"} < 0.995

表示：求取beijing这个region的所有http请求的成功率，如果成功率小于 99.5% 就告警。

当然，告警规则的配置不止是一条promql，还有很多其他的配置，比如持续时长、生效时间、标题、备注、告警接收人、回调地址等等，这都是生产实践中总结的经验结晶。在etc/alerts目录下，也放置了很多内置的告警规则，可以直接导入使用，同样的，也欢迎PR。

告警规则这块，大家可以参考两个视频教程，一个是之前 v5.0 录制的，一个是近期 v5.9.3 录制的：

屏蔽规则

有时会有预期的停机维护，在维护期间的告警，对我们反而是一种打扰，所以监控系统通常支持配置告警屏蔽规则，指定什么样的告警事件在某个时间区间内就不要发出来了。

告警屏蔽，屏蔽的是告警事件，告警事件种类很多，怎么才能准确的筛选到想要屏蔽的事件呢？通常，是使用标签过滤，比如我想配置某个机器的失联告警，类似如下方法来配置：

上例中指定了屏蔽的时间范围，指定了事件过滤器，通过__name__和ident两个标签来过滤，这样就可以精确的匹配到cloud-ceph-node01.bj这个机器的target_up指标。

屏蔽规则新版本和老版本没啥差别，直接参考之前的视频教程即可：

订阅规则

订阅规则一般监控系统较少提供的功能，用好了的话是非常实用的。比如，公司的Kubernetes平台如果出了严重问题，Kubernetes平台的维护人员需要第一时间接收告警去处理，但是Kubernetes平台之上跑的那些业务方，其实也希望收到告警，此时，业务方就可以去订阅Kubernetes平台的这些严重告警。

另一个场景，比如云平台部门的运维人员配置了一条端口监控的告警规则，任何一个端口出问题，都会告警，此时各个业务方也可以通过配置订阅规则，只订阅自己感兴趣的服务的端口。避免了每个业务方都配置一条告警规则，对时序库造成较大压力。

订阅规则和屏蔽规则类似，也是对告警事件做各种条件的筛选，对于订阅到的事件，可以重新定义告警级别和通知媒介。

订阅规则也没有太多变化，大家参考之前 v5.0 的视频教程即可：

告警事件管理

对于生成的告警事件，通常我们有两类需求，其一是对活跃告警做分类呈现，类似一个实时刷新的大盘，有了问题能够及时了解到；其二是对历史告警有个存档，未来想回来找的时候能够方便的找到，有了历史存档，未来也可以做分析。

活跃告警

活跃告警提供两种视图，一个是列表视图，一个是聚合视图，聚合视图可以配置聚合规则，这个设计还是比较创新的，下面给一下截图，让大家有个直观的感受：

上面是活跃告警的聚合视图，按照告警规则聚合，这样查看起来就较为容易。也支持自定义聚合规则，如果告警事件的标签较为规范，也可以按照地域聚合，按照业务线聚合，按照服务聚合等等。

历史告警

活跃告警是只展示当前未恢复的告警，历史告警是所有的告警事件，包括恢复的事件，下面截图中有个绿条的那一行，就是恢复事件，其他颜色，越深表示事件级别越高。

告警事件可以参考之前的视频教程，针对新功能活跃告警视图，单独做了一个新的视频教程：

监控对象管理

首先，监控对象这个东西，即使没有，整个系统的核心逻辑也仍然可以工作。设计监控对象这个东西，更多的是应对机器监控管理的场景。我们要做监控数据采集，是需要在机器上安装 agent 的，我们可能有统一管理这些 agent 的配置的需求，有对这些机器做权限配置的需求，因为夜莺中有告警自愈功能，可以在机器上跑脚本，跑脚本是一定要控制权限的，即要能配置哪些人对哪些机器有权限，所以机器这个概念，一定要能在系统中建模。另外，机器经常会有分组的需求，相当于在 agent 上配置标签，这样上报的监控数据就自动有了分类信息，但是在 agent 上配置标签需要登录机器操作，不太方便，所以有个机器管理的UI也可以提升易用性。

夜莺提供的接口都是监控数据上报的接口，如何从监控数据中解析出机器的信息呢？这就需要规范了，默认情况下，夜莺会去监控数据的标签中找 ident 标签，ident 标签的值就看作是机器标识。当然，为了兼容datadog-agent的数据结构，夜莺也会把 host 字段转换成 ident，为了兼容 grafana-agent，夜莺会把 agent_hostname 字段转换成 ident，这样一来，不同的 agent 采集的数据，夜莺都可以从中得知机器信息。

这样说，可能略微抽象，举个例子，下面是一条监控数据，表示机器的整体CPU空闲率：

{    "metric": "cpu_usage_idle",    "tags": {        "cpu": "cpu-total",        "ident": "cloud-ceph-node01.bj"    },    "timestamp": 1651976422,    "value": 34.5}

tags 部分有两个标签，一个是 cpu=cpu-total 表示这是整机的CPU空闲率，而非单核心的，ident=cloud-ceph-node01.bj 表示这个监控数据是来自 cloud-ceph-node01.bj 这个机器。

像上面这条监控数据，如果上报给夜莺，夜莺就会从中解析出 cloud-ceph-node01.bj 这个字符串，当做机器标识，写入DB中的target表，这样我们在对象列表中就可以看到这个机器了。

对象归属业务组

监控对象可以设置归属关系，归属到某个业务组，只有这个业务组的的有权限的人才能对机器做操作，比如修改机器的备注、标签、通过故障自愈提供的命令通道去机器上执行脚本。

业务组怎么划分比较合适？

业务组有两个作用，一个是用于机器归属，另一个是用于给监控大盘、告警规则做分类。用于机器归属的业务组，就根据实际的机器和团队的归属关系设置即可。用于监控大盘、告警规则分类的业务组，则根据大盘和规则分类的习惯来划分即可。不需要非得考虑一种通用的划分方案，导致两个场景都无法100%的满足。

对象支持打标签

给监控对象打标签也是一种分组机制，业务组可能是个更大范围的东西，比如DBA团队创建了一个DBA的业务组，所有归属DBA管理的机器都放到这个业务组下。但是这些机器部署的数据库实例其实是给不同的业务线使用的，如果想做区分，就需要有个比业务组颗粒度更小的分组机制，这就是标签。

监控对象上面打的标签，都是KEY=VALUE的格式，这些标签会被附到时序数据上，比如某个机器打上了region=beijing的标签，未来这个机器上报的监控数据，就都会自动附上region=beijing的标签。这样做有个好处，如果用grafana制作图表，虽然grafana不是夜莺的一个组件，二者是两个不同的系统，但是因为grafana也能读取时序数据的标签，故而，在grafana中也可以使用在监控对象上打的这些标签。

对象失联告警的原理

对于监控对象（主要是机器）失联告警，直观想到的方案是只要机器不再上报监控数据了（即在服务端查不到机器的监控数据了），就是失联了。这可以使用promql中的absent函数实现，但是，absent函数需要把所有的标签都写完整才能起到预期的效果，比如有10台机器，我们需要配置10条类似下面的告警规则：

absent(system_load_1m{ident="cloud-ceph-node01.bj"})

即，每一台机器都要配置一条规则，这就有点太麻烦了。有没有什么办法，可以只配置一条规则，任一台机器失联都可以感知到呢？

夜莺提供了一种方案，会为每个机器自动生成一个target_up指标，如果夜莺在最近收到了机器的监控数据，target_up的值就设置为1，如果近期没有收到机器的监控数据，target_up就设置为0，这样一来，我们只要配置一条告警规则就可以了：

max_over_time(target_up[130s]) == 0

只要监控数据的标签中带有对应的 ident 标签，这个 ident 对应的机器就认为是活跃的，无论是CPU的指标还是内存的指标，都没关系。但如果监控数据中没有 ident 标签，或者监控数据压根就没有上报给夜莺，而是直接写入了时序库，那就没法使用夜莺提供的这个失联告警的功能了。

在 server.conf 中可以找到 target_up 相关的配置项：

[NoData]Metric = "target_up"Interval = 15

默认 Interval 是 15 秒，即，只要 15 秒内没有收到机器的任一监控数据，就会生成 target_up = 0 的监控数据，如果 agent 上报的频率本来就比较大，比如 agent 上报的频率是1分钟，那这里也要相应的调大，建议是比 agent 上报频率 * 2 + 10 算出 NoData 下的 Interval 配置。

人员组织管理

夜莺中涉及人员相关的概念有3个，用户、团队、业务组

用户管理

用户有两个作用，一个是为现实世界的人员的建模，这些人要能登录系统，那就需要用户名、密码。用户还可以作为告警接收者，比如钉钉机器人、企微机器人，也可以看做是用户，这类用户是虚拟用户。他们不允许登录系统，也不需要填充手机、邮箱等属性。

夜莺默认提供3类角色，Admin、Standard、Guest，Admin角色相当于系统的管理员，啥都可以干，Standard角色相当于操作员，能做业务操作，不能创建、删除用户之类的，Guest则是只读角色，只能看，不能操作。

如果有自定义角色的需求，需要修改role和role_operation表，这两个表的结构很简单，这里不详细展开，未来可能会把角色管理的功能做到UI上，算是一个长尾需求，短期暂未排期。

团队管理

团队的概念比较简单，团队就是用户组。配置告警接收人的时候，或者配置业务组的管理人员的时候，如果直接配置对应的人，未来在人员离职或变更权限的时候，都会比较麻烦。所以，设计了团队的概念，告警接收人和业务组的管理人员都关联到团队上，未来人员如果有变化，只需要修改团队即可。

业务组管理

业务组是个管理概念，上面在讲解监控对象的时候就提到，业务组下面的人才能操作业务组下面的机器，除了人和机器，监控大盘、告警规则、屏蔽规则、订阅规则、自愈脚本等等，都是隶属某个业务组的，只有这个业务组的人才能修改。

人和业务组是通过团队关联起来的，业务组下面有管理团队和只读团队，如果某人是某业务组的管理团队的一员，这个人就能管理这个业务组下的资源，如果这个人是只读团队的一员，那他就可以查看业务组下的资源，不能修改。

告警自愈

告警自愈的功能没有更新，大家参考之前的视频教程即可：https://mp.weixin.qq.com/s/4xlbWjclbSyCn91HpVRT9g

作者：龙渊秦五，网络ID：UlricQin，个人主页：https://ulricqin.github.io夜莺：一款云原生监控系统，国产开源，隶属中国计算机学会开源发展委员会，项目主站：https://n9e.github.io/