Is the webserver useful if you have an error that warrants sending a mail? If sending an email means the server is broken having a flood of mails may be a feature. It will be incentive to fix whatever is breaking your server/db. Also, I would strongly recommend keeping your warning system as simple as possible. Why not have the servers output an error message to a file on a single nfs file system and then setup a crontab to watch the file(s)? One machine could run the crontab every minute. 60 mails/min isn't too much unless you are forwarding it to a beeper in which case you could write a quick script to only mail once per unit time.
On Wed, Apr 17, 2002 at 11:56:36AM -0400, Benjamin Elbirt wrote: > Wow, > > I never expected the response I got! Well, lets assume that I were to go with > the shared memory option anyway... what would the pitfalls be / concerns? The > truth is, I don't want a separate system (as per the e-mail about having an > error handling server), and I don't want to have to manage the e-mail on the > receiving end because I'm not the only person who receives it (didn't mention > it, but I guess that's important). Further, I have no control over the mail > server that handles the incoming mail so I'd have to handle it on the mail > client (Outlook / Netscape Mail) resulting in the same problem I have now. > > Thanks, > > Ben > > Perrin Harkins wrote: > > > Andrew Ho wrote: > > > Your error handlers on your five load-balanced boxes send an HTTP request > > > to this error handling box. > > > > That sounds kind of slow, since it requires a network connection to be > > created every time and some synchronous processing on the other end. It > > also depends on that box always staying up. I think e-mail is actually > > a good approach, since it's a robust message queuing system and if you > > use something like qmail-inject to send the e-mail it takes almost no > > time at all for mod_perl to finish with it and move on. You just need > > to process those messages on the other end instead of looking at the raw > > output, i.e. use Mail::Audit to keep track of the current state and > > remove duplicate messages. > > > > Matt posted something about PPerl yesterday, which could make a > > Mail::Audit script more efficient by keeping it persistent. > > > > - Perrin > > -- 28 70 20 71 2C 65 29 61 9C B1 36 3D D4 69 CE 62 4A 22 8B 0E DC 3E mailto:[EMAIL PROTECTED] http://thecap.org/
