Costel,
great that you took the time to go through this.
This document is meanwhile pretty old (which does not automatically render it invalid).
The current thinking goes along the usage of JBoss Drools Fusion
(
http://www.jboss.org/drools/drools-fusion.html),
which has time based ruling incorporated. I think we will in this approach not use the
color coding, but will allow the
user to create as many rules as he wants.
This way the "per user" rules that you describe in 1) should be resolved.
For 2) you should be able to code some sort of sliding windows that count the number of
occurrences and then
if they match "forward that result" to the next rule that correlates the
sources.
The approach would still provide a UI as we have today, but would also allow to rules
either in .drl and/or a
special RHQ dsl.
A student has implemented a first "PoC" that looks promising performance wise,
but we don't have real concrete
plans for this.
It is definitively good to get that input - and for every one who has ideas (or want to
participate) we are open for input.
Heiko
Am 10.07.2013 um 20:22 schrieb Costel Cosman:
Hi,
I was reading the document with the proposal for CorrelationUnits
https://docs.jboss.org/author/display/RHQ/Correlation+Units
It seems a very good idea, but I think, from the flexibility point of view, there are
some use cases that are not covered:
UseCase1. A source can be of interest for more different user groups, therefor is needed
of different alert configurations.
=====================================================================================
The current approach has the limitation that allows only one NormalizationRule per
source.
Let's say that we have a JBoss resource and the metric "Memory free" and
the Normalization Rule:
g : > 1000
y: 100..1000
r: < 100
This values are good for the JBoss administrators group that need to be alerted in order
to have some actions like restarting JBoss.
The developers group do not need to restart JBoss, but they might need do at some point
some kind of a debugging and they want to be alerted when the free memory is less then 500
MB. So the normalization rule might be:
g: >= 500
y: -
r: <500
UseCase 2. We have the use following use case of the alert:
===============================================
" I want an alert if some condition1 happens 10 times AND some other condition2
happens 5 times".
The alert dumpening doesn't work for this case because the consecutive count is not
on condition level, but on alert level.
Problem: There is no possibility to check if a Normalization rule has a certain color for
a consecutive number of times
Solution: A normalization rule might maintain in the working memory both a color and the
consecutive number of times this color happens.
Let's name the corresponding NormalizationRoles : NR1 and NR2
The CorrelationRule must be something like :
g:
y:
r: NR1(color) = r and NR1(consecutive count) = 10 and NR2(color) = r and NR2(consecutive
count) = 5
==========================================================================
What do you think about this ?
Regards,
Costel Cosman
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera