学习笔记—Grafana监控docker--mysql/redis/rabbitMQ_docker grafana

一、配置grafana中的promethus

1、第一步：进入grafana后，先设置data source ，选择添加prometheus，并配置好地址，测试并保存（前提是prometheus是启动状态）；
2、第二步：import一个对应的展示数据的模版：服务器数据模版、mysql数据模版

二、进入docker
1、Docker stats: 监控docker性能。注意：容器限制了内存大小，超过内存后报错

2、docker搭建cAdviso容器(自带容器)

监控分析流程：全局到局部
1、服务器资源–全局分析服务器
>usr%
>sys%
2、容器资源情况—usr%
根据分析需求去搭建对应的中间件的监控
3、mysql资源情况—专项分析

性能测试实战
一、性能场景设计
1、项目业务简介
2、项目架构
3、场景提取
>需要对应的性能指标
*甲方给定对应的指标
没有指标—公司自己评估系统的性能
常规的指标：TPS、RT(响应时间)、并发数
辅助的参考指标：错误范围（0～0.5%）
>场景设计
单场景：
。登录
。商品首页—列表出商品
多（混合）场景
。可以是一个或多个操作业务流程：登录-商品列出-商品详情—秒杀-退出
>比例场景
。基于多场景—精准流程：10%-50%-40%
压测前的准备：
>jmeter堆设置
1、win环境设置：/bin/jmeter.bat中设置 set HEAP=-Xms5g -Xmx5g
>端口设置:
压测实战一：
场景：获取商品列表
场景类型：单场景
测试类型：负载测试—不同负载（用户数）的性能表现
场景设置：ramp-up：持续时间是1s

场景名称/操作流程/场景详情/指标/备注

压测数据

用户数据/TPS/Error%/RT(ms)-平均/RT(ms)-90%/备注

性能分析：经过性能负载的事：整个列出商品的接口在容器监控下可以按到没有走redis。工作流程：直接从数据库mysql获取商品列表。
不同负载的趋势图：
grafana的监控图：
Cpu监控图
测试结果汇总
1、商品列出接口：tps在用户数在1500-2000范围内，TPS在2800
优化建议
结合分析：这个接口没有走redis
redis常用场景

读场景（查询接口）
补充知识点：
1、redis作用：让数据访问缓存，不访问数据库，减少对数据库的压力
哪些数据走redis:可以设置失效时间（开发去设置）
Token—需要账户密码去数据库做检验
高频业务数据—热点数据—当天的秒杀数据
哪些数据不适合走redis:只适合走mysql
需要事实查询
列表数据（订单）
2、jmeter的运行方式
jmeter.bat 在win环境运行(带页面)
jmeter.sh 在linux环境运行：
。在Mac环境运行的GUI模式
。在图像化linux环境的GUI模式
。jmeter命令模式
。Jmeter-server 分布式模式

**优化方案：这个接口走redis
开发解决：
回归测试：
2、问题：并发用户数在4000时，响应结果出现异常
分析：
1、先确认是测试机问题（查看jmeter右上角的黄色报错信息），还是项目服务器问题·
jmeter.log的问题：jmeter.heap 、jmeter.plus、socket
服务器问题： 500、404、断言（请求本身返回是否是200，响应有问题）
2、确认是项目服务器问题
3、去查看对应服务器log（查看到redis的连接池不够用）
4、优化redis连接池

二、压测实战二
**场景：**秒杀场景（登录-商品列出-商品详情—秒杀-退出）
**测试目标：**验证高并发下的秒杀接口的性能以及是否会出现超卖
场景类型：多场景
测试类型 ：高并发–使用同步定时器
补充知识点：
同步定时器中“模拟用户组的数量”为0时，表示的是所并发的用户
分析：
线程数1001个都秒杀成功，但库存只有1000
测试结果：
出现超卖现象
优化建议：
*库存在mysql，使用mysql x锁；一个事务获取了一个x锁，其它事务不能去获取
*CAS 不使用锁
*redis预减库存
开发优化：
回归测试：
三、压测实战三
场景：在开发优化，测试回归过程中可能会引入新的bug
验证环境3.0.，优化升级到4.1
补充知识点：如何在项目中替换容器新版本：
1、stop老的容器（端口需要重用）
2、创建新的容器
分析：

1、使用浏览器访问项目的页面，看能不能访问
2、使用简单的指令查看资源情况 ,top
3、在项目空载的时候，cpu%==25%
4、cpu%>usr%>java进程高（pid 55730）（但实际上代码运行没有报错，不会有打印出服务器日志 docker logs -f --tail 100 miaosha）
5、miaoshao容器
6、使用iotop 看到有大量的磁盘写入操作
在外面查看秒杀容器
查看具体的进程的资源情况： top -H -p 55730
查看io的命令： pistat -p 50730 -t -d 1 3 或 iotop
7、写操作是miaosha进程miao.jar
8、进入秒杀容器内，docker exec 0t 53b /bin/bash
使用top 查看java进程—7jar
9、使用jstack 7 >miaosha.txt
10、正则查找 more +/miaosha miaosha.txt 去txt查看具体线程的描述
11、找到一个 文件上传任务在运行！

四、压测实战四–redis（结合压测实战一）
场景：高并发的用户数时
分析流程：先全局，后局部
1、聚合报告出现错误率=4.7%
2、经过查看结果树：响应报服务端异常
3、确定是服务器性能问题–下一步分析服务器性能
4、分析web应用服务器—miaosha容器
5、使用docker logs -f —tail 100 miaosha ：看日志
6、分析redis的性能，连接池不够
>java代码里有配置文件
>redis应用本身的配置（两个配置，哪个小就以哪个为准）
7、了解redis
补充知识点：Redis:
Redis概述

