On Tue, Jun 24, 2014 at 07:29:15AM +0200, Willy Tarreau wrote: > Hi Simon, > > On Tue, Jun 24, 2014 at 09:15:13AM +0900, Simon Horman wrote: > > Hi Willy, > > > > Malcolm has asked me to open a discussion with you regarding adding > > email alerts to haproxy and that is the purpose of this email. > > > > In essence the motivation is to provide a lightweight email alert > > feature that may be used in situations where a full-blown monitoring > > system is not in use. > > > > There is some discussion of this topic and several solutions, > > including patches to haproxy, on the loadbalancer.org log. > > > > http://blog.loadbalancer.org/3-ways-to-send-haproxy-health-check-email-alerts/ > > > > Would you be open to including such a feature in haproxy? > > > > If so I had it in mind to have haproxy send emails using the sendmail > > command, > > a variation of the mailx implementation at the link above, avoiding the > > need to implement an SMTP client. > > > > I was thinking it could be configured using directives like the following, > > borrowing ideas from my recent external-agent patch. > > > > global > > email-alert > > > > listen ... > > > > option email-alert > > email-alert command sendmail > > email-alert path /usr/sbin:/usr/lib > > email-alert from [email protected] > > email-alert to [email protected] > > email-alert cc [email protected], [email protected] > > email-alert bcc [email protected] > > email-alert subject Loadbalancer alert > > email-alert custom-header X-Custom: foo > > > > It might be nice to allow the use of printf style directives in > > the subject to allow it to include the name of the proxy and other > > useful information. I expect that different users have different needs > > there. > > We had such an idea in the past, however the principle was to use the > address of a smart relay host. We cannot use a command because the process > is supposed to be chrooted.
Thanks, if that is the direction you wish to take things then I'm happy to do so. I guess a simple SMTP client is not an insurmountable challenge. But I wonder if there is any infrastructure in haproxy that might make such an implementation easier. If so, could you point me at it? > Also, in my opinion the SMTP relay should be > per section (ie: supported in the defaults section) because in shared > environments, customers want to use a different gateway and e-mail > settings. Yes, I agree that sounds like a good idea. > In fact in the ALOHA we have implemented a daemon which watches > the unix socket to send e-mails because by then it was too much work to > implement it natively. Now it should be much simpler. I'm clad to hear it will be simpler though I'm not sure that I understand why this is so. > I was just wondering whether we should not go slightly further and support > "mailer" sections just like we have peers. I'd like to do the same for DNS > resolving later and I think it makes the configs more understandable, and > more flexible (eg: later we can think about having multiple mail relays). I also agree that sounds reasonable. I'll see about making it so. > We also want to have the ability to define what events can result in an > e-mail alert. For example, I know some hosting providers who absolutely > want to know when a service is operational again (so that they can drive > back home), while others absolutely refuse to be spammed with such info. Thanks. I meant to include that in my proposal. I agree it is important. > Sections also make it possible to add extra settings for the mail relays, > for example SSL + a certificate. Or maybe some default from/to/... Agreed. I would prefer to only handle plain-text to start with. To allow a working prototype to be slightly closer to hand. But I agree that SSL support, I assume in the form of STLS, is an important feature.
