Red Hat Bugzilla – Bug 536604
be able to disable baseline calculations per metric
Last modified: 2014-11-17 11:27:54 EST
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.
setting to fix version 1.2 so we remember to discuss this in the next dev cycle.
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.
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".
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-937
Mass move to component = Monitoring
Mazz, still interested in this?
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.
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.