Sentry SDKs should be able to sample for transactions (performance events) at 100%.

Meaning the the developer setting up their Sentry service(s) for Sentry Performance should be able to set traces_sample_rate=1.0, and not worry that the SDK will have some significant impact on their applications performance, and definitely not that the service could be brought down by the SDK.

Hight throughput backend environments are typically the only services which face this concern, and then it is really only very large high traffic evironment faced by large business and enterprises.

Proposal:

1. find ways to improve the SDK, find and fix different bottlenecks
2. fail safe(s): SDK should be able to detect when there is failure imminent, or even a significant degradation to the host service and shut down
3. Agents (sidecar): Should an agent be required to truly meet this goal: what changes are necessary to achieve that

• for example HTTP requests ultimately make up a huge chunk of the OH caused by the SDks. Should we switch to a different communication method with an agent approach
• Would there be an agent mode of the SDK(s)? When relay is running locally then switch from HTTP. Otherwise works as usual (just as suggestion)

Outcome:

Sentry.io python services sample at 100%