Hi, I don't understand this conversation. If you are sending messages via UDP there are thousands of $reasons why you can lose a message.
Even if you are using TCP you can lose messages if you don't configure rsyslog to run "in reliable mode". Because of these different $reasons you cannot compare with data from different setups (change one piece, i.e. different network hardware, updated router software..., and you could face different problems). So why should one waste time in quantifying log loss in such an unreliable setup? As said above: If you would have found a working setup for you (you tested everything, fine-tuned everything, quantified everything), changing _anything_ could change _everything_. If you would really care wouldn't you install a local rsyslog daemon (Ra) on the application server and make sure your application uses syslog() to log data (so it is guaranteed that this call hang/fail if syslog cannot read/accept the message)? In the next step you would have to make sure that rsyslog is running in a reliable mode, i.e. with queue etc. to ensure that rsyslog won't ever throw away a message. >From this instance you would now send your data to the next hop (Rr) via RELP. You would also have to configure your Rr instance the same way to ensure that it will never throw away a message. If you will ever see a message loss in such a setup there must be a bug. -Thomas _______________________________________________ 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.
