[rsyslog] actionqueue in front of tcp forward

[Rainer Gerhards]

> Rainer Gerhards wrote:
> > 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
> > take.
> >
> > 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.
> 
> Just curious: do either of the above solutions (3195 and
> half-duplex) resolve the issue of losing all messages when
> the server goes down and you are going over stunnel?
> 
> It sounds like the half-duplex does, I don't know enough
> about the 3195 to know.
> 
> 
> In answer to your question, I probably don't have as heavy a
> load as some folks out there, so it's easy for me to say,
> yes, half-duplex works for me, at least for the moment.

I had a somewhat sleepless night, which is good news because it usually
results in good ideas ;) This problem really bugged me, but I finally
made up my mind. Instead of wasting time on fixing broken plain tcp
syslog transport mode (e.g. by implementing half-duplex, which isn't
standard anyhow), I'll do "the right thing". I thought rfc 3195 is the
right thing. But it carries a lot of overhead that I really don't need.
And, most importantly, any standard additions takes ages to go through
the IETF (I know what I am talking about, have finally succeeded to get
a better syslog rfc though it in "just" 4 (or 5?) years -- and it is
still waiting to be published...).

So instead of adding on any of these existing protocols, I'll do a new,
lightweight but capable protocol specifically designed to solve the
shortcomings we currently experience. Please welcome RELP, the "reliable
event logging protocol" (name based on the quite successful selp [simple
event logging protocol] effort:
http://www.monitorware.com/en/workinprogress/selp.txt).

Relp will evolve over time. I hope to do something useful relatively
soon, and it will be extended as the project progresses. The ultimate
goal is to have a good, very reliable, protocol for rsyslog-to-rsyslog
communications. I'll don't care about the outside world, so I can do the
best of breed solution. For the rest of the world, rsyslog will of
course continue to support plain tcp syslog and will get better support
for rfc 3195. But if you wanna go hardcore on high-reliability,
high-performance event logging, relp will be your choice.

Technically, I'll split this off into rsyslog relp input and output
plugins AND an independent librelp, which provides core protocol
functionality (just in case somebody else wants to support it in the
long term, so this will not be tied to rsyslog).

> 
> >> 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! I'll have to look more closely at this in a staging
> environment down the road, as I can't afford potentially
> running into another stumbling block at the moment.
> 
> 
> > A side-note: we are rewriting phpLogCon, the web interface to syslog
> > data. Any chance you happen to have some interest in that? ;)
> 
> It'll be a couple weeks before I really start looking into
> this, but yes, I was in fact planning to setup phpLogCon, too.

Excellent. Please keep an eye on its beta announcements - various stages
of v2 will probably be available in a few weeks and I promise it will be
much better than what is currently there. In fact, it tries to become
the best-ever log web viewer. If there are some things you'd like to see
in such a viewer, it would be great to hear your opinion.

Rainer