On Wed, 19 Jun 2013, Risto Vaarandi wrote:
On 06/19/2013 04:34 PM, Rainer Gerhards wrote:
On Wed, Jun 19, 2013 at 2:48 PM, Radu
Gheorghe<[email protected]>wrote:
Hi Risto,
Yes, I've used omprog and it's a good temporary solution :) There are two
things I've bumped into:
- performance. If you can develop (or pay Adiscon to develop) a rsyslog
output plugin that can do what your external program does, it will
probably
be way faster. Because it can make use of rsyslog's features, like having
multiple threads or processing logs in batches
I guess Risto will run some input to SEC - am I right here?
...in fact, I was thinking about creating a SEC FAQ entry which would discuss
different options for connection SEC to rsyslog. Typically, the users have
let it to monitor rsyslog's output files, since as Radu mentioned, there is
no message loss problem with regular files. Of course, with pipes (be it
named or memory based) there is always the "small buffer issue", but in more
recent linux kernels the buffers have grown in size. For this reason, I was
thinking of discussing shortly the cons and pros of each approach. And after
reading the omprog docs, I was just wondering if there are some other and
fancier ways for offering stdin-from-pipe interface for external programs :)
Another question -- in the omprog source code I noticed a comment that
writing into pipe is not entirely block-free? Does it mean that if external
program is not reading fast enough, the rsyslog thread which writes into pipe
could block for a brief moment?
I believe this is true. When the program does not read fast enough, and the pipe
buffer fills, the rsyslog output to the pipe will 'fail'.
by default, this will cause rsyslog to stop outputting any messages,, however
there are a couple of options.
1. you can configure rsyslog to give up instead of continuing to try to write to
this output (logs will go everywhere else but this output)
2. you can configure rsyslog to hae an action queue for this output (which can
include spillover to disk) and processing for this output will be decoupled from
all other log processing.
I think what the comment is talking about is that the failure is not always
instanious, it may time a little bit of time for a blocking write to wait long
enough for a timeout to happen. This isn't really much different from other
outputs like TCP network writes, it can take time for rsyslog to know that the
attempt to connect to a remote system has failed.
David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of
sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE
THAT.
