[
https://issues.apache.org/jira/browse/KAFKA-1100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13802642#comment-13802642
]
Jason Rosenberg commented on KAFKA-1100:
----------------------------------------
Hi Swapnil,
Unfortunately, we aren't using mbeans, but using the yammer MetricsRegistry and
a reporter class based on com.yammer.metrics.reporting.AbstractPollingReporter.
This creates a background thread that wakes up every 10 seconds and transmits
all the metrics in the registry (which is essentially all the yammer metric
mbeans) and sends them as messages over kafka. We then have time series db's
which store these. Unfortunately, the ts db's are not sophisticated enough to
allow wild-card querying....
Is there a fundamental reason for having those cryptic metric names?
> metrics shouldn't have generation/timestamp specific names
> ----------------------------------------------------------
>
> Key: KAFKA-1100
> URL: https://issues.apache.org/jira/browse/KAFKA-1100
> Project: Kafka
> Issue Type: Bug
> Reporter: Jason Rosenberg
>
> I've noticed that there are several metrics that seem useful for monitoring
> overtime, but which contain generational timestamps in the metric name.
> We are using yammer metrics libraries to send metrics data in a background
> thread every 10 seconds (to kafka actually), and then they eventually end up
> in a metrics database (graphite, opentsdb). The metrics then get graphed via
> UI, and we can see metrics going way back, etc.
> Unfortunately, many of the metrics coming from kafka seem to have metric
> names that change any time the server or consumer is restarted, which makes
> it hard to easily create graphs over long periods of time (spanning app
> restarts).
> For example:
> names like:
> kafka.consumer.FetchRequestAndResponseMetrics....square-1371718712833-e9bb4d10-0-508818741-AllBrokersFetchRequestRateAndTimeMs
> or:
> kafka.consumer.ZookeeperConsumerConnector...topicName.....square-1373476779391-78aa2e83-0-FetchQueueSize
> In our staging environment, we have our servers on regular auto-deploy cycles
> (they restart every few hours). So just not longitudinally usable to have
> metric names constantly changing like this.
> Is there something that can easily be done? Is it really necessary to have
> so much cryptic info in the metric name?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
