Mailing-List: contact issues-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Mon, 30 May 2016 09:30:13 +0000 (UTC)
From: "Jungtaek Lim (JIRA)" <jira@apache.org>
To: issues@ambari.apache.org
Message-ID: <JIRA.12973878.1464571508000.330619.1464600613219@Atlassian.JIRA>
In-Reply-To: <JIRA.12973878.1464571508000@Atlassian.JIRA>
References: <JIRA.12973878.1464571508000@Atlassian.JIRA> <JIRA.12973878.1464571508806@arcas>
Subject: [jira] [Commented] (AMBARI-16946) Storm Metrics Sink has high
 chance to discard some datapoints
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Mon, 30 May 2016 09:30:15 -0000


    [ https://issues.apache.org/jira/browse/AMBARI-16946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15306440#comment-15306440 ] 

Jungtaek Lim commented on AMBARI-16946:
---------------------------------------

https://builds.apache.org/job/Ambari-trunk-test-patch/7050/artifact/patch-work/trunkCompile.txt

Seems like ambari-web is the reason to failure of build #7050. Just retriggered.

> Storm Metrics Sink has high chance to discard some datapoints
> -------------------------------------------------------------
>
>                 Key: AMBARI-16946
>                 URL: https://issues.apache.org/jira/browse/AMBARI-16946
>             Project: Ambari
>          Issue Type: Bug
>          Components: ambari-metrics
>    Affects Versions: 2.4.0
>            Reporter: Jungtaek Lim
>         Attachments: AMBARI-16946-trunk-v2.patch
>
>
> There's a mismatch between TimelineMetricsCache and Storm metrics unit, while TimelineMetricsCache considers "metric name + timestamp" to be unique but Storm is not.
> For example, assume that bolt B has task T1, T2 and B has registered metrics M1. It's possible for metrics sink to receive (T1, M1) and (T2, M1) with same timestamp TS1 (in TaskInfo, not current time), and received later will be discarded from TimelineMetricsCache.
> If we want to have unique metric point of Storm, we should use "topology name + component name + task id + metric name" to metric name so that "metric name + timestamp" will be unique.
> There're other issues I would like to address, too.
> - Currently, hostname is written to hostname of the machine which runs metrics sink. Since TaskInfo has hostname of the machine which runs task, we're better to use this.
> - Unit of timestamp of TaskInfo is second, while Storm Metrics Sink uses this as millisecond, resulting in timestamp flaw, and malfunction of cache eviction. It should be multiplied by 1000.
> - 'component name' is not unique across the cluster, so it's not fit for app id. 'topology name' is unique so proper value of app id is topology name. 


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)