Hi Glenn,
basically, the approach you have sketched is feasible (although the syntax
would be somewhat different).
It's obvious that if you insist of putting most of the logic into
application classes, Drools won't be able to do much for you. The trick is
to keep the business logic in the rules :-)
Assuming classes such as
Parameter { ParType type; Host host; int value; ... }
Threshold1 { ParType type; Host: int alarmValue; }
Threshold2 { ParType type; Host: int warningValue; int alarmValue; }
Bounds { ParType type; Host: int lowValue; int highValue; }
I'd try to deal with various evaluation strategies by grouping the rules
according to evaluation models which are "grouping" objects that can be
assigned, as need be, to host-parameter combinations. As an example:
rule "CPU load - Model WARN_ALARM"
when
$p : Parameter( type == $type, $value : value, $host : host )
$m : Model( id == ModelType.WARN_ALARM, $type : type ==
ParamType.CPU_LOAD, host == $h )
$t : Threshold2( type == $type, host == $host, warningValue < $value )
then
warn that $h exceeds warning level for parameter type
end
For an alternative, a host should have a temperature between bounds:
rule "Temperature - Model BOUNDS"
when
$p : Parameter( type == $type, $value : value, $host : host )
$m : Model( id == ModelType.BOUNDS, $type : type ==
ParamType.TEMPERATURE, host == $host )
$t : Bounds( type == $type, host == $host, lowValue >$value || highValue
< $value )
then
warn that $host has left the permitted temp. range
end
You can see that another host's temperature could easily be checked against
a single or double threshold.
The advantage lies in the concentration of all evaluation logic in rules.
Changes won't affect the application around the rules engine, which would
have to deal with updates of parameter readings and operator command to
change the values of a host/parameter combination or even a host's
evaluation model for a certain parameter.
-W
2010/2/9 Glenn Macgregor <gmacgregor(a)pocketkings.ie>
Hi All,
I am in the process of evaluating Drools to use in a networks & systems
management project. Some of the initial use cases are listed below.
*Use Cases:*
1. Simple single parameter thresholds with configurable warning and
error levels.
2. Simple multi parameter thresholds from one host with configurable
warning and error levels.
3. Complex multi parameter thresholds from multiple hosts with
configurable warning and error levels.
4. Complex time based multi parameter thresholds from multiple hosts
with configurable warning and error levels.
After reading about the Drools rules engine (Expert) and the CEP (Fusion)
it seems at a glance that it would be very useful in this application. As I
digging into use case 1 I am not sure Drools is actually going to fit the
bill as first thought.
Imagine a small network with 300 hosts each of which is being polled for
CPU data which can be massaged to produce an instantaneous CPU Utilization
which I want to check against some threshold, which can be different for
each host. I don’t see creating 300 rules to handle this simple case as an
ideal solution as I need to give control of the CPU Utilization threshold to
the teams who own the hosts. Thinking about how to abstract that I imagine I
could put the thresholds into a database and rebuild/reload the rules as
necessary but as the thresholds could change often this seems like
unnecessary overhead. I have moved on from that solution to the idea that a
threshold is an attribute of the parameter as name and value are attributes.
This allows me to attach the threshold value to the parameter update and
potentially have a Drools rule something like (not a working rule):
*rule “test rule”*
* when*
* $param : Parameter(name == someName) #
comes from some map of params or something, not sure yet.*
* $param(value >= warningThreshold)*
* then*
* # Fire warning alert*
* end*
* *
Where value and warningThreshold are members of the Parameter object.
Having thought about this and discussed with some colleagues we can not
impose a ‘>=’ in the rule as some teams might what a different set of
comparators. Moving on to these new requirements I thought we could have all
the info encapsulated into the Parameter object as a set of functions:
· isInWarning
· isInError
*rule “test rule”*
* when*
* $param : Parameter(name == someName) #
comes from some map of params or something, not sure yet.*
* $param.isInWarning()*
* then*
* # Fire warning event*
* End*
* *
Questions:
· Is the above possible in Drools?
· What does Drools get me as my software is already doing all the
calculation and comparison work?
· Is there a better way to handle this using Drools?
Thanks for the reply’s
Glenn
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users