Thomas Wollner wrote:
> Hello List,
>
Thomas,
if you would like to use an external file in a fast manner, here is a
solution (note that I just did a couple of tests with it, so there might
still be some typos):
type=Calendar
time=* * * * *
desc=Reload the lookup file
context= -> ( sub { if (!defined($mtime)) { $mtime = 0; } \
return ($mtime != (stat("/home/risto/lookup"))[9]);
} )
action=eval %o ( if (open(LOOKUP, "/home/risto/lookup")) { \
$mtime = (stat("/home/risto/lookup"))[9]; \
%keydevice = (); \
while (<LOOKUP>) { if (/^([\d.]+)\|(\S+)\|keydevice/) \
{ $keydevice{$2} = 1; } } } )
type=Single
ptype=RegExp
pattern=(\S+) interface (\S+) down
context=$1 -> (sub { return exists $keydevice{$_[0]}; })
desc=(MINOR) $1 INTERFACE $2 DOWN and not up in one minute
action=shellcmd /opt/sec/tools/send_nsca.sh $1 WARNING '%s'
The first rule checks the modification time of the /home/risto/lookup
file and loads it if the file has been modified after the last load
(checks are made once in every minute). The names of all key devices are
stored in a %keydevice hash which allows for quick lookups. The second
rule is a simple example how to search host names from this hash with a
->() construct (this is a fast invocation of a precompiled Perl
subroutine that verifies if the host name is in the hash).
There might be other ways for tackling the problem -- e.g., you could
invoke the 'spawn' action from the Calendar rule that feeds the names of
all key devices back to SEC; then you could match the names with a
separate SEC rule and set up a permanent context for each key device.
(the presence of these contexts could later be checked from other rules).
hth,
risto
> first of all I would like to thank the developers of SEC for this
> great piece of software.
> I`m new to SEC and I try to integrate cisco syslog events into nagios
> using cisco-syslog.sec found on
> http://kodu.neti.ee/~risto/sec/rulesets/cisco-syslog.sec. I`m using
> send_nsca to send messages to nagios.
>
> So far everything worked as it should but one (or more) thing left:
>
> I receive a lot of syslogs from access-switches (link and line proto
> up/down) but I`m only interested on these messages coming from
> key-devices. For that I have created a facts file which holds the
> information which device is a "key" device.
>
> Now I want to perform a lookup from within the rule to decide the
> device is a key device or not. how can i do that with sec?
>
> The format of my fact file is for example:
> 10.10.10.1|bigrouter1|keydevice
> 10.10.1.1|smallswitch1|access
>
> Currently I`m using the following rules for link-up-down correlation:
> # This rule deals with link down events
> #
> type=PairWithWindow
> ptype=RegExp
> pattern=\d+:\d+:\d+.*?(\S+)\s+\d+:.*?%LINK-3-UPDOWN: Interface (\S+),
> changed state to down
> desc=(MINOR) $1 INTERFACE $2 DOWN and not up in one minute
> action=shellcmd /opt/sec/tools/send_nsca.sh $1 WARNING '%s'
> ptype2=RegExp
> pattern2=($1)\s+\d+:.*?%LINK-3-UPDOWN: Interface ($2), changed state to up
> desc2=(WARNING) %1 INTERFACE %2 BOUNCE
> action2=event %s
> window=60
>
> # when the first bounce event is seen, create a reporting trigger
> #
> type=Single
> continue=TakeNext
> ptype=regexp
> pattern=(\S+) INTERFACE (\S+) BOUNCE
> context=!INTERFACE_BOUNCE_WAIT_$1
> desc=interface bounce summary event for router $1
> action=create INTERFACE_BOUNCE_WAIT_$1 10;shellcmd
> /opt/sec/tools/send_nsca.sh $1 INFO '%s'; delete INTERFACE_BOUNCE_$1
>
> # accumulate all interface bounce events into a context
> #
> type=Single
> ptype=regexp
> pattern=(\S+) INTERFACE (\S+) BOUNCE
> desc=interface bounce for router $1 interface $2 detected
> action=add INTERFACE_BOUNCE_$1 %t: %s
>
>
> any ideas, any hints?
>
> thank you in advance,
>
> best regards,
>
> tom
>
>
>
>
>
>
>
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Simple-evcorr-users mailing list
> Simple-evcorr-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
