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

feat(develop-docs): SDK Debug Mode #12100

Merged
merged 4 commits into from
Dec 13, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 25 additions & 0 deletions develop-docs/sdk/expected-features/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -77,6 +77,31 @@ Backend SDKs (typically used in server applications) should have backpressure ma

See <Link to="/sdk/telemetry/traces/backpressure/">Backpressure Management</Link> for details.

## Debug Mode

Every SDK must implement a debug mode, which is disabled by default. Users can enable it by setting the option `debug` to `true`. If the debug mode is enabled, the SDK prints out useful debugging information for two main purposes:

1. It helps users identify and fix SDK problems, such as misconfigurations or something going wrong with sending data to Sentry.
2. It can help Sentry SDK engineers investigate issues in Sentry SDKs, which can be done while developing or by asking a user to enable the debug mode and share the debug logs.

As the log output can add unnecessary overhead, we advise users to refrain from enabling the debug mode in production. Still, SDKs may log fatal error messages even when the debug mode is disabled. When using debug mode extensively for the second use case, we recommend adding the diagnostic level because users could easily miss error or fatal log messages.

### Diagnostic Level

SDKs may offer an optional diagnostic level, which controls the verbosity of the debug mode. There are five different levels:

- `debug`: The most verbose mode
- `info`: Informational messages
- `warning`: Warning that something might not be right
- `error`: Only SDK internal errors are printed
- `fatal`: Only critical errors are printed

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.
philipphofmann marked this conversation as resolved.
Show resolved Hide resolved

### Auto Debug Mode

So users can easily spot errors during development, the SDK can automatically enable debug mode when it reliably detects it's running in a debug build. When doing so, the SDK must communicate this in the docs and with a log message when initializing the SDK. When the user explicitly sets the `debug` option to `false`, the SDK must disable the debug mode.

## In-App frames

Stack parsing can tell which frames should be identified as part of the user’s application (as opposed to part of the language, a library, or a framework), either automatically or by user configuration at startup, often declared as a package/module prefix.
Expand Down
Loading