Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Email log #26

Closed
brokkr opened this issue Aug 31, 2016 · 9 comments

Comments

@brokkr
Copy link
Owner

commented Aug 31, 2016

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 brokkr added the enhancement label Aug 31, 2016

@brokkr

This comment has been minimized.

Copy link
Owner Author

commented Sep 2, 2016

@brokkr brokkr changed the title Email log: Have changes noted on a daily / hourly(?) basis and mailed to you Email log Sep 2, 2016

@brokkr brokkr added the no-milestone label Sep 2, 2016

@brokkr brokkr referenced this issue Sep 5, 2016

Closed

'Terse' output #32

@brokkr brokkr removed the no-milestone label Sep 18, 2016

@brokkr brokkr added this to the 0.7 milestone Sep 18, 2016

@brokkr

This comment has been minimized.

Copy link
Owner Author

commented Jan 5, 2017

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

This comment has been minimized.

Copy link
Owner Author

commented Jan 6, 2017

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

This comment has been minimized.

Copy link
Owner Author

commented Jan 6, 2017

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 #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

This comment has been minimized.

Copy link
Owner Author

commented Jan 25, 2017

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

This comment has been minimized.

Copy link
Owner Author

commented Feb 3, 2017

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

This comment has been minimized.

Copy link
Owner Author

commented Feb 5, 2017

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

This comment has been minimized.

Copy link
Owner Author

commented Feb 8, 2017

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

@brokkr

This comment has been minimized.

Copy link
Owner Author

commented Feb 8, 2017

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?

@brokkr brokkr closed this in fb72399 Feb 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant
You can’t perform that action at this time.