Return-Path: X-Original-To: apmail-hadoop-common-issues-archive@minotaur.apache.org Delivered-To: apmail-hadoop-common-issues-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id DBB5ED20B for ; Thu, 16 Aug 2012 22:18:39 +0000 (UTC) Received: (qmail 55380 invoked by uid 500); 16 Aug 2012 22:18:39 -0000 Delivered-To: apmail-hadoop-common-issues-archive@hadoop.apache.org Received: (qmail 55282 invoked by uid 500); 16 Aug 2012 22:18:39 -0000 Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: common-issues@hadoop.apache.org Delivered-To: mailing list common-issues@hadoop.apache.org Received: (qmail 55075 invoked by uid 99); 16 Aug 2012 22:18:38 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 16 Aug 2012 22:18:38 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 4473B2C5BEB for ; Thu, 16 Aug 2012 22:18:38 +0000 (UTC) Date: Fri, 17 Aug 2012 09:18:38 +1100 (NCT) From: "Andy Isaacson (JIRA)" To: common-issues@hadoop.apache.org Message-ID: <2092162724.21312.1345155518281.JavaMail.jiratomcat@arcas> In-Reply-To: <1232155075.17106.1345078118109.JavaMail.jiratomcat@arcas> Subject: [jira] [Commented] (HADOOP-8706) Provide rate metrics based on counter value MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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