[ https://issues.apache.org/jira/browse/KAFKA-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14208497#comment-14208497 ]
Jun Rao commented on KAFKA-1481: -------------------------------- 65. The following are some of the choices that we have. (1) kafka.server:type=BrokerTopicMetrics,name=AggregateBytesOutPerSec (2) kafka.server:type=AggregateBrokerTopicMetrics,name=BytesOutPerSec (3) kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec (4) kafka.server:type=BrokerTopicMetrics,name=AllTopicsBytesOutPerSec (5) kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec,allTopics=true (6) kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec,topics=aggregate The following is my take. The issue with (1), (2) and (3) is that it's not obvious which dimension is being aggregated upon. I also don't quite like (2) since it breaks the convention that type is the class name. If we do go with this route, I'd prefer that we explicitly create an AggregateBrokerTopicMetrics class instead of sneaking in the prefix in KafkaMetricsGroup. (4), (5) and (6) will all make it clear which dimension is being aggregated upon. (4) is a bit weird now that we support tags since the main purpose of tags is that we don't have to squeeze everything into a single name. So, either (5) and (6) looks reasonable to me. Also, I am not sure how jconsole displays mbeans, but the key/value pairs in the mbean name are supposed to be unordered. [~jjkoshy], what's your take? As for the mbean for the Kafka version, could we do that in a separate jira? The approach seems reasonable. > Stop using dashes AND underscores as separators in MBean names > -------------------------------------------------------------- > > Key: KAFKA-1481 > URL: https://issues.apache.org/jira/browse/KAFKA-1481 > Project: Kafka > Issue Type: Bug > Components: core > Affects Versions: 0.8.1.1 > Reporter: Otis Gospodnetic > Priority: Critical > Labels: patch > Fix For: 0.8.3 > > Attachments: KAFKA-1481_2014-06-06_13-06-35.patch, > KAFKA-1481_2014-10-13_18-23-35.patch, KAFKA-1481_2014-10-14_21-53-35.patch, > KAFKA-1481_2014-10-15_10-23-35.patch, KAFKA-1481_2014-10-20_23-14-35.patch, > KAFKA-1481_2014-10-21_09-14-35.patch, KAFKA-1481_2014-10-30_21-35-43.patch, > KAFKA-1481_2014-10-31_14-35-43.patch, > KAFKA-1481_2014-11-03_16-39-41_doc.patch, > KAFKA-1481_2014-11-03_17-02-23.patch, > KAFKA-1481_2014-11-10_20-39-41_doc.patch, > KAFKA-1481_2014-11-10_21-02-23.patch, > KAFKA-1481_IDEA_IDE_2014-10-14_21-53-35.patch, > KAFKA-1481_IDEA_IDE_2014-10-15_10-23-35.patch, > KAFKA-1481_IDEA_IDE_2014-10-20_20-14-35.patch, > KAFKA-1481_IDEA_IDE_2014-10-20_23-14-35.patch, alternateLayout1.png, > alternateLayout2.png, diff-for-alternate-layout1.patch, > diff-for-alternate-layout2.patch, originalLayout.png > > > MBeans should not use dashes or underscores as separators because these > characters are allowed in hostnames, topics, group and consumer IDs, etc., > and these are embedded in MBeans names making it impossible to parse out > individual bits from MBeans. > Perhaps a pipe character should be used to avoid the conflict. > This looks like a major blocker because it means nobody can write Kafka 0.8.x > monitoring tools unless they are doing it for themselves AND do not use > dashes AND do not use underscores. > See: http://search-hadoop.com/m/4TaT4lonIW -- This message was sent by Atlassian JIRA (v6.3.4#6332)