内存数据库，纯内存操作，即把之前需要从数据库读取的诗句使用io，转化为读取内存数据
key-value数据库，非关系数据路
c语言编写，新能极高–如果传统方法安装：config,make
redis 支持数据持久化—必要的时候可以保存到磁盘
需要大量内存（网络带宽）
工作场景现象：登录的token保存到redis,如果redis挂了，登录失败了
redis性能指标：
性能指标：performance
内存指标：memory
基本活动指标：basic activity
持久性指标：persistence
错误指标：error
Redis配置：
1、临时配置—通过指令配置，重启应用就会失效（验证阶段时，使用临时方案）
Xx set 配置参数=10000
get 配置参数
1、进入redis容器: redis-cil -a sq
2、查看信息：info
3、CONFIG get maxclients 查看最大连接数
4、CONFIG set maxclients 5000 设置对答连接数
2、永久配置–修改对应配置文件 my.conf, redis.conf
/usr/local/redis.conf
#将容器内的文件复制到宿主机上
docker cp 容器id:/usr/local/redis.conf /root
3、修改redis本身连接数50000，压测之前的场景、一样报错，改回之前的10000配置
4、问下开发，你的springboot项目配置文件写多少
Maiosha3.0项目里面的文件配置：连接数时1000
5、优化下，项目配置文件 application.properties
Redis.poolMaxTotal=10000
Redis.poolMaxIdle=5000
6、回归设置后的版本
补充知识点：
redis的自测工具redis-benchmark，用来测试redis的性能，和业务没有关系
场景描述：
1、目前项目里****：miaosha应用去操作
2、直接跑开业务逻辑，直接测试组件的性能（配置参数所在服务器环境）
redis-benchmark -a sq -t get -c 100 -n 10000 :（容器内）模拟100个用户发送10000个请求
3、是不是所有的组件都要自测？
> 当你分析道这个组件可能有性能问题，可以去做这个操作
jmeter的jdbc取样器：直接去验证mysql组件，绕过业务层
性能测试正常流程：是不是用过业务层接口去执行的
Web应用的代码里写的操作数据库脚本（有对应的表，对应的数据，对应的操作）
实战五：
场景描述：验证redis是否击穿
场景1: 请求已有的商品
90%—267ms,redis使用率相对上去了
场景2: 请求没有的商品（首页没有展示这个商品）
90%—654ms ,redis使用率不会上了，mysql上去了，直接去db获取数据
补充知识点：
redis击穿、缓存雪崩
数据未加载到缓存中，或者缓存同一时间内大面积失效，从而导致所有请求都去查数据库，导致数据库cpu和内存负载过高，甚至宕机（一些服务器故障，包括服务器主机，数据库死锁或者DNS故障都可以称为宕机）；举例：比如缓存中的key设置了统一的过期时间，而在国旗时间点，有大量的请求进来，这个时候redis中没有用户请的的资源，所以所有的请求会全部涌到数据库。如果数据库有报警监测的话，可能会保一下警，然后数据库就挂掉了。如果这时候把数据重新起来，redis上还是没有缓存这些内容，数据库还是会再一次被击垮。
**优化：**在redis添加一个空对象（代码层处理）
补充知识点：
秒杀操作时，如果路径和商品的id和token确定时，可以使用接口工具并发去秒。解决方法之一。采用了（动态秒杀地址）隐藏秒杀地址，例如在原来路径的基础上加上&verifyCode=验证码等，或添加一个加密值
补充知识点：
**redis调优操作：**redis的所有数据都在内存中，而内存又是非常宝贵的资源。
1、配置优化：
（1）linux配置优化：内存优化、THP、snappiness、ulimit设置
（2）redis配置优化：
设置最大物理内存
让键名保持简短
客户端timeout设置一个超时时间，防止无用的连接占用资源
检查数据持久化策略
优化AOF和RDB，减少占用CPU时间
监控客户端的连接
限制客户端的连接数
2、缩减健值对象
3、命令处理
4、缓存淘汰方案

rabbitMQ简介：
消息传递指的是程序之间通过在消息中发送数据进行通信，而不是通过直接调用彼此来通信。
RabbitMQ是使用Erlang语言开发的开源消息队列系统，基于AMQP协议来实现。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量的要求还在其次。
**场景描述：**采用数据接口A----rabbitMQ—计费B
**测试需求：**需要测试B接口的性能
**方案一：**抓包B接口，使用jmeter直接压测B接口（不符合实际的生产性能）
**方案二：**使用MQ的生产者A接口产生消息，提供B接口消费
技术储备：
1、了解MQ
2、理解需求
3、如何使用MQ产生消息
4、采用数据接口A给MQ消息参数，不用的看B接口，只用jmeter模拟A接口高并发产生的队列的信息，就可以查看到B消费队列消息的性能
JMeter模拟AMQP
1、需要安装：amp-client-5.10.0.jar 和JMeterAMQP.jar，放到JMeter\lib\ext的目录下，重启JMeter
https://github.com/jlavallee/JMeter-Rabbit-AMQP.
2、用rabbitMQ自带的监控工具。监控MQ的内存,设置成服务器内存的0.5
进入MQ容器，rabbitmqctl

通常MQ测试是个链路测试，A接口—AMQP-- B接口
总结性能分析调优：