Make consumer metric collection more configurable

[erikvanoosten]

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:

• Change the histogram boundaries. This could be supported by allowing users to override the histogram boundaries in the current implementation, ZioConsumerMetrics (the boundaries are declared as protected so overriding is already possible).
• Use of a completely different metrics backend, e.g. Dropwizard metrics or Micrometer. This could be supported by allowing users to provide their own implementation of ConsumerMetrics.

One problem that needs to be solved is that trait ConsumerMetrics uses the completely internal type Runloop.State. The type Runloop.State has moved around and changed many times in zio-kafka's history. Something that is possible because it is an internal private type. Exposing Runloop.State is therefore not attractive.

A possible solution:

• Move the trait ConsumerMetrics to the zio.kafka.consumer.metrics package.
• In the trait, replace the parameter of type Runloop.State with something that does not expose internal types.
• Allow users to provide their own implementation via ConsumerSettings.

Considerations

• It is not yet established whether any user needs the flexibility proposed in this issue.
• Other parts of zio-kafka (producer api, admin api) do not collect metrics yet. Any solution has to be scalable to those parts as well.

[svroonland]

My vote is for option 2, exposing a new type State-like type dedicated for metrics.

[erikvanoosten]

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 :)

[svroonland]

D'oh 😅 I guess I need some caffeine first.