You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ambari.apache.org by "Aravindan Vijayan (JIRA)" <ji...@apache.org> on 2016/03/02 19:06:18 UTC

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

Aravindan Vijayan created AMBARI-15267:
------------------------------------------

             Summary: 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: Bug
          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)