这几天在重新部署我的云服务器上的k8s新版本玩，打算试一下k8s新版本的特性。

一堆服务的装，过程也是艰辛。总是会遇到网上都查不着的问题。还有一些是网上说的错误的解决方法。不再多说，否则跟文章名不相符了。

加了prometheus和influxdb、grafana做监控之后，也是想测试一下，看一下有数据的样子，于是拿出jmeter，配置上backend listener。

在grafana中加上个dashboard等步骤。这些网上都有详细的说明文档。

简单的跑起来之后，大概看到这样的监控页面。

之所以要写这个文章是要说明这些数据为什么要这样展现。

这里分成两个部分，一部分是summary的，一部分是针对具体事务的。非常直观。

然后再看筛选器。

我们知道这些数据都来自于backend listener。所以来看看Backend listener的配置。

这里的application是对应着的，transaction也是脚本中自己定义的。

jmeter要发给influxdb，怎么发呢。有两个关键部分。如下所示：

上面是取到数据，然后通过下面这一段发给influxdb。

然后我们再来看influxdb中如何存。

也就是说在influxdb中，创建了两个MEASUREMENTS，events和jmeter。里面各自存了数据，我们在界面中配置的testtile和eventTags放在了events这个measurement中。在很多模板中这个表都是不用的。我们在配置dashboard的时候，会有这样的选择。

这里就写明了要从哪个measurement取数据。

其实在项目的具体实施的角度上来看，testtile和eventTags还是有用的。一般我们都大概会用：

项目 - 场景 - 业务脚本（事务也在这里定义） - 轮次

这样的结构来确定某个测试结果。

这里的testtile就可以对应到场景中去。但是现在这样的表设计并不能实现这一点。拿来主义总是有不尽如人意的地方。

还有一个eventTags也是可以扩展来用的。为什么会需要这样的场景呢。

因为现在的云服务器基本上，在各地都会有，在不同的城市的数据中心，如果我们有一个场景是要这样来做云架构的测试场景。

在测试结果中，我们希望能确定各压力机的区域以及所运行的相同事务在响应时间上的区分。这些过滤参数就会比较有用了。

再来说一下数据。这些数据还是比较简单和笼统的，如果要定位的更细一些。像loadrunner中的webpage diagnostics的功能。

那就要求的太多了。既然不能这样，只能通过其他的手段来做。也就是微服务中必然要做的链路监控和日志分析。

看两个重要的图中的数据query吧。

上面这个就是TPS了。在这里称为throughput。

这是95 pct的响应时间。

后面我会把jmeter做成容器，再指定node来运行。因为jmeter做为java的应用，在做gc的时候不可避免地影响TPS。多实例运行是必然的。

今天先写到这吧。