性能测试中如何进行监控设计

一、监控设计步骤

首先,你要分析系统的架构。在知道架构中使用的组件之后,再针对每个组件进行监控。

其次,监控要有层次,要有步骤。应该是先全局,后定向定量分析。

最后,通过分析全局、定向、分层的监控数据做分析,再根据分析的结果决定下一步要收集什么信息,然后找到完整的证据链。

这才是监控应该有的步骤,才能体现监控的价值。

架构图

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

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

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

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

在这里插入图片描述
需要监控的内容如下:

  1. 操作系统
  2. Nginx
  3. Tomcat
  4. Redis
  5. MySQL

监控设计

我来说明一下:

  1. 我们要对整个架构做分层。
  2. 在每一个层级上列出要监控的计数器。
  3. 寻找相应的监控工具,实现对这些计数器的监控。如果一个工具做不到,在定位过程中考虑补充工具。
  4. 要做到对每层都不遗漏。

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

在这里插入图片描述

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

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

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

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

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

在这里插入图片描述

全局监控设计

那么什么是全局监控呢?

OS 层(CentOS 为例)

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

先不管通过这些计数器得到的结论是不是对的。我们首先要知道的是,要有这样全局监控的潜意识,之所以说潜意识,是因为很多人不知道为什么看这些,但还是这样看了。

那么实际上做一个 OS 的全局监控需要看多少个计数器呢?我们看下架构图。

在这里插入图片描述

给这张图的目的就是建议先看架构图,再考虑要监控的大分类有多少。从上图中,我们可以看到有这么几类,system、processing、memory、storage、networking 等。

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

在这里插入图片描述

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

DB 层(MySQL 为例)

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

在这里插入图片描述

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

在这里插入图片描述

同样,这也是 MySQL 全局监控的第一层。

这个内容的整理并不具有什么技术性。稍微了解一下 Linux 和 MySQL 的架构,就可以整理出来。我们依此类推,按照这个思路,就可以把其他的组件都整理出第一层监控组件。

有了全局监控,接着就是定向监控了。这是寻找证据链的关键一节。

定向监控

有了 OS 层的全局监控计数器,我们首先要学会的,就是判断这些计数器说明了什么问题。我在第三模块中写监控分析工具,会详细说明这部分。

这里呢,我先把定向监控细化地解释一下,把这个思路给你讲得明明白白,通通透透。

OS 层之定向监控细化 1

当你看到 CPU 消耗得多,那么你就得按照下面这张图细化思路(从左向右看)

在这里插入图片描述


st=>start: 开始
e=>end: 结束
op1=>operation: 通过si CPU找到对应的软中断号及中断设备
op2=>operation: 再找到软中断对应的模块
op3=>operation: 再到模块对应的实现原理
op4=>operation: 给出解决方案 
st->op1->op2->op3->op4->e
OS 层之定向监控细化 2

当你看到 OS 全局监控图中的 Network 中的 Total 总流量比较大时,就要有这样的分析思路(从右向左看):

在这里插入图片描述

列出流程图来就是如下所示:


st=>start: 开始
e=>end: 结束
op1=>operation: 网络总流量
op2=>operation: 分析性能场景中的业务流量
op3=>operation: 分析网络带宽
op4=>operation: 分析网络队列
op5=>operation: 解决方案
st->op1->op2->op3->op4->op5->e

依此类推,就可以列出更多 OS 层的定向监控分析的思路。

DB 层之定向监控细化 1

同 OS 层的定向监控细化思路一样,在 DB 层中要想找到完整的链路,那么在 MySQL 中也必须把逻辑想明白。

当你发现查询和排序的报表有问题时,比如说下面这样(数据来自于 MySQL Report):

__ SELECT and Sort _____________________________________________________
Scan            7.88M     2.0/s %SELECT:  38.04
Range         237.84k     0.1/s            1.15
Full join       5.97M     1.5/s           28.81
Range check   913.25k     0.2/s            4.41
Full rng join  18.47k     0.0/s            0.09
Sort scan     737.86k     0.2/s
Sort range     56.13k     0.0/s
Sort mrg pass 282.65k     0.1/s
在这里插入代码片

居然每秒就能有 2 次全表扫描!那该怎么办呢?定向细化,如下所示:

在这里插入图片描述
相信这样常规的动作,你肯定能掌握得了。

那么来看下一个。

DB 层之定向监控细化 2

当你看到锁数据的时候,如下所示:


__ InnoDB Lock _________________________________________________________
Waits          227829     0.1/s
Current             1
Time acquiring
  Total     171855224 ms
  Average         754 ms
  Max            6143 ms

当前等待并不多,只有 1。但是你看下面的平均时间为 754ms,这还能不能愉快地玩耍了?

下面我也同样列出定向监控细化的思路。

在这里插入图片描述

分析产生锁的 SQL,看 SQL 的 Profiling 信息,再根据信息找下一步原因,最终给出解决方案。

有了上面的全局—定向监控思路,并且将每个组件的第一层的计数器一一列出。这是我们监控分析的第一步。

至于定向监控部分,我不建议一开始就列,主要原因有三个:

  1. 耗费太多时间;
  2. 列出来也可能半辈子也用不上;
  3. 照搬列出来的定向监控逻辑,有可能误导你对实时数据的判断。

监控工具

针对上面我们画的架构图,我大概列出相应的监控工具及优缺点。这里列得并不详尽,只供借鉴思路使用。

在这里插入图片描述

如果要选择的话,肯定是用 Prometheus + Exporter 的思路会好一点。于是我们这样实现全局的监控。

OS:

在这里插入图片描述

DB:

在这里插入图片描述

Nginx:
在这里插入图片描述

Redis:
在这里插入图片描述

Tomcat:

在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值