-
Notifications
You must be signed in to change notification settings - Fork 133
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
Make consumer metric collection more configurable #1153
Comments
My vote is for option 2, exposing a new type State-like type dedicated for metrics. |
There is only 1 proposal consisting of 3 points :) |
D'oh 😅 I guess I need some caffeine first. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
PR #1143 introduces the new trait
ConsumerMetrics
. We see opportunity to increase the number of metric use cases by allowing users to plug in their own implementations.These use cases come to mind:
ZioConsumerMetrics
(the boundaries are declared asprotected
so overriding is already possible).ConsumerMetrics
.One problem that needs to be solved is that trait
ConsumerMetrics
uses the completely internal typeRunloop.State
. The typeRunloop.State
has moved around and changed many times in zio-kafka's history. Something that is possible because it is an internal private type. ExposingRunloop.State
is therefore not attractive.A possible solution:
ConsumerMetrics
to thezio.kafka.consumer.metrics
package.Runloop.State
with something that does not expose internal types.ConsumerSettings
.Considerations
The text was updated successfully, but these errors were encountered: