Reduce the amount of debug logs

[vaind]

Problem Statement

When I am running my flutter app locally flutter run, the Sentry SDK emits logs as well since it is default debug: true. This consumes everything in my console and make it impossible to catch other framework, libary, build, run time console logs related to errors when trying to run my app.

Also when replay is present event setting debug: false, does nothing. This is it's own bug #2759

Solution Brainstorm

1. There's a lot of logging happening in debug builds (with debug=true) for Replay. For example, the WidgetFilter logs a lot of info that was meant to be used during development but we don't actually need that most of the time. We should verify the logs are relevant and if not, remove them.

2. Alternatively, we could bump the default log level for when options.debug is true from SentryLevel.debug to SentryLevel.info.

• context: https://develop.sentry.dev/sdk/expected-features/#debug-mode

3. Add debug levels, not just true/false. A verbose flag for example, or multiple levels the user can choose from, which when NOT set, the SDK will never log, entire event payloads for example, since that takes up a ton of space.

Backstory

SDKs can choose what the default log level is, develop docs:

The default level can be debug or error depending on the SDK's usage of log messages. When the volume of log message is low, the default can be debug. When it is high, users might easily miss errors or fatal messages. In that case, the SDK should set the default level to error. This choice must be clearly documented in the user-facing docs.

We recently changed this on some mobile SDKs because we have so many debug logs that you can easily miss critical errors. This came up at a customer call with [redacted]. We tried to fix a problem and missed a critical error log message that would have easily pointed them to fix it themselves. Now the Cocoa SDK, for example, logs always logs error even when having debug = false. Debug = true is extremely verbose and handy for diagnosing SDK issues.

[buenaflor]

Alternatively, we could bump the default log level for when options.debug is true from SentryLevel.debug to SentryLevel.info.

related: getsentry/sentry-cocoa#4467, cocoa plans to set it to warning we could also adopt that here

[buenaflor]

Add debug levels, not just true/false. A verbose flag for example, or multiple levels the user can choose from

isn't that what the diagnosticLevel option is for? the user could change that e.g to SentryLevel.fatal

[vaind]

Add debug levels, not just true/false. A verbose flag for example, or multiple levels the user can choose from

isn't that what the diagnosticLevel option is for? the user could change that e.g to SentryLevel.fatal

I agree.

I believe that part is @smeubank's edit so maybe he'd like to clarify.

[smeubank]

I think the default experience should be less. Replay and android logs, both seem to be contributing too much in an erroneous way, whcih should be fixed, But overall the default debug experience of SDKs is way too verbose in my opinion. cc @cleptric for thought across SDKs, but using diagnosticLevel or --verbose type flags should only be in special scenarios where you need SOO much info. Rarely is logging the whole JSONs really useful for anyone for example. That should not be included in simply debug: true

[cleptric]

The trend we've seen is actually quite the opposite. People manually instrument something, it does not work, our debug logs don't help. So I'm actually more inclined to be as verbose as possible. On certain platforms, merging your app's stdout with all the Sentry SDK logs can be a PITA though. I have no good solution besides offering a dedicated log stream.

[smeubank]

The trend we've seen is actually quite the opposite. People manually instrument something, it does not work, our debug logs don't help.

1. i think this is directed at those who do complain
2. i would be curious to understand why they don't help, and fix that problem instead of just going with verbose AF. This isn't a fix, this is using the whole roll of duct tape and hoping for the best.

Because for me the debug logs on most SDKs i use don;t help. I want to understand what the SDK is doing on a high level at first. THEN get into verbose details only maybe later. I still stand by loggin JSON event bodies as being way too much 90% of the time.

[cleptric]

I still stand by loggin JSON event bodies as being way too much 90% of the time.

Yes, this is overkill.