[rsyslog] ultra-reliable speed test

[Rainer Gerhards]

> -----Original Message-----
> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-
> bounces at lists.adiscon.com] On Behalf Of david at lang.hm
> Sent: Friday, May 08, 2009 7:38 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] ultra-reliable speed test
> 
> > However, I also know that for regulatory requirements, you often seem to
> > need to prove that a system may not lose messages once it has received
> > them, even at the cost of an overall increased probability of message
> > loss.
> 
> it's a bit more than that.
> 
> In my case I have two completely different use-cases, and will almost
> certinly end up running two different sets of rsyslog (potentially on
> different sets of servers)

OK, that is the ultimate explanation. Due to our lengthy discussions about
performance, I was so preoccupied with performance that I did not realize
that you talk about a very different use case. More importantly, I did not
see that you talk about using only reliable transports (or, in other words:
no standard syslog at all). From that perspective, everything makes perfectly
sense to me, too.

I'd still be interested in the performance numbers (though they are no longer
needed to convince me this is a valid use case ;)).

Just to verify: this is a use case that you cannot build with e.g. syslog-ng,
as it does not speak any truly reliable logging protocol. Actually, you need
audit-grade protocols, and then an audit-grade core engine makes sense.

Did I get you right this time?

Rainer 

> 
> case #1
> 
> 'normal system syslogs'
>    99.9% reliability (easy to achieve with UDP) is easily good enough.
>    the sender is normal software that knows nothing about rsyslog
>    high volume, mostly junk
> 
> 'logs of record'
>    the application is modified to do application level acknowledgements
> (relp or similar), and the system must be architected to not loose logs
> once they are acknowledged short of a disaster that physically destroys
> equipment (storage drives must be redundant so that a drive failure does
> not loose logs)
>    low volume, every log is critical.