[jira] [Updated] (AMBARI-15267) Metrics aggregate times should be tied to aggregation period instead of AMS start time

["Aravindan Vijayan (JIRA)" <ji...@apache.org>]

     [ 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)