[c-nsp] Any good filters for syslog output

[Jason LeBlanc]

The other nice thing about SEC is that it can handle a busy log server 
without nuking the cpu.  You can get pretty crazy with it too in terms 
of complexity.

Christian Zeng wrote:
> Hi,
>
> * Eric Cables <ecables at gmail.com> wrote:
>   
>> I've been using swatch for a couple of years now, and have been pretty happy
>> with it (I used CiscoWorks' built-in syslog analyzer before, yuck!).  I have
>> had ambitions to test out SEC (Simple Event Correlator), which appears to
>> still be developed (not sure if I've seen a swatch update since I started
>> using it), but I just haven't had the time to do so.
>>
>> For those who have used both swatch & SEC, do you have any arguments for
>> switching to SEC?
>>     
>
> We are using SEC since 4 years in production, it has been proven as a
> stable and a very powerful event correlation tool.
>
> Back then, I looked also into swatch. SEC made it because it allowed me
> to work with context-based events. This means when one event occurs, you
> can create a context, allowing other event rules to become active.
>
> There are tons of use cases I can think of. Event suppression, for
> example in case of a STP topology trap was logged. Watchdog solutions,
> like noticing an adjacency went down and starting a timer to check
> whether it came back or not. Or even complex aggregation rules, like
> collecting information about traffic behavior (ACL hits/IDS logs),
> correlating up to a point where you can make sense out of the noise
> (what MARS does; simpler, but free).
>
> I am certain that some of this can be done with swatch, but more complex
> scenarios require to have some persistent relation between events, and I
> think this cannot be done with swatch.
>
> Kind regards,
>
>
> Christian
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>