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
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@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
rhq-devel@lists.fedorahosted.org