2016-12-22 16:41 GMT+02:00 Martin Etcheverry <mar...@etcheverri.com>:
>
> Hi , everyone! i have a little problem with rsyslog sending events to sec.
>
> part of my config in the *rsyslog.conf* is ;
>
> $ModLoad omprog
>
> $ActionOMProgBinary /usr/local/bin/sec.sh
> *.* :omprog:
>
>
> my *sec.sh* is
>
> exec /usr/local/bin/sec --conf=/etc/sec/sec.conf --notail --input=-
>
For debugging, I would advise to add the --log option to this command line.
If you are suspecting that sec is not receiving any input events at all
from syslog, you could set up the following rule which echos all received
line to sec debug log:
type=single
ptype=regexp
pattern=.
desc=echo everything
action=logonly Received from rsyslog: $0
If you see events that rsyslog has previously received in sec debug log,
the connection between rsyslog and sec is functioning.
>
> my */etc/sec/sec.conf*:
>
> type=PairWithWindow
> ptype=RegExp
> pattern=(?:[^\ ]*\ ){4}([^ ]*): \1\Wnew\W\w+\W+\w+
> desc=No cancellation event for $1 after 10 minutes
> action= pipe '$s' mail -s 'alarmed event mailsyslog' mym...@gmail.com
> ptype2=RegExp
> pattern2=(?:[^\ ]*\ ){4}$1\W\$1\W+cancelled\W\w+\W+\w+\W
> desc2=pipe '%s details:$2' mail -s 'canceled event mailsyslog'
> mym...@gmail.com
> action2= pipe '%s' mail -s 'evento cancelado mailsyslog'
> metcheve...@hg.com.uy
> window=600
>
> to test the sec i do :
>
> echo "Dec 21 16:55:48 10.250.200.5 SOMEHOST02: SOMEHOST02 new critical,
> VMwareAdapter,"|/usr/bin/perl -w /usr/local/bin/sec --conf=/etc/sec/sec.conf
>
> This is a valid way to check if the sec will work with my event?
>
not quite -- you also need to provide sec with the --input=- option, in
order to read this event from standard input.
> anyways , i dont know how to check if the event is sended correctly to sec
> or if is a problem.
>
apart from options described above, the simplest way for debugging sec is
the following -- send the sec process SIGUSR1 signal and inspect its dump
file (by default located at /tmp/sec.dump). The dump file contains
information about the number of processed lines, the state of input files
(e.g., are they open or closed), and the content of input buffer (last
lines which sec has processed). Inspecting this information will help you
quickly determine if sec has received any input from rsyslog, and if yes,
what the last line(s) have been. More importantly, you can see all
information about event correlation operations that sec is currently
running, all contexts it has created, and many other things about the
internal state of sec.
kind regards,
risto
>
> anyone has faced something like this?
>
> Regards
> Martin
>
>
>
> ------------------------------------------------------------
> ------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/intel
> _______________________________________________
> Simple-evcorr-users mailing list
> Simple-evcorr-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
>
>
------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
