C001: Continuous Integration JMeter

  • Author(s): @yufeiminds
  • Approver: @coanor
  • Status: In Review
  • Last updated: 2023-05-14
  • Discussion at: GitHub issues (comma separated, filled after thread exists)

Abstract

This proposal describes a component to upload JMeter Logs to Guance Cloud.

JMeter Demo

It will be used in continuous integration pipelines, such as GitHub Action, GitLab CI, etc.

Background

JMeter is a popular tool for load testing. It is widely used in the continuous integration pipelines.

In real-world usages, there are two use cases for JMeter:

  1. Load generation. In this use case, JMeter is a long-time running process. It will send pre-defined requests to the target system. And then record the response time and other metrics. The metrics will be used to evaluate the performance of the target system.
  2. Acceptance testing. In this use case, JMeter is invoked by the continuous integration pipeline. It is mainly used to verify the correctness of the target system and compare the JMeter metrics changes between the source code version from version control systems such as Git.

Proposal

DataKit Plugin will implement the load generation use case. Because DataKit is a long-time running process. It is more suitable to collect JMeter logs living.

This proposal focuses on the acceptance testing use case.

Command-Line Arguments

We should implement a new sub-command guance ci upload jmeter to upload JMeter logs to Guance Cloud.

ArgumentDescription
tagsThe tags of the request.
Examples: --tags k1:v1 --tags k2:v2
serviceThe service name.
Examples: foo
envThe environment identifier.
Examples: production

Collect JMeter logging

The JMeter logs contain the following tags:

TagDescription
labelThe label of the request.
Examples: Upload Metrics Data
responseCodeThe response code of the request.
Examples: 200
responseMessageThe response message of the request.
Examples: OK
threadNameThe thread name of the request.
Examples: Thread Group 1-1
dataTypeThe data type of the request.
Examples: text
successThe success of the request.
Examples: true
failureMessageThe failure message of the request.
Examples: Test failed: code expected to contain /200/

The JMeter logs contain the following fields:

FieldDescription
elaspedThe elapsed time of the request.
Examples: 2615
bytesThe bytes of the request.
Examples: 496
sentBytesThe sent bytes of the request.
Examples: 608
grpThreadsThe group threads of the request.
Examples: 147
allThreadsAll threads of the request.
Examples: 147
URLThe URL of the request.
Examples: https://openway.guance.com/v1/write/metric?token=...
LatencyThe latency of the request.
Examples: 2610
IdleTimeThe idle time of the request.
Examples: 0
ConnectThe connect time of the request.
Examples: 1665

The typical JMeter logging example is shown below:

timeStamp,elapsed,label,responseCode,responseMessage,threadName,dataType,success,failureMessage,bytes,sentBytes,grpThreads,allThreads,URL,Latency,IdleTime,Connect
1662531305870,2615,Upload Metrics Data,200,OK,Testing 1-1,,true,,496,608,147,147,https://openway.guance.com/v1/write/metric?token=...,2610,0,1665
1667975613816,408,Login,Non HTTP response code: java.net.UnknownHostException,Non HTTP response message: testing-ft2x-auth-api.cloudcare.cn: Name does not resolve,Testing 1-2,text,false,,2341,0,1,1,http://testing-ft2x-auth-api.cloudcare.cn/api/v1/auth/signin,0,0,408

It is a CSV format. The first line is the header. The following lines are the JMeter logging.

Collect Git-related information

The Git-related information contains the following tags:

TagDescription
git_repository_urlThe URL of the git repository.
Examples: https://github.com/GuanceCloud/community.git
git_branchThe branch of the git repository.
Examples: main
git_tagThe tag of the git repository.
Examples: v1.0.0
git_commit_shaThe commit sha consists of the git repository.
Examples: b1b9c2c
git_messageThe message of the git repository.
Examples: docs: Add JMeter documentation
git_author_nameThe author name of the git repository.
Examples: guance-bot
git_author_emailThe author email of the git repository.
Examples: developer@guance.com
git_author_dateThe author date of the git repository.
Examples: 2021-05-14T08:00:00Z
git_committer_nameThe committer name of the git repository.
Examples: guance-bot
git_committer_emailThe committer email of the git repository.
Examples: developer@guance.com
git_committer_dateThe committer date of the git repository.
Examples: 2021-05-14T08:00:00Z

Collect Runtime-related information

The Runtime-related information contains the following tags:

TagDescription
platformThe platform of the environment.
Examples: windows, darwin, linux
archThe architecture of the environment.
Examples: amd64, arm64
osThe operating system of the environment.
Examples: windows 10, macos 11.3.1, ubuntu 20.04

Rationale

What are the differences between this Guance CLI and DataKit JMeter Plugin?

The running time is the crucial difference between the Guance CLI and DataKit Plugin.

  • The Guance CLI is a short-time running process. It will only execute once in the continuous integration pipelines. And you can easily integrate it with most of the open-source CI pipeline ecosystems, such as GitHub Action, GitLab CI, etc.
  • The DataKit Plugin is a long-time running process. In most use cases, it will collect the metrics by the scheduler or stream living. It will keep running in any client workload, such as Virtual Machine, Kubernetes, etc.

So in a real-world use case. We generally use the Guance CLI and DataKit JMeter Plugin both. The CLI is used in the development stage, helping us to manage the SDLC (Software Development Life Cycle). The DataKit Plugin is used in the production stage to help us to manage the SLO (Service Level Objective). We use both in Guance Cloud to help us manage all the metrics data and archive Testing Observability.

Implementation

  1. Create a new component in the Guance CLI repository.
  2. Create a GitHub Action to set up the Guance CLI.
  3. Create an interactive example to show how to use the component.
Last updated on