I am writing to thank you for your letter about a very good looking and=20
interesting product, and say
On Wed, Nov 12, 2003 at 05:15:14PM +0100, Marco Seiri=F6 wrote:
>=20
> Hi list,
>=20
> We have built a kind event pattern detector, or event correlation engin=
e
> as it also could be called. It's free and you can get it under GPL from
> www.rulecore.com
>=20
> I have been getting a number of requests to use ruleCore together with
> Nagios. But this requires some work to make Nagios and ruleCore talk to
> each other. I don't have any experience with Nagios so I wonder if
> somebody would be interested in doing this integration.
>=20
Nagios is an all in one availability monitor that
1 schedules service checks (and their retries)
2 contains hardwired logic to recognise a simple subset of events based=20
on heuristics or 'hard coded rules' such as=20
event of max retries of service check exceeded
=3D>=20
hard (confirmed) state transition and state trans event processing.
In my view, it would be good for Nagios to gain an event filtering/event
correlation/event facility to as you say, 'could add to or improve the
event detection capabilities to Nagios.'
One of the significant differences of the Tivoli product is its ability
to define predicates, event filters and rules in its rule processing
core (based on Prolog I believe).
This is advantageous because
. the event processing framework is non-procedural; the engine
establishes a predicate based on its definition and the events that have
been input. There is simply no need for a whole bunch of cases to deal
with sequencing.
. conclusions can be drawn about business systems based on the event=20
stream. This is a significant facility because it provides the potential=20
of
- a business view instead of or as well as a system view
- the ability to make decisions or conclusions based on best practise=20
rules. This instantly puts ones subject expertise to much greater use:=20
it can be used in the core of the monitor instead of your being asked or=20
having to do it yourself.
Unfortunately, I am not the Nag developer and am therefore speaking for=20
myself only.
However, there exists this (dumb) path to integration of RuleCore and or
Sec event processing and correlation, that allows the two to coexist
unchanged at the expense of having two products and clumbsier
processing.
1 Nagios acts as an event source to RuleCore (and or Sec); Nagios
schedules system and element checks and on _its_ detection of a hard
state, informs RuleCore via the Nagios notification or event handler
mechanism (to push the event of a hard state change somehow into
RuleCore).
2 Nagios defines passive service checks corresponding to the inferences
or conclusions about business systems and or cloned services that will
be processed by RuleCore.
3 RuleCore processes the Nagios events and any other events (from other
eevent sources such as trap handlers) then submits passive service check
results to Nag.
This is advantageous in that both products are unchanged. It is=20
suboptimal in that
- RuleCore cannot comment on element failures (that are related to other=20
events such as congestion) unless that event is passed to RuleCore.
- The IPC is via whatever the host supports and could be slow or=20
suboptimal
- Event correlation can only be done on hard state changes; Nagios event
processing cannot be expedited or altered by the conclusions that
RuleCore may already be able to make through its use of event filters,
correlation and or rules - this is simply another way of writing the
first point.
> What I understand from the requests I have received, ruleCore could add=
or
> improve the event detection capabilities to Nagios. But this I suppose =
you
> would know much more about
>=20
> We can ofcourse help out with ruleCore specific changes or additions if
> just somebody tells us what to do.
>
Unfortunately I am not the person to do this. I am very grateful for=20
your work and thank you for the offer.
Good luck with what looks like a good product.
=20
> /Marco
>=20
Your
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]