[
https://issues.apache.org/jira/browse/HADOOP-8706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13436363#comment-13436363
]
Andy Isaacson commented on HADOOP-8706:
---------------------------------------
It's very easy using an external tool to derive an ops/sec rate by sampling the
monotonic metric at your chosen frequency and subtracting. What is the benefit
of hard-coding a single period (one second) within the metrics system rather
than allowing the external sampling application to choose a period that is
appropriate for its application?
I don't see a benefit to this approach that justifies the added complexity.
> Provide rate metrics based on counter value
> -------------------------------------------
>
> Key: HADOOP-8706
> URL: https://issues.apache.org/jira/browse/HADOOP-8706
> Project: Hadoop Common
> Issue Type: Improvement
> Components: metrics
> Reporter: Ming Ma
> Attachments: HADOOP-8706.patch
>
>
> In production clusters, it is more useful to have ops / sec instead of
> increasing counter value. Take NameNodeMetrics.getBlockLocations as an
> example, its current type is MutableCounterLong and thus the value is
> increasing all the time. Quite often "num of getBlockLocations" per second is
> more interesting for analysis. Further I found most of the MutableCounterLong
> in NamenodeMetrics and DataNodeMetrics are more useful if they are expressed
> in terms of ops / sec.
> I looked at all the metrics objects provided in metrics 2.0, couldn't find
> such type.
> FYI, hbase has its own MetricsRate object based on metrics 1.0 for this
> purpose.
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
