如何进行监控设计?

Posted 丝瓜呆呆

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了如何进行监控设计?相关的知识,希望对你有一定的参考价值。

在性能测试中,我觉得监控是非常重要的环节。因为这是做性能分析的前提,走出这一步,才有后面的分析。

监控是性能分析承上启下的关键点。设计监控是我们性能测试工程师必须要做的事情。当然了,仅仅设计监控是不够的,还要看懂监控数据才能分析。我们将在后面的篇幅一一拆解。

我觉得性能测试工程师也一定要自己去实现一遍监控的环节,而不是直接用其他团队搭建的监控工具。你可以自己找个 demo 服务器做一遍,这样才能真正理解后续要关注的点在哪里。

监控平台还指望别人给搭好,点个链接就能出数据了,这显然不是一个技术人员该有的样子。

监控设计步骤

如果要让性能测试人员设计监控逻辑,要如何做呢?首先,你要分析系统的架构。在知道架构中使用的组件之后,再针对每个组件进行监控。其次,监控要有层次,要有步骤。有些人喜欢一上来就把方法执行时间、SQL 执行时间给列出来,直接干到代码层,让人觉得触摸到了最顶级的技能。然而在我的工作中,通常不这么做,应该是先全局,后定向定量分析。最后,通过分析全局、定向、分层的监控数据做分析,再根据分析的结果决定下一步要收集什么信息,然后找到完整的证据链。这才是监控应该有的步骤,才能体现监控的价值。

监控技术图谱

这张图是我认为在一个性能测试中,该有的技术图谱。

 

 从这个图中我们可以看到,除了压力工具之外,还有很多技术细节。

通常在各种场合下,我都会说,这些都是我们要学习的范围,做性能分析的人,不一定能完全能掌握这些内容,那你所在的性能团队就应该有这样的能力。

因为性能团队要推进瓶颈的定位解决,所以要有和其他团队正面沟通的能力。下面我们就以具体的操作过程来说明设计的落地过程。现在的流行框架(比如说 Spring Cloud)中的熔断监控、限流服务、服务健康检查/监控、链路监控、服务跟踪、聚合监控等等,都是非常好的监控手段。比如说下面这样的架构图:

 

 

 

 这是比较常见的微服务技术架构。其中很多开源工具已经提供了监控的能力。

对技术的发展,我们要拥抱。但对思路的梳理更为重要,因为框架平台工具都是为了实现目标而存在的。在本篇中,我们还是回归根本,说一下监控设计的思路,讲清楚性能测试中应该如何拆分监控的点。当你看完了之后,即使是面对不同的架构,也有监控部署的思路。

架构图

那么我们就来到开始的位置了。做性能监控之前,先画一个最简单的架构图,看一下架构中各有什么组件,各有什么服务,将这些列下来,再找对应的监控手段和方式,看哪种手段和方式在性能测试过程中成本最低,效率最高。

如果把性能归到测试的这个阶段,那就必须先考虑测试的具体情况。

有些企业因为有长期的积累,监控平台完整又稳定,那显然是最好的。如果是短期项目类的性能测试,又涉及到多方企业的,基本上不要想有完整成熟的监控平台这件事了。

但是不管怎么样,我们都需要拿到架构的全局监控数据。针对下面的这个不大的架构,我们来考虑下如何拆分。

 

 

需要监控的内容如下:

下面我就来细化下这个简单架构的监控设计。

监控设计

下图可以大概说明我对监控的整体设计理念。

 

 我来说明一下:

我们要对整个架构做分层。

在每一个层级上列出要监控的计数器。

寻找相应的监控工具,实现对这些计数器的监控。

如果一个工具做不到,在定位过程中考虑补充工具。

要做到对每层都不遗漏。

从大的分类上来看,我们识别出每个监控的节点和层级,再对应到架构中,如下图所示:

 

 最适合的监控方式是什么样的呢?那就是成本最低,监控范围最大,效率最快。而是否持久就不再是考虑的重点了,因为项目结束了,监控工具可能也被拆了。

在企业中,我们也是首先考虑快速的监控实现。但是,还要一点要考虑,就是监控的持久有效性,能一直用下去。所以,在快速实现了之后,在必要时,会做一些二次开发,定制监控。

对了,这里再提一句,我不建议一开始就把代码级的监控给加进来。不光是因为它消耗资源,更重要的是,真的没有太大的必要。像方法的执行时间这类监控,如果没有定位到它们有问题,我们为什么要去看呢?当我们有了证据链的时候,是不是更一针见血呢?

所以最重要的是,我想看到的数据,到底能不能看得到。

对于上述的每个组件,我都建议用下面这样的监控思路。敲黑板!下图是重点!

 

 有人可能会想说:就这几个字还值当画个图吗?我觉得非常有必要。因为全局到定向的思路帮我解决了很多的问题。

全局监控设计

OS 层(CentOS 为例)

就拿 OS 来说吧,我们一般进到系统中,看的就是 CPU、I/O、内存、网络的使用率,这是很常规的计数器。在很多人看来,这些计数器是可以反应出一个系统的全局健康状态的。

先不管通过这些计数器得到的结论是不是对的。我们首先要知道的是,要有这样全局监控的潜意识,之所以说潜意识,是因为很多人不知道为什么看这些,但还是这样看了。那么实际上做一个 OS 的全局监控需要看多少个计数器呢?我们看下架构图。

 

 因为新版内核没有给更细的内核架构图,所以我用 2.6.26 版本的 Linux 内核架构图来说明思路。

给这张图的目的就是建议先看架构图,再考虑要监控的大分类有多少。

从上图中,我们可以看到有这么几类,system、processing、memory、storage、networking 等。

这里画出一个思维导图,给出我的经验计数器。

 

 针对 OS,我通常看上图中红色计数器的部分,这是 OS 查看的第一层。有第一层就有第二层,所以才需要定向的监控。后面我们再说定向监控的思路。

DB 层(MySQL 为例)

 我们再说 DB层,以 MySQL 为例。和上面的理念一样,我们也要看架构图。

 

 此图来自于 MySQL 官方,各大技术网站均有展示。

接着我们看下全局监控的分类,如下图所示:

 

 

同样,这也是 MySQL 全局监控的第一层。这个内容的整理并不具有什么技术性。稍微了解一下 Linux 和 MySQL 的架构,就可以整理出来。我们依此类推,按照这个思路,就可以把其他的组件都整理出第一层监控组件。有了全局监控,接着就是定向监控了。这是寻找证据链的关键一节。

定向监控

有了 OS 层的全局监控计数器,我们首先要学会的,就是判断这些计数器说明了什么问题。我在第三模块中写监控分析工具,会详细说明这部分。这里呢,我先把定向监控细化地解释一下,把这个思路给你讲得明明白白,通通透透。

 

以上是关于如何进行监控设计?的主要内容,如果未能解决你的问题,请参考以下文章

如何设计一个mysql性能监控的软件

vivo服务端监控架构设计与实践

设计讨论:监控系统,监控什么?

日志监控告警系统的设计与实现

资产监控设备4G模块BG95上电自动开机设计

设计一个靠谱的监控告警平台