raven-python
raven-python copied to clipboard
getsentry
Sentry is noisy on process exit
We are using Sentry to report errors from cron tasks. We have MAILTO set as a backup so that we receive emails about critical errors which happen before raven has a chance to initialize.
This leads to us getting the occasional email containing:
Sentry is attempting to send 1 pending error messages
Waiting up to 10 seconds
Press Ctrl-C to quit
It happens because there's a hardcoded initial_timeout of 0.1 seconds in the process exit hook. Is there any chance you could make this timeout configurable the way shutdown_timeout is?
+1
And we are receiving this message even if --verbosity 0 is set.
Since all django commands accept the verbosity option, it would be nice if raven_compat complies with it.
@ollb this isn't a Django feature, and while I agree we should allow some ability to make this less noisy, we're not going to make a one-off to try and support an arbitrary Django flag.
@dcramer At least would it be ok to have an option to control raven verbosity ? (I'm very new with raven and so I do not understand what is at stake).
By the way, I'm not sure what do you mean by "an arbitrary django flag". Since --verbosity is a flag defined in BaseCommand django class it should be usable by any django command. That said, I understand this might be a specific issue. So let's handle the first one.
@olib I mean arbitrary in that sentry is far wider reaching than just Django and it's not a management command that is happening for Sentry reporting.
Is it ok if this noise will be printed to stderr? I want to do so, but I'm not sure if it's enough.
We ended up solving the problem by putting a call to this function at the end of our scripts:
def silence_stdout_until_process_exit():
"""
Upon process exit, Sentry sometimes prints:
Sentry is attempting to send 1 pending error messages
Waiting up to 10 seconds
Press Ctrl-C to quit
This causes us to get emails from cron which are useless noise, since the
exceptions end up in sentry anyway. "Real" exceptions print to stderr, not
stdout, so this shouldn't silence anything important.
See also this issue: https://github.com/getsentry/raven-python/issues/904
"""
sys.stdout = StringIO()
It's ugly, but I think it's the best we can do without forking the library.
https://github.com/getsentry/raven-python/blob/a698fc406d2e0f26616f0163b2b22e1a3a5b30f5/raven/transport/threaded.py#L62
timeout = self.options['shutdown_timeout']
-
- # wait briefly, initially
- initial_timeout = min(0.1, timeout)
+ initial_timeout = self.options['initial_timeout']
if not self._timed_queue_join(initial_timeout):
Who will be the hero?
If you guys really want to hardcode this timeout and send to stdout, I thought of an alternative that would also solve the problem. Instead of unconditionally sending this through stdout where it will clobber your program output, send it through Python's logging framework with a suitably unique logger name such as raven.shutdown_flush. Then add a default handler for that logger during module init that sends the output to stdout. This would result in no change in the default behavior, but it would let users of the library override the default and route the message to wherever suits them best. @kornsn can send it to stderr in his apps, and the 10 people who 👍'd the issue can send it to NullHandler. Everybody wins.
This would help a lot to switch to using a logging logger to avoid messing with our well crafted stdout, please
Any news or tips on this? We have the same issue where we are getting useless notifications.
