john.j.mackney@accenture.com writes:
> I want to send a limited number of events to TEC.
>
> What do most people do - create a ruleset from scratch or is there a
> general starting point ruleset available.
> Is the TEC_ITS.rs a good place to start?
I can tell you what we did, and then why changed.
We used to run all our events through a correlation ruleset, having
"trap settings" rulset nodes to pick off the events we cared about,
and then to a Forward ruleset node. We would then run this ruleset in
the TEC adapter (configured via server-setup, creates a tecint.conf
file). Any events that hit a forward node would be sent to TEC.
It turns out this wasn't all that scaleable! Every new and
interesting device with traps we wanted to address required another
ruleset branch with its own trap settings node. Soon, the rulesets
took forever to load into the rulset editor (PAINFUL, esp. when
editing over remote X11 connections), and we had nvcorrd stability
problems since nearly all events were going through the nvcorrd
daemon.
So, based on some advice gathered on this forum, we switched to an
approach whereby simple traps of interest directly execute a "Command
for automatic action" (as labeled in the trap configuration dialog box
in the GUI, that's -C in the addtrap command--see addtrap manpage for
details) that run a script in which we call the postemsg command to
send an event to TEC. If you're not familiar with tec, postemsg is a
binary that you get from TEC (available on all supported TEC
platforms) that sends events to TEC and has a bunch of options.
The benefit of this script-based approach is that our ruleset is now
MUCH smaller and less complex plus, nvcorrd has fewer problems because
it's processing a lot fewer events. We now use rulesets exclusively
for situations that actually require correlation (i.e. a notion of one
event's processing depending on a previously received event(s)).
HTH,
--
Todd H.
http://www.toddh.net/
|