DevOps AcademyLearn the delivery system
Chapter 24Lesson 03~205 minutes

Backend Listener, InfluxDB/Graphite, Grafana, and Real-Time Telemetry: Configuration, Design Patterns, and Trade-Offs

A telemetry pipeline can become more complex than the performance test it is supposed to explain. The design goal is not “send everything to Grafana.” It is to preserve a small, stable metric schema whose cost, cardinality, retention and semantic ownership are known—while raw JTL and service evidence remain independently reviewable.

InfluxDB vs GraphiteTags/cardinalityCompose vs nativeLive vs HTMLRetention

Learning objectives

  • Choose InfluxDB, Graphite, or architecture-only simulation based on local constraints.
  • Choose Backend Listener plus JTL versus JTL-only based on live-diagnosis needs and overhead budget.
  • Design low-cardinality tags and stable sampler labels.
  • Choose send interval/window/detail level from time resolution and generator cost.
  • Choose local Compose/native stack versus centralized telemetry deployment.
  • Choose centralized Grafana history versus immutable per-run HTML/JTL artifacts.

1. Mandatory learning remains free/local-compatible

The executable path remains localhost-only on 127.0.0.1. Managed Grafana/InfluxDB, commercial APM, shared performance clusters, Kubernetes and paid CI are optional contexts. A native InfluxDB/Grafana installation or architecture-only walkthrough can replace Compose where containers are unavailable. The mandatory design uses synthetic data and no real credentials.

2. InfluxDB versus Graphite

InfluxDB Backend Listener Graphite Backend Listener
HTTP write integration; measurements/tags/fields/timestamps. Hierarchical dot-separated metric paths.
JMeter v2 integration supports token + org/bucket URL. Text sender or more efficient Pickle sender for larger volumes.
Grafana InfluxDB datasource supports InfluxDB OSS 1.x/2.x/3.x with version-specific query languages. Grafana Graphite datasource is a common live-metrics alternative.
Custom TAG_* values make dimensional filtering easy—but increase series cardinality. Dimensions often become path segments; dynamic labels/prefixes increase metric-path count.
Lab choice because v2 HTTP setup is simple to inspect locally. Good when an organization already operates Graphite/carbon and wants a compact hierarchy.

3. Backend Listener plus JTL versus JTL-only

JTL-only is simpler, cheaper and strongest for post-run forensic analysis. It is sufficient when tests are short and no live operational correlation is needed.

Backend Listener + lean JTL adds live time correlation and centralized history at the cost of queue/client CPU, network writes, backend storage and another failure domain. Keep JTL because Backend Listener aggregates/windows metrics and is not a lossless per-sample replacement.

4. Aggregated Influx client versus raw Influx client

The standard InfluxdbBackendListenerClient aggregates interval metrics. InfluxDBRawBackendListenerClient writes every sample result. Current JMeter documentation explicitly notes the raw implementation uses more resources in both JMeter and InfluxDB.

Choose raw only when per-sample central querying is a real requirement and the generator/backend budget has been measured. Chapter 24's mandatory path uses aggregate live metrics plus raw JTL.

5. Metric granularity and tag cardinality

Dimension Good tag/label? Why
application=p24-lab Yes Small stable set.
env=local|perf Usually Small bounded set.
run_id Conditionally Useful isolation; cardinality grows with retained runs, so retention matters.
sampler/transaction label Yes if stable Core comparison dimension; avoid IDs/timestamps in labels.
user ID / order ID / UUID No Potentially one series per request/user/order.
Authorization token / session ID Never Sensitive and high-cardinality.
full URL with query IDs Usually no Privacy/cardinality explosion; normalize path or use stable label.

6. Send interval versus metric window

A shorter send interval improves time resolution but increases HTTP/socket/write frequency. A larger percentile window can stabilize live percentiles but retains more samples and can blur rapid phase changes. JMeter's timed large-window property explicitly warns that excessive values can lead to OOM.

Start from defaults. Shorten/increase only for a documented diagnosis requirement and measure generator/backend impact.

7. summaryOnly and sampler filtering

summaryOnly=true sends only cumulative “all” metrics. It minimizes series count but loses operation-level visibility. summaryOnly=false plus a narrow stable regex sends selected sampler series.

For a complex plan, report only business-critical stable labels rather than .* by default.

8. Compose stack versus native/architecture-only path

Local Compose Native binaries / architecture-only
Pinned, disposable, reproducible service versions and ports. Useful where container runtime is unavailable/restricted.
Easy cleanup with named volumes/container removal. Native services need explicit data/config/service cleanup.
Co-location can create host-resource contention with JMeter/target. Separate hosts can reduce contention but add clock/network complexity.
Container resource state is visible via docker stats. Native process/JVM/OS metrics use platform tools.

Containerization is deployment mechanics, not a telemetry semantic requirement. JMeter only needs a reachable backend endpoint compatible with the chosen client.

9. Centralized Grafana versus per-run HTML report

Grafana is strong for long-running/live comparisons, shared operational context, annotations and cross-system panels. Per-run HTML is immutable, portable and reproducible from JTL without a live service.

A mature system often keeps both: Grafana for live/history and JTL+HTML/manifests for auditable run artifacts.

