In a JMeter dashboard, how do you show only a few named transactions in the graphs?

## The property and its shape The key is long because it is scoped to one exporter: ```properties # bin/user.properties jmeter.reportgenerator.exporter.html.series_filter=^(Search|Order)(-success|-failure)?$ jmeter.reportgenerator.exporter.html.filters_only_sample_series=true ``` `jmeter.reportgenerator.exporter.html.` is the prefix for the HTML exporter; `series_filter` is a regular expression matched against the name of each series in a graph — and against the row labels of the summary tables. Its default is empty, which means no filtering at all: every sampler in the results file gets a series in every graph. ## Why the (-success|-failure)?$ tail matters This is the detail that catches people. Not every graph names its series after the sampler alone. The transactions-per-second consumer builds each series name as the sample label, a hyphen, and then `success` or `failure` depending on the result. A filter of `^(Search|Order)$` matches the response-time series and misses every per-second series, so those graphs come out empty while the others look right. Ending the pattern with the optional group `(-success|-failure)?$` covers both spellings, which is why the shipped example and the manual both carry it. ## Where in the pipeline it applies Two filters exist and they are not interchangeable: | Property | When it acts | Effect | |---|---|---| | `jmeter.reportgenerator.sample_filter` | before the calculations | discards samples, so they are absent from every figure | | `jmeter.reportgenerator.exporter.html.series_filter` | after the calculations | keeps the figures intact and hides series and rows from the output | That difference decides which one you want. To make a report about a subset of the traffic, the numbers themselves must exclude the rest, and dropping samples is the tool. To keep the numbers whole but make a 300-series chart legible, the exporter filter is the tool, and it is the one this leaf is about. ## The companion switches The HTML exporter has two more properties that interact with the filter: - **`filters_only_sample_series`**, default `true`. The filter is applied only to graphs whose series stand for samples; a graph whose series are not sampler labels — Active Threads Over Time, where each series is a thread group — is left alone. Set it to `false` and the filter applies to everything, which is a documented way to end up with empty graphs when the pattern does not name those series too. - **`show_controllers_only`**, default `false`. When set, only controller series are displayed — and on a graph that is configured to exclude controllers, the combination yields nothing and a warning saying so. ## Failure is quiet An over-narrow pattern does not fail the generation. The exporter checks whether any series in a graph matched, and when none did it logs ``` No series matches the series_filter: series_filter in graph: <graphId> ``` at WARN level and renders the graph empty. Since report generation at the end of a run swallows and logs its problems anyway, an empty dashboard from a bad regular expression is entirely silent unless somebody reads the log. Check a new filter against a small results file before putting it in a scheduled job. ## Practical use The common shape is a plan with dozens of samplers and a handful of business transactions worth charting: 1. name those transactions deliberately in the plan; 2. write the filter as an alternation of exactly those names, anchored at both ends, with the success and failure suffixes allowed; 3. rebuild the report from the existing results file with `-g` and look at the transactions-per-second graph first, because that is the one that reveals a missing suffix. Because it is a report-time property, iterating on the regular expression costs a regeneration, not a new run.