Multi-hub setups

[sl0thentr0py]

Sometimes within a larger application, users want to use different DSNs for different parts of the application. The following sample shows how to setup two hubs and send exceptions to different DSNs.

import sentry_sdk

DSN1 = "<dsn1>"
DSN2 = "<dsn2>"

first_hub = sentry_sdk.init(DSN1, debug=True)
second_hub = sentry_sdk.Hub(sentry_sdk.Client(DSN2, debug=True))

try:
    1 / 0
except Exception as e:
    # sent to DSN1
    sentry_sdk.capture_exception(e)


with second_hub:
    l = {}
    try:
        x = l['adasdasdasdas']
    except Exception as e:
        # sent to DSN2
        sentry_sdk.capture_exception(e)

second_hub.flush()

As a caveat, in general, some of the integrations logic might not work with such multi-hub setups, please report if something doesn't work and we'll try to figure it out together. These are edge case usages and the SDK is definitely not built with such scenarios in mind.

---

Related issues

#610

[DanielNoord]

Just wanted to comment that this solution doesn't really work for the use case that was supported by the comments in the linked issue. It's a bit unfeasible to start adding contextmanagers to every place where we want to log to our secondary DSN. Doing this based on the name of the logger worked/works quite well and doesn't add all the boilerplate of the contextmanagers.

Support for something similar would be appreciated.

[H3zi]

Do you have any plans to fully support multi-DSN (i.e. clients) in the future?
In my use case, we have an SDK that other services will install. each one of them will have its sentry client, but I want to be able to monitor issues and performance of my SDK with a different DSN (project).

[realkosty]

@sl0thentr0py we have an enterprise customer who needs this to manage quotas across teams all contributing to a very large codebase. They don't mind having to write some custom code but my understanding is that with a hub-based solution you provided above all the breadcrumbs etc will go on the main hub and ones going to alternative hubs/DSNs would only have a stack trace. Is that correct?

[sl0thentr0py]

yes, unfortunately.
They'd have to do a lot of the scope/thread management themselves. Bottomline is our SDKs are in no way defined for that use case.

[realkosty]

Understood. FWIW I think we should implement it on the server-side, reusing ownership rules engine. But even though there have been plenty of feature requests for this use case across all of our SDKs, it's unlikely to happen anytime in the foreseeable future. That's why we're hoping for workarounds on the client-side to address this need now. Thanks for all the info.

[yuval-sentry]

@sl0thentr0py @realkosty
Shouldn't we be able to configure a scope for each hub which will preserve the breadcrumbs?

[sl0thentr0py]

they'd have to pass in the relevant hubs and their clones in requests/threads etc, it's complicated

[mark-agustin-render]

Inside the with second_hub when I try to add(code below), and do a sentry_sdk.capture_message, I get this warning even if I'm passing a valid IP address

 user_details = {
     'id': request.user.id,
     'username': request.user.username,
     'email': request.user.email,
     'ip_address': request.META.get('REMOTE_ADDR', None),
 }
 set_user(user_details)
 add_breadcrumb(
      category='frontend',
      message=error_message,
      level='error',
 )
 sentry_sdk.capture_message(error_type, "fatal")```