10. Retention is a cardinality/cost control

Time-series retention defines how long unique run IDs/series occupy storage/index state. A run ID that is acceptable at 7-day retention can become expensive at multi-year retention. Establish retention per environment and preserve long-term conclusions in immutable run reports rather than retaining every live metric forever.

11. Tags and dashboards are data-governance surfaces

Influx tags are indexed and Grafana dashboards expose them to users with datasource access. Never tag tokens, cookies, real user identifiers or sensitive URL query values. Stable synthetic environment/run labels are sufficient for the mandatory lab.

12. Layer boundaries

Layer Examples Do not confuse with
JMeter core Backend Listener queue/client, samplersRegex, summaryOnly, percentiles, tags Java GC or Grafana query processing.
Java/JVM JMeter heap/GC/thread scheduling InfluxDB storage or target service CPU.
OS/network loopback/socket bandwidth, file/disk contention, host clock SampleResult semantics.
SUT configured delay, inflight, server CPU/DB/cache JMeter active threads/response time.
Backend/plugin InfluxDB/Graphite storage/query/client protocol Target business correctness.
CI/container container CPU/memory, workspace/network, service startup Production capacity unless separately measured.

13. Worked scenario

A 2-hour soak needs live detection of API latency spikes and JVM GC pauses. The organization already stores infrastructure metrics in Grafana/Graphite.

  • Prefer GraphiteBackendListenerClient instead of adding a second InfluxDB platform solely for JMeter.
  • Keep lean JTL locally for per-sample forensic analysis.
  • Use stable sampler labels for critical journeys, summaryOnly=false with a narrow allow-list/regex.
  • Publish run ID/build SHA only if retention/cardinality budget supports it.
  • Correlate JMeter response time with independently collected application JVM/GC metrics; do not rename JMeter response time “server GC latency.”

14. Decision table

Need Preferred approach Evidence/validity
Short local regression, no live triage JTL + HTML only Lowest telemetry overhead.
Live local teaching/correlation InfluxDBBackendListenerClient + lean JTL Explicit queue/send/tags + target metric + overhead measurement.
Existing Graphite estate GraphiteBackendListenerClient Reuse existing backend/schema; Pickle for larger volume if appropriate.
Per-sample central analytics Raw Influx client only after measurement Higher JMeter/backend cost; raw JTL may already satisfy need.
Long soak shared dashboard Backend Listener + SUT telemetry + central Grafana Clock sync, retention/cardinality, backend resilience required.
Immutable release evidence JTL + HTML + manifest even when Grafana exists Reproducible, backend-independent audit trail.

15. Configured versus achieved load

Backend telemetry shows completed/aggregated client samples, not configured intent. Always compare expected sample count/rate with JTL and target events. If telemetry overhead saturates generator CPU/network or a blocked backend reduces achieved work, the test is invalid even if Grafana looks smooth.

Preserve the matching JTL + jmeter.log, backend config, metric query, target metric/events, generator resource evidence and retention/cardinality note for every live-telemetry comparison.

Knowledge check

Why might Graphite be preferable to InfluxDB in an existing organization?

Why is summaryOnly=false not automatically better?

Why retain per-run HTML when Grafana stores history?

What makes a run_id tag dangerous at long retention?

What must be true before comparing live p95 across two runs?

Next lesson

Diagnose telemetry failures without blaming the target

Lesson 4 covers cardinality explosion, secret tags, blank/misleading Grafana panels, backend overload/unavailability, clock skew and client/server metric confusion.

Official references and version notes

Version and compatibility note

Version-sensitive statements were rechecked against current primary documentation on 2026-09-05. The JMeter course baseline remains Apache JMeter 5.6.3 with a Java 17 JDK; JMeter 5.6.3 requires Java 8+. JMeter's Backend Listener is asynchronous and accepts an explicit queue size. JMeter ships with GraphiteBackendListenerClient and InfluxdbBackendListenerClient; since JMeter 5.4 it also ships InfluxDBRawBackendListenerClient, which JMeter explicitly warns consumes more JMeter and InfluxDB resources because it writes every sample individually. The standard InfluxDB client supports InfluxDB v2 by supplying an influxdbToken plus org/bucket in the influxdbUrl. The built-in Influx backend send interval defaults to 5 seconds; this tiny lab deliberately sets it to 1 second for visible time correlation. The default backend percentiles are 90/95/99. Backend metric windows default to fixed mode with a 100-sample window; a too-large timed window can create memory pressure. The lab pins InfluxDB OSS 2.9.1 and Grafana OSS 13.2.1 rather than floating container tags. InfluxDB 3 is the newest InfluxDB product line, but the mandatory lab intentionally uses the documented JMeter v2 write integration. Grafana 13.2.1's InfluxDB datasource supports InfluxDB OSS 2.x and Flux. No third-party JMeter plugin is required.

Keep the academy open

Support free, practical DevOps education.

Every lesson is designed to remain readable in a browser, downloadable from GitHub, and usable without a paid learning platform. Contributions help expand and maintain the curriculum.

Ethereum / ERC-20
0x716c4Ab160C4B66F31a28AE2448BfF68fc3a2ef0 Send only Ethereum/ERC-20 compatible assets to this address.