-
Notifications
You must be signed in to change notification settings - Fork 565
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
Initial integration of Sentry (crash monitoring) #4172
Conversation
…nd bugs in OpenShot. Removing the old hooks and HTTP posts to openshot.org, since they would be redundant. Sentry is still gated behind our 'send_metrics' setting, just like before.
This generally works great, except for one big issue. Our custom logger, which redirects all STDERR to both the console and our log file... causes a bunch of individual traces on Sentry. Each log.error() level message generates a separate trace event... which is of course not correct. If I remove the STDERR redirection, we lose exceptions from our log file, and we lose certain output from other programs I think (such as blender output)... I need to do more testing around this though. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Can't wait to see the data start coming in.
Did you turn on |
(Also, setting a development |
Meanwhile, I'll try to figure out why the Python bindings in the libopenshot PPA builds currently seem to think (Edit: No clue. Works fine in my Ubuntu Focal VM as well, with the newest libopenshot PPA installed. Doing a full |
Then again, maybe not. I mean, we should strive to eliminate all error conditions, and maybe having them tallied in Sentry will motivate us. As long as they're captured in a lightweight way, getting totals on how frequently they occur would be good data to have, even if we mostly ignore it. (This presumes their filtering and drill-down is robust enough that "mostly ignore it" is a workable option. I haven't looked at the reporting interface yet, still trying to figure out which way I'm supposed to create my account.) |
@ferdnyc Just sent you an invite to Sentry |
@ferdnyc If I disable our Logger redirection of stdout and stderr, sentry will log a single trace event for an error. It includes a stack trace in my examples (at least for unhandled exceptions, such as 1 / 0). But with our Logger redirecting things to stderr, it generates a ton of noise on Sentry. |
Regarding the Sentry filtering and grouping... it's pretty great. And lots of great ignore rules. However, I want to make sure we have as much detail about errors as possible, including stack traces when available, and also minimize noisy useless info. An actual exception should generate a single Sentry trace ideally... and not 10 of them, lol |
@jonoomph Ah, gotcha. Probably for the same reason this happens: A total mess on
|
It took me ALL night, but I believe I have solved the logging/redirection issue. #4175 is a complete overhaul of
|
…#4175) StreamToLogger is now backed by a filter on the console stream handler, which rejects messages that originated ON stdout/stderr. Additionally, StreamToLogger's capture now only logs after the output is flushed, meaning multi-line tracebacks and the like will be logged as a single message.
@ferdnyc This seems to work great, as far as I can tell! Nice work! 🏆 I am seeing stack-trace output in both our log files and only a single exception sent to Sentry! Woot! |
Another interesting idea... is to catch the before_send event (should be possible with Sentry), collect the current trace ID, and display an error icon on the main toolbar in OpenShot (maybe a little bug or exclamation mark). The user has 30 minutes to click the bug, and enter a text description of what happened before the bug... and Sentry has an API we can call, to append the user feedback to the actual trace/exception report. This sounds like a really cool idea though! I like this idea vs opening a dialog, in those cases where we might have a bunch of errors, or a repeating error... I would hate to block the entire UI continuously with a user-feedback dialog. |
I definitely hate the idea of ever forcing a dialog on the user, TBH most of our EXISTING message dialogs should go. (The user never, EVER needs to be interrupted to be told we couldn't read an icon or a transition image, with the possible exception of it being one that's actually referenced in the project file. But when building the models? Nuh-uh. Totally not their problem.) Regarding If it's possible in the Sentry API to attach user feedback to existing data after-the-fact, so we could deliver the initial data immediately and then update it if/when they provide details, that feels safer to me. In which case, I don't see the point of the 30-minute timeout... can we just leave the option open at least through the end of the session? (Or the next session, if it's crash-recovery feedback.) If not... well, indefinitely? (Fedora's Abrt lets users open bugzilla tickets off of any unreported crash log that's still in its cache -- hours, days, weeks, even months old. I'm not saying we have to go that far, but 30 minutes is an awfully short arbitrary window. Especially if you're in the middle of trying to actually do something productive with the program that just crapped itself, and don't really have 5 minutes to spare RIGHT NOW so you can describe how.) |
Yeah, it would immediately send the trace to Sentry... but we have 30 minutes of additional time to collect user input (if we want to) and POST it to their API to append to our trace. |
I've tested this on all 4 builders/installers, and it seems to work (best I can tell). |
Initial integration of Sentry tracing, to better track stack-traces and bugs in OpenShot. Removing the old hooks and HTTP posts to openshot.org, since they would be redundant. Sentry is still gated behind our 'send_metrics' setting, just like before.
Sentry.io offers far better error reporting than my crude home-made version, and will allow more developers to monitor the exceptions, group them, and convert them into useful information and ultimately bug fixes.