Enable/Disable sending of Metrics by properties in InfluxdbBackendListenerClient and InfluxDBRawBackendListenerClient

[dgetzlaf]

Description

Introduce listenerIsEnabled to InfluxdbBackendListenerClient and InfluxDBRawBackendListenerClient. By this it is possible to enable/disable the sending of Metrics by properties (like in the Dynatrace/MINT Backend Listener)

Motivation and Context

When running the same testplan in different environments, I can not always rely on the accessibility to my InfluxDB. (Here I get the log file spammed by errors that are preventable.) With this, I can configure i.e. by properties or groovy code, if i can send metrics to my InfluxDB:

• ${__P(InfluxdbBackendListener.enabled, true)}
• ${__groovy(org.apache.commons.lang3.SystemUtils.IS_OS_LINUX)}

The idea is copied from the MintBackendListener.

By default the listener is always enabled and must be disabled explicitly.

How Has This Been Tested?

Locally tested the InfluxdbBackendListenerClient with

• enabled=true Log message "InfluxdbBackendListenerClient will send metrics: true" and sending of metrics
• enabled=false Log message "InfluxdbBackendListenerClient will send metrics: false" and NO sending of metrics
• enabled=faaaaaalse Log message "InfluxdbBackendListenerClient will send metrics: false" and NO sending of metrics

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• [ ] My code follows the code style of this project.
• [ ] I have updated the documentation accordingly.

[vlsi]

WDYT of something like https://github.com/apache/jmeter/pull/6478 instead?

[dgetzlaf]

WDYT of something like #6478 instead?

Hi @vlsi , I see, that's even a better idea - and a standardization across some components would come in handy :)

But I'm not sure, if I'm missing something: For test design I still use the GUI - will there be (for every supporting component) a new field for an expression to enable/disable it? Or is this only possible when using the API and generate the test plan?

[vlsi]

Or is this only possible when using the API and generate the test plan?

Sure the idea is to support both UI and programmatic API. I just drafted the test first to see how complicated would it be to implement the basic features.

I've drafted a UI as well: https://github.com/apache/jmeter/pull/6478 A "funny" problem is that curently JMeter dims disabled components, and it is not clear if it should display "conditionally enabled" as "regular" (==always enabled) or "dimmed" (==always disabled). I'm leaning towards "display conditionally enabled" just like the regular (always enabled) ones. I don't like color-only based distinction much for accessibility reasons.

[dgetzlaf]

I understand your funny problem; in my opinion you should stick to "display conditionally enabled" as that's the default. This might also reduce the possible overhead/noice during an update of the testplan.

But could your change lead to performance drop (number of executed sampler), since the isEnabled() evaluates the JavaScript/Groovy code everytime? Or am I mistaken here?

[vlsi]

since the isEnabled() evaluates the JavaScript/Groovy code everytime?

That is right. However, the default case is that "enabled" is either unset or set to true, so it should not be as devastating as executing Groovy or JavaScript for every sampler execution.

We should probably support case like enabled=${__P(InfluxdbBackendListener.enabled, true)} so it won't spawn full Groovy/JavaScript runtime. I'll add a test so ensure such pattern works.