skip to content

Live Metric Streaming

3 roadmaps6 questions

Pushing metrics out during a run with a Backend Listener, plus the summariser lines the console prints in CLI mode. Interviewers ask how much detail you emit before the cardinality bill arrives.

on this pageshow

explore

questions

6

In JMeter, which element streams metrics to InfluxDB or Graphite while a test runs?

level: juniorimportance: must knowfreq 66%

answer

  1. A listener that pushes, not stores
  2. Configured by a name/value Parameters table
  3. A pluggable client class does the transmitting
  4. InfluxDB and Graphite clients ship with it

basics

~10 s

The Backend Listener. Pick a BackendListenerClient implementation - InfluxdbBackendListenerClient or GraphiteBackendListenerClient - then fill its Parameters table with the target URL or host and port, and metrics leave the injector during the run.

solid answer

~50 s

JMeter 6.0.0 ships one listener designed to emit metrics mid-run: the **Backend Listener**. It has three things to set - **Backend Listener implementation** (a fully-qualified `BackendListenerClient` class), **Async Queue size** (default `5000`), and a **Parameters** table holding that client's own arguments. Three implementations ship in the box; two of them aggregate. `InfluxdbBackendListenerClient` is configured with `influxdbUrl` (plus `influxdbToken` for InfluxDB 2), `application`, `measurement` and `testTitle`. `GraphiteBackendListenerClient` is configured with `graphiteHost`, `graphitePort` (default `2003`), `rootMetricsPrefix` (default `jmeter.`) and a `graphiteMetricsSender` class. Sample results are handed to a background worker thread that aggregates them into per-label statistics; the client's own scheduled thread then flushes those on a fixed cadence - every 5 seconds for the InfluxDB client, every 1 second for the Graphite one. None of this depends on GUI mode; it is the normal way to watch a CLI run.

code

xml · 34 lines
xml
<BackendListener guiclass="BackendListenerGui" testclass="BackendListener" testname="Live metrics" enabled="true">
  <elementProp name="arguments" elementType="Arguments" guiclass="ArgumentsPanel" testclass="Arguments" enabled="true">
    <collectionProp name="Arguments.arguments">
      <elementProp name="influxdbMetricsSender" elementType="Argument">
        <stringProp name="Argument.name">influxdbMetricsSender</stringProp>
        <stringProp name="Argument.value">org.apache.jmeter.visualizers.backend.influxdb.HttpMetricsSender</stringProp>
        <stringProp name="Argument.metadata">=</stringProp>
      </elementProp>
      <elementProp name="influxdbUrl" elementType="Argument">
        <stringProp name="Argument.name">influxdbUrl</stringProp>
        <stringProp name="Argument.value">http://influx:8086/write?db=jmeter</stringProp>
        <stringProp name="Argument.metadata">=</stringProp>
      </elementProp>
      <elementProp name="application" elementType="Argument">
        <stringProp name="Argument.name">application</stringProp>
        <stringProp name="Argument.value">checkout</stringProp>
        <stringProp name="Argument.metadata">=</stringProp>
      </elementProp>
      <elementProp name="measurement" elementType="Argument">
        <stringProp name="Argument.name">measurement</stringProp>
        <stringProp name="Argument.value">jmeter</stringProp>
        <stringProp name="Argument.metadata">=</stringProp>
      </elementProp>
      <elementProp name="testTitle" elementType="Argument">
        <stringProp name="Argument.name">testTitle</stringProp>
        <stringProp name="Argument.value">Nightly 12h soak</stringProp>
        <stringProp name="Argument.metadata">=</stringProp>
      </elementProp>
    </collectionProp>
  </elementProp>
  <stringProp name="classname">org.apache.jmeter.visualizers.backend.influxdb.InfluxdbBackendListenerClient</stringProp>
  <stringProp name="QUEUE_SIZE">5000</stringProp>
</BackendListener>
<hashTree/>

go deeper

for a junior

Recall the element by name: Backend Listener. Know that it needs an implementation class and a Parameters table, and that InfluxDB and Graphite clients ship with JMeter.

for a middle

Explain the split between element and client: the element queues sample results, the client aggregates them and decides what a flush looks like, on its own scheduled thread.

for a senior

Show you have run one for real - where the URL and token come from in CI, what the flush interval means for the first points you see, and how you prove metrics are actually arriving.

for a principal

Own whether live streaming is worth a dependency on a metrics store at all, and what the team standardises: one client, one naming convention, one set of parameters injected per environment.

