System integrations are integrations enabled by default that integrate into the
standard library or the interpreter itself. Sentry documents them so you can see
what they do and that they can be disabled if they cause issues. To disable
all system integrations, set
default_integrations=False when calling
This integrates with the interpreter’s
atexit system to automatically flush
events from the background queue on interpreter shutdown. Typically, one does
not need to disable this. Even if the functionality is not wanted, it’s easier to disable it by setting the
0 in the options passed to
This integration registers with the interpreter’s except hook system. Through this, any exception that is unhandled will be reported to Sentry automatically. Note that exceptions raised in interactive interpreter sessions will not be reported.
You can pass the following keyword arguments to
$ python >>> import sentry_sdk >>> from sentry_sdk.integrations.excepthook import ExcepthookIntegration >>> sentry_sdk.init(..., integrations=[ExcepthookIntegration(always_run=True)]) >>> raise Exception("I will become an error")
By default, the SDK does not capture errors occurring in the REPL (
This integration deduplicates certain events. The Sentry Python SDK enables it by default, and it should not be disabled except in rare circumstances. Disabling this integration, for instance, will cause duplicate error logging in the Flask framework.
The stdlib integration instruments certain modules in the standard library to emit breadcrumbs. The Sentry Python SDK enables this by default, and it rarely makes sense to disable.
Any outgoing HTTP request done with
httplibwill result in a breadcrumb being logged.
httplibunder the hood, so HTTP requests from those packages should be covered as well.
(New in version 0.10.0) Subprocesses spawned with the
subprocessmodule will result in a breadcrumb being logged.
Sends a list of installed Python packages along with each event.
(New in version 0.5.0)
sys.argv as an
extra attribute to each event.
(New in version 0.7.3)
Reports crashing threads.
It also accepts an option
propagate_hub that changes the way clients are transferred between threads, and transfers scope data (such as tags) from the parent thread to the child thread. This option is currently disabled (
False) by default, but this will likely change in the future.
Next are two code samples that demonstrate what boilerplate you would have to write without
propagate_hub. This boilerplate is still sometimes necessary if you want to propagate context data into a thread pool, for example.
import threading from sentry_sdk import Hub, init, configure_scope, capture_message init(...) with configure_scope() as scope: scope.set_tag("mydata", 42) def run(thread_hub): with thread_hub: capture_message("hi") # event will have `mydata` tag attached # We take all context data (the tags map and even the entire client # configuration), and pass it as explicit variable # into the thread. thread_hub = Hub(Hub.current) tr = threading.Thread(target=run, args=[thread_hub]) tr.start() tr.join()
Example B: Automatic propagation
import threading from sentry_sdk import Hub, init, configure_scope, capture_message from sentry_sdk.integrations.threading import ThreadingIntegration init(..., integrations=[ThreadingIntegration(propagate_hub=True)]) with configure_scope() as scope: scope.set_tag("mydata", 42) def run(): capture_message("hi") # event will have `mydata` tag attached # The threading integration hooks into the stdlib to automatically pass # existing context data when a `Thread` is instantiated. tr = threading.Thread(target=run) tr.start() tr.join()