Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1112313

Summary: Min metric value for last 5 days is lower than min value for last 6 months
Product: [JBoss] JBoss Operations Network Reporter: Jirka Kremser <jkremser>
Component: Monitoring -- Other, UIAssignee: Jirka Kremser <jkremser>
Status: CLOSED NOTABUG QA Contact: Mike Foley <mfoley>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: JON 3.2CC: ahovsepy, jkremser, jsanda, jshaughn, snegrea
Target Milestone: ER05   
Target Release: JON 3.3.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-09 16:04:58 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
screen1
none
screen2 none

Description Jirka Kremser 2014-06-23 14:51:48 UTC
Created attachment 911492 [details]
screen1

Description of problem:
In the metric table the min/max values are not calculated or displayed correctly.
See the attached screenshots for more details.

This also applies for maximum values.
I am not sure if it is a UI bug or logical server-side issue.


Version-Release number of selected component (if applicable):
JON 3.2.0 GA

How reproducible:
10%

Steps to Reproduce:
1. go to /coregui/#Resource/${resId}/Monitoring/Metrics
2. change the time scale couple of times

Actual results:
Min (max) value for shorter time period is lower (higher) than min (max) value for a period that actually contains the shorter period.


Expected results:
local extreme can't be higher/lower than global extreme

Comment 1 Jirka Kremser 2014-06-23 14:52:19 UTC
Created attachment 911493 [details]
screen2

Comment 3 Jay Shaughnessy 2014-07-03 20:01:41 UTC
I think this can be expected.  As I understand it we use the finest grain data we can that covers the requested time period.  If the time range covers multiple granularities the less granular data is used.

But jsanda should probably comment to make sure I have things straight...

Comment 4 John Sanda 2014-09-02 14:47:20 UTC
Jay is correct. Any date range where the lower bound is less seven days will result in a query against the raw data. The first screenshot includes data from the past 5 days; so, it will include the most recently collected data. Date ranges where the lower bound is less than 31 days will result in a query again the six hour metrics. It is entirely possible that the data for the past 5 days in screenshot 1 had not been aggregated into the six_hour_metrics table which could explain the lower min value.

We would need to look at the actual values and timestamps to determine whether or not the min/max values from the 5 days query should be included in the 1 month query. For example, if the min/max values reported in the 5 day query were from two days again, then they should also be included in the 1 month query.

Jirka, can you reproduce this?

Comment 5 John Sanda 2014-09-05 15:00:07 UTC
To be clear, I do not think it is clear yet whether or not there is an issue. I assume that the next step for this is to try to reproduce so we can make a determination as to whether or not there is actually a problem.

Comment 7 Jirka Kremser 2014-09-17 12:16:10 UTC
Confirming that sentence:

"It is entirely possible that the data for the past 5 days in screenshot 1 had not been aggregated into the six_hour_metrics table which could explain the lower min value."

is correct. Not sure what to do now, is this expected behavior? I am good with closing this as NOTABUG

Comment 8 Simeon Pinder 2014-09-29 08:12:39 UTC
Moving into ER05 as didn't make the ER04 cut.