[rsyslog] actionqueue in front of tcp forward
rgerhards at hq.adiscon.com
Wed Mar 12 22:20:15 CET 2008
> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com
> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Johnny Tan
> Sent: Wednesday, March 12, 2008 10:06 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] actionqueue in front of tcp forward
> Rainer Gerhards wrote:
> > I have received the file and had a chance to look at it. It's quite
> > confusing. The send fails, but each retry succeeds... It
> looks like you
> > use stunnel. I currently doubt that stunnel accepts each
> send and only
> > reports the error after it can not connect to the remote side. So in
> > fact we continously run into the situation that exactly *that* one
> > message is lost. But I am still puzzled. Could you, for a
> test, run the
> > same without stunnel and tell me if the problem persists or
> goes away?
> Yes, I had the same thought about stunnel being the problem
> and was running some tests.
> It works! I now only lose the one message (known problem).
> But if I go over stunnel, then I lose all messages during
> the rsyslog server downtime.
I have the strong feeling that it is time to do something against this
plain old ack-less syslog tcp protocol... Maybe I add a half-duplex mode
for starters. That's low, but quick to implement and ultra-reliable.
I'll also see that I get more serious with RFC 3195 re-enabling. I've
already done some basic thinking in regard to 3195 and the new syslog
engine and doing it ultra-reliable will require a little bit of work. So
there won't be an immediate cure - but defenitely the right route to
How about half-duplex mode? Would that work for you? It means that each
message must be acked before the next one is sent, so tcp's streaming
features will almost be disabled. I'd expect a drop to at most 50% (more
probable 40%) of the performance compared to what we currently run
(half-duplex would obviously need to be an option...). So it would be a
large performance hit.
> I can do without the stunnel for now.
For encryption, you could also look into the GSSAPI modules. It's
contributed code, and I currently unfortunately have limited insight
into it. But varmojfekoj, the contributor, has done a great job.
> Thanks once again!
I am very intersted in real-life experience. After all, the engine is
still quite new. So I need feedback from the field to make it
ultra-solid - a lab is a lab, is a lab ;) So keep the thoughts flowing.
A side-note: we are rewriting phpLogCon, the web interface to syslog
data. Any chance you happen to have some interest in that? ;)
> rsyslog mailing list
More information about the rsyslog