Email log

[brokkr]

It should be comparaively easy to add support for mailing the changes to yourself? At least with a local mail server. See dispatches for inspiration.

[brokkr]

https://docs.python.org/3/library/logging.handlers.html#smtphandler

[brokkr]

Even though the usefulness of this is questionable (maybe you would want an email when a feed repeatedly fails, like podcast.init did?) it would provide a good opportunity to redo logging. I believe the proper approach would be to use a separate logger, rather than just a separate handler, for each destination if the output is different? Or maybe subclass some of it to do the differentation?

[brokkr]

There seems to be two schools of thought: 1) Use (subclass) filters and use one to discard one kind of messages and not the other and 2) Just use multiple loggers as "they're inexpensive".

http://stackoverflow.com/questions/879732/logging-with-filters

[brokkr]

As for the when (how often) to email log and what to put in, here are some options:

• Logging is global similar to stream and file - every line equals one email
• Logging is per-subscription: You probably only want to be notified of your favourites. Or we could implement (issue Defaults #9 ) and overrule on a per-subscription basis.
• Email logging is mostly about uncovering errors. But getting emails for every single time a connection times out or a server is briefly offline is tiring. So we would need to store an error count and error summary per subscription. Then when a threshold is passed - say, a podcast check has failed ten times in a row (successfully connecting shoudl reset counter) - we fire off an email and reset.

[brokkr]

Is there a common denominator for error reporting for file log and email? For file log the ideal seems to be one report per update (nor per subscription as connection errors would just be repeats). For email the ideal would be once per say 10 errors per subscription (so as to uncover subscription specific errors)

[brokkr]

Can we either: a) pickle the bufferingsmtp logger/handler or b) subclass bufferingsmtphandler in such a way that it saves on close (rather than flush) and loads on creation?

Some similar thoughts: http://stackoverflow.com/questions/3375443/cant-pickle-loggers

[brokkr]

I think we can keep it simple. First, we add unpickling the buffer to the BufferingSMTPHandler's init and saving it to flush (either before or after we reset it, depending). This can work regardless of the handler's level. If we only want the occasional email when errors keep occuring, the handler gets the error level, else info. The number of entries is compared to some user setting. If the number exceeds it, we sendmail, reset buffer and pickle buffer. If not, we simply pickle the buffer and move on.

The question remains if we keep separate error buffers for each sub (which can be saved in the sub's pickle) or if we need a global state one. Global seems simpler, as summarylogger already operates on the assumption that sub messages are mixed.

We should start by simply adding the unpickling to init and adding pickling to flush. KISS. Keep capacity high and pickle the lot if we're not above capacity. Let it build up. Then we try lowering capacity and see what happens.

[brokkr]

How do you tell your user that his logging configuration isn't working without starting an infinite loop...?

[brokkr]

What are we still missing:

• Documentation
• Doing something about the Silent Failures
• The train test: Can it cope with Arriva's horrible wifi without throwing a tantrum?