[
https://issues.apache.org/jira/browse/AMBARI-15267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15176613#comment-15176613
]
Hadoop QA commented on AMBARI-15267:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12790979/AMBARI-15267.patch
against trunk revision .
{color:red}-1 patch{color}. The patch command could not apply the patch.
Console output:
https://builds.apache.org/job/Ambari-trunk-test-patch/5685//console
This message is automatically generated.
> Metrics aggregate times should be tied to aggregation period instead of AMS
> start time
> --------------------------------------------------------------------------------------
>
> Key: AMBARI-15267
> URL: https://issues.apache.org/jira/browse/AMBARI-15267
> Project: Ambari
> Issue Type: Task
> Components: ambari-metrics
> Affects Versions: 2.2.1
> Reporter: Aravindan Vijayan
> Assignee: Aravindan Vijayan
> Fix For: 2.2.2
>
> Attachments: AMBARI-15267.patch
>
>
> The timestamp of aggregated metrics is tied to service start time. For
> example if the AMS service was started at 10:21, all hourly aggregated metric
> will have timestamps like 10:21, 11:21, 12:21 and so on.
> If AMS was restarted at 1:47, the subsequent hourly aggregates will have
> timestamps like 1:47, 2:47, 3:47 and so on.
> This creates inconsistency and difficulty in using the metrics. All aggregate
> timestamps should have definitive boundaries. For example, irrespective of
> when the AMS was started, the hourly aggregate should always be timestamped
> to top of hour (eg. all aggregated metrics having timestamp >= 10 AM and <
> 11:00 AM should be timestamped to 11:00 AM ), and similarly 5 minute
> aggregates should be timestamped to 0th, 5th, 10th, 15th..... minute
> This will enable SmartSense to use this data reliably for trend analysis
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
