jira.rhq-project.org has been archived and is now in read-only mode.

All issues have been moved to bugzilla.redhat.com. All new issues or updates to existing issues should be made through bugzilla.
Specific old RHQ issues can be found using a query of this form: https://bugzilla.redhat.com/show_bug.cgi?id=RHQ-1999.
New bugs can be raised here. Accounts at bugzilla.redhat.com have been created for existing RHQ users.
Open bugs raised in the last week can be found here.
Issue Details (XML | Word | Printable)

Key: RHQ-43
Type: Bug Bug
Status: Accepted Accepted
Priority: Critical Critical
Assignee: Joseph Marques
Reporter: Heiko W. Rupp
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
RHQ Project

Metric avg wrong for groups

Created: 06/Mar/08 01:52 PM   Updated: 03/Feb/09 01:20 PM
Return to search
Issue 2 of 32 issue(s)
Component/s: FX - Measurement
Affects Version/s: 0.1
Fix Version/s: None

Time Tracking:
Not Specified

Date of First Response: 11/Mar/08 09:32 AM


 Description  « Hide
20:31:06 < ghinkle> there is another problem in metrics... the aggregation of group data
20:32:47 < ghinkle> if i have metric A scheduled for 5 minutes on one resource and 10 minutes for another and then look at them in a group where the buckets are say 10 minutes surrounding all data points, the average displayed will be 6.667 instead of 7.5



 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Heiko W. Rupp added a comment - 07/Mar/08 11:24 AM
The avg and sum values for groups are wrong.
Especially it makes no sense that if one value is collected 10 times in a timespan and the other only 1 time, that the first one gets 90% of the avg and the other 10.


Charles Crouch added a comment - 11/Mar/08 09:32 AM
Joe, could you investigate whats required to address this issue

Charles Crouch added a comment - 02/Apr/08 10:05 AM
(10:00:22 AM) ghinkle: ccrouch, i recommend we push rhq-43 out of the next release

We had similar problems in JON 1.4

John Mazzitelli added a comment - 02/Apr/08 10:08 AM
I think the "workaround" would be to not have different schedules for the same metric across resources in the group. I'm sure there are reasons for doing it otherwise, but it seems to me the more common use case would be to collect the same metric with the same collection schedule across resources.

Joseph Marques added a comment - 18/Dec/08 12:08 PM
mazz, in general that sounds like a good strategy, but it's nearly impossible to prevent that in practice. the issue lies in the fact that with a ManyToMany relationship between Resources and ResourceGroups, a resource (and, thus, it's metrics) may actually be in many, many different groups.

pragmatically speaking, your suggested workaround would then scale up to requiring that all metrics of a particular type must be moved in tandem - i.e., disallow individual schedules and only allow updates at the metric template-level...because if we didn't do it that way the logic would simply be too complex to get correct across all current group permutations in the system.

i think this is fixable, just not fun / simple.

John Mazzitelli added a comment - 18/Dec/08 12:12 PM
maybe we check and if we see two or more different coll interval values, we just put a yellow bar at the top of the graphs and say, "these values may be inaccurate due to the differing intervals across resources"