In my research of rsyslog to determine its suitability for a particular situation I have some questions left unanswered. I need relatively-guaranteed delivery. I will continue to review the available info including source code to see if I can answer the questions, but I hope it may be productive to ask questions here.
In the documentation, you describe the situation where syslog silently loses tcp messages, not because the tcp protocol permits it but because the send function returns after delivering the message to a local buffer before it is actually delivered. But there is a more-fundamental reason an application-level ack is required. An application can fail (someone trips over the power cord) between when the application receives the data and when it records it. 1. Does rsyslog send the ack in the RELP protocol occur after the message has been safely recorded in whatever queue has been configured or forwarded on so its delivery status is as safe as it will get (of course how safe depends upon options chosen), or was it only intended to solve the case of TCP buffering-based unreliability? 2. Presumably there is a client API that speaks RELP. Can it be configured to return an error to the client if there is no ACK (i.e. if the log it sent did not make it into the configured safe location which could be on a disk-based queue), or does it only retry? Where is this API? Certainly the TCP caching case you mention in your pages is one a user is more likely to be able to reproduce, but that is all the more reason for me to be concerned that the less-reproducible situations that could cause a message to occasionally become lost are handled correctly. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
