[ 
https://issues.apache.org/jira/browse/KAFKA-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel Koshy updated KAFKA-1481:
------------------------------
    Attachment: alternateLayout2.png
                alternateLayout1.png
                diff-for-alternate-layout1.patch
                diff-for-alternate-layout2.patch
                originalLayout.png

Can you rebase? Sorry I know you have rebased a couple times already. 
Hopefully this should be the last time as these are minor comments.

KafkaMetricsGroup: 64: foreach

KafkaMetricsGroup: toMbeanName: 150/153: can you use filter { case(tagKey, 
tagValue) =>
...}


For aggregate topic metrics, since allTopics=true appears at the end it is a 
bit weird when browsing mbeans in jvisualvm/other tools. i.e., the mbean is
listed as "true". I understand why - it is just a bit weird. I'm referring 
to (for example)
kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec,allTopics=true
See the attached originalLayout.png

Personally I prefer aggregate=true to allTopics=true. A further improvement 
with aggregate=true is the following: in KafkaMetricsGroup.metricName you
can check in the tags map if aggregate=true. If so, then modify the typeName 
by pre-pending Aggregate to it and then strip off the aggregate=true tag. So
you will end up with:
kafka.server:type=BrokerTopicMetrics,name=AggregateBytesOutPerSec 

See alternateLayout1.png 

Another alternative is to modify the name (not the typeName). See 
alternateLayout2.png
                                                                 
The aggregate=true approach seems generic enough to apply to any other
all-topic, all-request, or all-broker level mbeans. What do you think?


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

Reply via email to