[
https://issues.apache.org/jira/browse/AMBARI-15267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aravindan Vijayan updated AMBARI-15267:
---------------------------------------
Issue Type: Task (was: Bug)
> 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
>
>
> 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)