## The one listener built to push Apache JMeter 6.0.0 ships exactly one listener whose job is to get numbers **off the injector while the test is still running**: the **Backend Listener** (`testclass="BackendListener"`, `guiclass="BackendListenerGui"`). Every other listener either accumulates results in memory for a GUI table or writes them to a result file for later — with one exception, **Generate Summary Results**, which prints delta and running-total lines to the injector's own console and log. Only the Backend Listener ships them to a remote metrics store. The Backend Listener hands each `SampleResult` to a pluggable **`BackendListenerClient`**, which aggregates on a background worker thread and transmits on a timer. The element has only three things to fill in: - **Backend Listener implementation** — the fully-qualified class name of a `BackendListenerClient`. The GUI offers the shipped ones in a drop-down and rewrites the Parameters table when you switch. - **Async Queue size** — the bounded handoff between the sampling threads and the worker; the default is `5000`. - **Parameters** — a name/value table. These rows are *not* JMeter variables; they are that particular client's own arguments, and each implementation defines its own set. ## The clients in the box | Implementation | Target | The rows that matter | Flush cadence | |---|---|---|---| | `InfluxdbBackendListenerClient` | InfluxDB, over its write API | `influxdbUrl`, `influxdbToken`, `application`, `measurement`, `testTitle` | `backend_influxdb.send_interval`, default 5s | | `GraphiteBackendListenerClient` | Graphite (or InfluxDB behind its Graphite plugin) | `graphiteHost`, `graphitePort` (default `2003`), `rootMetricsPrefix` (default `jmeter.`), `graphiteMetricsSender` | `backend_graphite.send_interval`, default 1s | The Graphite client picks its wire format from `graphiteMetricsSender`: `TextGraphiteMetricsSender` for the plaintext protocol, or `PickleGraphiteMetricsSender` for the pickle protocol on port `2004`. For InfluxDB 2 the `influxdbUrl` carries `org` and `bucket` as query parameters and `influxdbToken` supplies the token. A third client, `InfluxDBRawBackendListenerClient`, writes every individual sample result rather than aggregates. ## What actually leaves the machine Each flush sends, per label the client is tracking, counts split into successful and failed, minimum, maximum and average response time, sent and received bytes, hit count, and one metric per configured percentile. Alongside those go five run-wide thread metrics — `minAT`, `maxAT`, `meanAT`, `startedT` and `endedT` — which the Graphite client publishes under a `test` context and the InfluxDB client writes into the configured measurement tagged `transaction=internal`. The InfluxDB client additionally writes an annotation into an `events` measurement when the test starts and when it ends, tagged with `application` and carrying `testTitle` as its text. ## What it is not Three confusions are worth naming up front: 1. **It is not the HTML report.** The report JMeter can generate at the end of a run is built after the fact from the result file; it does not update while the test runs. 2. **It is not a result log.** The Backend Listener sends aggregates on a timer. Per-sample rows are a separate concern and a separate file. 3. **It is not GUI-only.** Live streaming is precisely what you want in a CLI run, where there is no GUI to show you anything except the console summary lines. ## Writing one by hand Because the element is plain XML in the `.jmx`, the whole configuration can be templated and the target injected per environment. The `classname` string property holds the implementation, `QUEUE_SIZE` the async queue, and the `arguments` element property holds the Parameters table as an `Arguments` collection of `Argument` rows — exactly the shape any other JMeter arguments table uses.

  • Where in JMeter's Backend Listener do you put the InfluxDB write URL?
    In the Parameters table, as the `influxdbUrl` row - for example `http://influx:8086/write?db=jmeter`. For InfluxDB 2 the URL carries `org` and `bucket` as query parameters and an `influxdbToken` row supplies the token. The implementation field holds only the class name; it never holds a URL.
  • Does adding a Backend Listener replace the result file a run writes?
    No - they answer different questions. The Backend Listener sends aggregated counts and response-time statistics on a timer to a time-series store. The result file keeps one row per sample for after-the-fact analysis and for building the HTML report. Most CLI runs keep both.

saying these in an interview costs you the question

  • Says View Results Tree can feed a live dashboard
  • Thinks the HTML report updates while the run continues
  • Believes a dashboard reads the result file directly
  • Assumes metrics are only emitted at test end
  • Confuses the Parameters table with test-plan variables
open as a page

In JMeter's Backend Listener, what does setting summaryOnly to true do to samplersList?

level: middleimportance: must knowfreq 52%

basics

~10 s

Setting summaryOnly to true switches per-sampler metrics off entirely, so samplersList is never consulted and only the cumulated series is sent. The filter has no effect until summaryOnly is false.

open as a page

What prints the summary + and summary = lines during a JMeter CLI run?

level: middleimportance: should knowfreq 58%

basics

~20 s

A Summariser element, known in the GUI as Generate Summary Results. JMeter auto-creates one in CLI mode named by the summariser.name property, shipped as summary; + lines are the delta since the last report and = lines the running total.

open as a page

Over which samples does a JMeter Backend Listener compute the percentiles it streams?

level: seniorimportance: should knowfreq 42%

basics

~10 s

Over a fixed-size sliding window of the most recent response times - 100 values by default, set by backend_metrics_window - and never over the interval just elapsed. That window is not cleared between flushes.

open as a page

How would you decide what a team's JMeter Backend Listener emits during long soak runs?

level: principalimportance: should knowfreq 36%

basics

~20 s

Start from summaryOnly and the sampler filter: they decide whether one series or one per label leaves the injector. Then settle the percentile list, the flush interval and a label naming rule, and hold all of them in properties rather than in each plan.

open as a page

In JMeter's Backend Listener, what happens when the Async Queue size is exhausted?

level: seniorimportance: nice to knowfreq 26%

basics

~10 s

The sampling thread that produced the result blocks until the worker frees a slot. Nothing is dropped; the delay lands on the test thread, and JMeter logs a queue-wait warning once the test ends.

open as a page