Status

Current state: "Under DiscussionVoting in progress"

Discussion thread: here

Voting thread: here

JIRA: here

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

...

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

1. Add new metrics metric mentioned above
2. Update ConsumerFetchRequestsPerSec metric only when the fetch request is coming from client only (-1 != replicaId). Otherwise, update ReplicationFetchRequestsPerSec.

Compatibility, Deprecation, and Migration Plan

...

1. Do not provide new metrics - does not satisfy the need in environment where cluster owner has no knowledge about clients.
2. 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:
   1. 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)
   2. drawbacks: increased footprint (extra metric per topic & need to update it per request)
   As proposed change, just change TotalFetchRequestsPerSec to be a gauge that adds values from ConsumerFetchRequestsPerSec and ReplicationFetchRequestsPerSec.
   Same as point 2.