-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Exposing native metrics of multiple clients in the same JVM #237
Comments
@Z1kkurat why not just pass Other option: passing |
I don't think I understand the idea, can you share an example? In the first snippet of code
Please elaborate, what do you mean by "semi-static"? |
@t3hnar just for clarification -- I'm talking about native metrics exposed by the Kafka clients themselves |
The current implementation of the Prometheus collector for the native Kafka client (producer/consumer) metrics (via
Producer#clientMetrics
) can be inconvenient to use in case there are multiple consumers/producers in the same application, initialized within the scope of different modules. Let me illustrate:This code initializes two producers and registers their metrics. If we assume they are initialized within encapsulated code of different modules (files) this would probably be how we'd do it without exposing the newly created client from the encapsulated code. Unfortunately, this fails with
java.lang.IllegalArgumentException
:There's a possible workaround that partially resolves the issue:
This works, but it requires initializing all clients within the same scope which can be inconvenient in terms of code encapsulation.
I propose implementing a new abstraction over multiple clients returning metrics that keeps track of functions producing metrics for each "registered" client.
The usage would be as follows:
This works as expected with a simple Ref-based implementation, producing metrics like the following:
When
client.id
is not defined it looks a bit more confusing with both approaches (old workaround and a new proposed one), resulting in duplicate metrics, but it's still better than an exception:The text was updated successfully, but these errors were encountered: