Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 536604 - (RHQ-937) be able to disable baseline calculations per metric
be able to disable baseline calculations per metric
Status: NEW
Product: RHQ Project
Classification: Other
Component: Monitoring (Show other bugs)
All All
low Severity medium (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2008-10-03 12:56 EDT by John Mazzitelli
Modified: 2014-11-17 11:27 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description John Mazzitelli 2008-10-03 12:56:00 EDT
Right now, all "dynamic" measurement definitions (<metric>) will have baselines calculated for it.

In large systems, this could result is a huge amount of baselines, not all of which will be interesting to the customer.

We should enhance the <metric> metadata definition to allow for an attribute "enableBaseline" whose type is "boolean" with a default of "false".

We then need to go through all descriptors and add "enableBaseline="true"" to those metrics that we think would be useful to have baselines.

This would allow us to reduce the number of baselines calculated in the system.  this helps in several ways (the speed in which the calculations take, the speed in which the alert cache can load, the memory footprint of the cache, etc.).

We should have a UI page (measurement template page?) that lets the user flip this from true to false as the user feels is appropriate.

Perhaps even consider allowing each measurement schedule per resource have its own value - but just having it on a measurement template should be good enough to start.
Comment 1 John Mazzitelli 2008-10-03 12:56:47 EDT
setting to fix version 1.2 so we remember to discuss this in the next dev cycle.
Comment 2 John Mazzitelli 2009-01-27 10:40:32 EST
setting this to minor, the reason for this originally was because our old OOB subsystem has poor performance and reducing baselines was a way to help fix that.  Our old OOB subsystem has been been removed so this isn't as critical as before.
Comment 3 John Mazzitelli 2009-02-26 22:05:24 EST
After looking at the current OOB data for the new subsystem, I've come to the conclusion that I would like to revisit this JIRA. Actually, I would like to add to this idea a bit.

I used to think we should be able to turn off baseline calculations for individual schedules or entire schedule definitions. This way, I can say, "don't bother calculating baselines (and therefore don't bother telling me about OOBs) for the metric "JVM Total Memory" (or whatever, pick a metric). I still think that might be useful. This is what this JIRA's original purpose was.

But after looking at the new Problem Resources page, we might want to also be able to ignore certain OOBs that are currently in the system. Suppose a metric is showing at the top of the problem resources page but I've determined its not a problem and it can safely be ignored. Well, that metric is still going to show up at the top of this page every time I go there (until the baselines are recalculated again). I would like to tell the UI, "I've analyzed this metric and I deem the OOBs to not be a problem - please ignore it and only report those OOBs that I have not ignored". This way, I can refresh the UI and only see the OOBs that I have not yet looked at. Otherwise, everytime I come here, I'm going to look at the top of the table (which is where everyone is going to look) and I will have to remember to say, "I already looked at this OOB and its not important, let me move to OOBs lower in the list and see if they are more important".
Comment 4 Red Hat Bugzilla 2009-11-10 16:19:58 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-937
Comment 5 wes hayutin 2010-02-16 16:10:02 EST
Mass move to component = Monitoring
Comment 7 Jay Shaughnessy 2014-05-15 17:39:10 EDT
Mazz, still interested in this?
Comment 8 John Mazzitelli 2014-05-16 11:27:41 EDT
This might be an interesting feature if John Sanda thinks we could use it. Now that the storage node is handling baseline calcs, maybe it is efficient enough that we can do all of them and not worry about filtering out metrics that we don't want to have baselines calculated for.

John S. - thoughts? This is to be considered an enhancement request.
Comment 9 John Sanda 2014-11-17 11:27:54 EST
We are still storing baselines in the RDBMS. The implementation now is actually less efficient than it was previously. There are plenty of improvements that could be made relatively easily. It just has not been a priority. Unless it is a bug or regression, I would prefer to incorporate new features into RHQ Metrics.

Note You need to log in before you can comment on or make changes to this bug.