2011/10/15 Ralf Schmitt <ral...@arcor.de>:
> Hi Risto,
>
> thank you for the encouraging pat on the back ;)
>
> I'm taking a closer look at the documentation and the tutorial from
> Jim Brown (nice document) at the moment.
>
> But I'm still not able to solve my problem. Here is a rule set that:
>
> - saves "IP not reachable" messages in a context
> - deletes the IP from the context if the server is reachable again
> - reports all context entries if you send a "ReportMe" message to SEC
>
>
>
>
>
> ###################################################################
> # One of the sources is not reachable
> #
> # Sample log message:
> #
> # Source 193.124.4.177 offline
> #
> # Add the IP to the context SOURCE_STATUS
> #
> ###############
>
> type=Single
> ptype=RegExp
> pattern=Source (.*) offline
> desc=Add the IP to the context SOURCE_STATUS
> action=add SOURCE_STATUS $1
>
>
> ##################################################################
> #
> # One of the sources is reachable again
> #
> # Sample log message:
> #
> # Source 86.57.151.18 online
> #
> # Remove the IP from the context SOURCE_STATUS
> #
> ###############
>
> type=Single
> ptype=RegExp
> pattern=Source (.*) online
> desc=Remove the IP from the context SOURCE_STATUS
> action=eval %funcptr ( sub { my(@buf) = split(/\n/, $_[0]); \
> my(@ret) = grep(!/$1/, @buf); return @ret; } ); \
> copy SOURCE_STATUS %in; call %out %funcptr %in; \
> fill SOURCE_STATUS %out
>
>
> ##################################################################
> #
> # Pattern 'ReportMe' executes the report action
> #
> ###############
>
> type=Single
> ptype=RegExp
> pattern=ReportMe
> context=SOURCE_STATUS
> desc=$0
> action=report SOURCE_STATUS /bin/cat
>
>
> ##################################################################
> #
> # End
> #
> ###############
>
>
>
>
>
>
> Now I feed SEC with these messages:
>
>
> Source AAA offline
> Source BBB offline
> Source CCC offline
>
> Source AAA online
> Source BBB online
> Source CCC online
>
>
>
>
> 3 servers are offline and than online again. The result should be an empty
> context ... But "CCC" is still there. Even sending another:
>
> Source CCC online
>
> does not clear the context ... Strange. Don't know what I'm doing wrong.
>
>
> Thanks,
> -Ralf-
>
Ralf, I made a quick check of the ruleset and you are not doing
anything wrong -- the example I provided you needs a slight
modification. The problem is that return values from Perl miniprograms
are received as lists which allows for returning multiple values.
However, when the return list has a size 0, the value of the output
variable is not modified, and thus the 'fill' action does not empty
the context event store (SEC will also log a message that it didn't
receive any values for output variable, and thus its value will not be
altered).
The example from the man page comes from one of my past rule sets, but
there each comment line was describing the following data line (in
other words, the context always contained at least some non-comments,
and thus the example was always working). Nevertheless, I should
either change this example or add a sentence about the above
assumption to the documentation.
However, if you are using the context for creating textual reports, it
is possible to have a simple workaround by writing an empty string
into the @ret list, in order to make its size equal to 1 (for example,
with "if (!scalar(@ret)) { push @ret, ""; }" before return @ret).
Now the 'fill' action would overwrite the context event store with an
empty string which would become its first element. Of source, this
solution is not 100% perfect, since at some point the context would
have an empty first line in the event buffer. By far better solution
would be the use of if-statement to check the return value from
'eval', and delete the context when certain value is seen.
Unfortunately, in the current SEC version there is no support for
conditional and loop statements in action lists, but I would like to
add these features soon, since they would allow for handling many
issues in a better way.
BTW, are you using the context for reporting purposes only, or do you
intend to create checks for its event store, in order to verify which
sources are offline? If so, then using a separate context for each
offline source might be better solution. Also, if the reporting
context tends to be large (i.e., there are many offline sources),
linear search with grep() is much slower than a hash lookup. Since
there is a need for Perl code anyway to delete from context event
store, it might be a better idea to use a Perl hash instead of a
context. This would also nicely handle the case when you get several
offline messages for the same source (no duplicates are created in the
hash). Here is an example which uses the 'lcall' action to modify the
%offline hash (the keys to %offline are source names). While 'eval'
compiles the code before each execution, for 'lcall' it is done only
once at SEC startup which is much more efficient. Note that in the
third rule, %o is initialized to "No offline sources". When the
%offline hash is empty, 'lcall' would not modify %o, and thus a string
about no offline sources would be reported (all reporting is done with
'pipe' action instead of 'report'):
type=Single
ptype=RegExp
pattern=Source (.*) offline
desc=Add the IP to the context SOURCE_STATUS
action=lcall %o $1 -> ( sub { $offline{$_[0]} = 1; } )
type=Single
ptype=RegExp
pattern=Source (.*) online
desc=Remove the IP from the context SOURCE_STATUS
action=lcall %o $1 -> ( sub { delete $offline{$_[0]}; } )
type=Single
ptype=RegExp
pattern=ReportMe
desc=$0
action=assign %o No offline sources; \
lcall %o -> ( sub { return keys %offline; } ); pipe '%o' /bin/cat
I would myself use a Perl hash for bookkeeping, since it is faster,
handles duplicate offline-messages, and is probably simpler to read.
Hope I was able to provide better advice this time,
risto
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
