...
The following new broker-side metrics are metric is proposed:
- kafka.server:type=BrokerTopicMetrics,name=ConsumerFetchRequestsPerSec
- kafka.server:type=BrokerTopicMetrics,name=ConsumerFetchRequestsPerSec,topic=mytopic (one per topic)
- kafka.server:type=BrokerTopicMetrics,name=ReplicationFetchRequestsPerSec
- kafka.server:type=BrokerTopicMetrics,name=ReplicationFetchRequestsPerSec,topic=mytopic (one per topic)
Each of them is a meter similar to It would be similar to the already-existing TotalFetchRequestsPerSec metric.
Proposed Changes
- Add new metrics metric mentioned above
- Update ConsumerFetchRequestsPerSec metric only when the fetch request is coming from client only (-1 != replicaId). Otherwise, update ReplicationFetchRequestsPerSec.
Compatibility, Deprecation, and Migration Plan
...
- Do not provide new metrics - does not satisfy the need in environment where cluster owner has no knowledge about clients.
- Provide only one of metrics, as ConsumerFetchRequestsPerSec.count + ReplicationFetchRequestsPerSec.count == TotalFetchRequestsPerSec.count.
`com.yammer.metrics.core.Meter` used underneath is exponentially weighted, so it would not be true for *Rate metrics.two metrics: ConsumerFetchRequestsPerSec and ReplicationFetchRequestsPerSec:- benefits: user is capable of accessing the desired metric without the need to find the values of others (what might be beneficial to e.g. jmxterm users)
- drawbacks: increased footprint (extra metric per topic & need to update it per request)
Same as point 2.