New Performance API Wishlist
Opened this issue · 4 comments
Description
This issue shall serve as a sort of wishlist where we can collect ideas for the new Performance API.
If you have anything you'd like us to improve when reworking our Performance API in the Java SDK, please do leave a comment.
Here's some ideas:
- Get rid of transaction, only have spans in the API (note, depending on when we rewrite the API, the Sentry UI in product will likely still have transactions but the Java SDK API will not have those anymore)
- Have spans added to the scope by default (this may not apply to Android due to
globalHubMode) - Make it easier to continue a trace (
Sentry.continueTrace->Sentry.startTransactionis more complicated than it needs to be) - Consider moving to something like a Propagator design that OpenTelemetry has for extracting and injecting tracing information
- Merge different objects used for tracing information (
PropagationContext,TransactionContext/SpanContext,Baggage,TraceContext) - Have the span implement
AutoClosableso it can be used intrywith resources statements and have the span finished automatically - Align attributes / data closer to OpenTelemetry (this may mean limited support for data types)
NOTE: A reworked Performance API will likely be a breaking change where we completely remove the old API as it will likely be very hard (if not impossible) to make them coexist. So we can use this as an opportunity to clean up.
I request feature parity with other SDK's that have already made the transition to the Spans Only model. And documentation parity.
Baggage storing everything as String might not be ideal and requires workarounds like #4279 where we now store certain values directly in its most used type to avoid performance problems.
We should check if there's a way to avoid this.
Not creating spans for certain URLs (e.g. on outgoing HTTP requests) should be possible.
We currently have beforeSendTransaction as a workaround that allows dropping spans from the transaction. This however will no longer be possible with Spans API (see docs) so we should implement an ignoreSpans filter.
Remove deprecated OTEL classes (span processor and propagator).