On Sun, 2011-02-13 at 09:27 +0000, Alexander Clouter wrote:
Bill Anderson <Bill.Anderson@bodybuilding.com> wrote:
On Feb 12, 2011, at 16:08, "Alexander Clouter" <alex@digriz.org.uk> wrote:
* Tighter integration with syslog-ng allows for easier troubleshooting: one only has to look at one place
It does not answer "where did my email alert go?" Did syslog eat it? Did the smarthost toast it? Was it lost further upstream?
How is the any different than any other destination? SMS, MongoDB, SQL, etc. all have the same problem if it isn't where it is expected. Even files.
I phrased this badly. My point is that you have to look in the mail logs anyway, any syslog-ng logs is not going to tell you anything a call to the local sendmail binary does not.
That's not entirely accurate. If the problem is persistent, and can be reproduced with syslog-ng running in debug mode, my driver will echo back most of the SMTP session, so one can easily see whether the problem is between syslog-ng or the SMTP server used. Calling sendmail may or may not reveal that information: if you have a local mail setup that works, sendmail will accept the message. Then when the local MTA tries to deliver the message, it will encounter the same error then, and one will have to dig into the logs, which varies from MTA to MTA. With the program destination, one will need to assume that if there's network outage or any other error, the MTA will queue the mail and retry later. While this is true in most cases, it's not always the case. Thus, when one has an MTA that doesn't do this, program() can easily lead to lost messages. Using a built-in driver that uses syslog-ng's built in queuing will not have such problems. -- |8]