Client/Server instantion kerfuffle about jmeter-prometheus-plugin HOT 7 CLOSED

Adding some info,
When a test is launched in a distributed environment with n "servers" Jmeter starts n exporters and servers, one for each "server". This causes n-1 exceptions on the http listening port of the exporter already being used by the 1 exporter that has been succesfully launched. I see 2 roads ahead here.

1. Using a single http exporter by implementing the factory pattern.
2. Being able to launch exporters directly on "server" instances and configure prom to scrape from them. This also offloads jmeter from gathering results.

from jmeter-prometheus-plugin.

A benefit of the second option is that it will give us for free the possibility to "slice and dice" the data also from the "server" perspective. This could be really usefull to:

1. keep track of the differences when a test is executed from different (geo)location
2. spot anomalies in the test farm

Having the same through the first option could result in overlabeling...

from jmeter-prometheus-plugin.

In researching this issue it seems I implemented Remoteable which forced only one instantiation on the client.

It was a mistake, so really this is a bug, we should definitely instantiate on the servers.

from jmeter-prometheus-plugin.

I changed this to a bug because that's what I believe it now to be. I had always intended the server to boot on the server and never send data back to the client.

As I started to create a pull request for a fix branch I noticed you have a branch for BackendClient. Reading the documentation for the interface it says it creates 1 per thread and perhaps more. I think just relying on NoThreadClone is a better approach.

I'm creating the pull request now that will revert the factory @GiovanniPaoloGibilisco had implemented. Once that's sorted, then we can evaluate this branch which already has the UI refactor in it.

I'm in no rush to pull it in quickly.

from jmeter-prometheus-plugin.

From the jmeter developer mail list I was suggested to look at the BackendListenerClient implementation of InfluxDB and Graphite exporters. This branch implements the exporter as a BackendListenerClient but still this relies on the fact that the Client receives samples from the servers. I've also inspected the idea of extending the BackendListener but this is definetly not the way to go.

from jmeter-prometheus-plugin.

Oh I see. With the NoThreadClone or the singleton you had implemented you still boot 1 server per JVM. But, if you're trying to boot multiple servers (JVM/processes) on one single instance (machine) you'll still get port binding errors in either case.

Is that what you were trying to do? If so, you may want to try to use the __Random function and bind to a random port. Of course that doesn't make auto discovery easy, but ideally Jmeter servers and host servers should be 1:1.

from jmeter-prometheus-plugin.

No, I was trying to avoid running multiple http servers inside the JVM with the Jmeter Client. This was a temporary fix due to the fact that multiple instances of the exporter were running on the client instead of running on the server. I would prefer to stick with the default 9270 port and allowing customization.

from jmeter-prometheus-plugin.