You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jira@kafka.apache.org by GitBox <gi...@apache.org> on 2021/08/23 18:49:13 UTC

[GitHub] [kafka] rondagostino commented on pull request #11133: KAFKA-13140: KRaft brokers do not expose kafka.controller metrics

rondagostino commented on pull request #11133:
URL: https://github.com/apache/kafka/pull/11133#issuecomment-904022863


   > I am not sure we should expose controller metrics for brokers that don't have the controller role.
   
   I agree it is a bit counter-intuitive.  Now that you bring up this hesitance, here is how I see it.
   
   It *may* make sense from a backwards-compatibility perspective: those metrics are there on non-controllers today with values equal to 0, so it could be argued that for compatibility purposes they should be there for non-controller KRaft nodes.
   
   That being said, though, the reason the controller metrics are available on ZK-based brokers today is because those brokers may soon be elected as the controller -- they are "controller-eligible".  A KRaft node that has `process.roles=broker` is not controller-eligible, so that's an argument against exposing the controller metrics on KRaft broker nodes.  Similarly, today we expose broker metrics on a node that is the (ZK-based) controller because that node **is** also a broker.  A KRaft node with `process.roles=controller` does not currently expose broker metrics -- we have not made any such backwards-compatibility argument for this case and probably would not do so given the volume of metrics and the fact that the node it is not broker-eligible.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: jira-unsubscribe@kafka.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org