feat: API for manual performance monitoring (NATIVE-309) #395
Conversation
Swatinem
changed the title
Swatinem
force-pushed
the
feat/performance
branch
from
58d51f5
to
3ef3dcd
Compare
Swatinem
changed the title
| // "Context" Types: | ||
|
|
||
| /// The Transaction Context used to start a new Performance Monitoring Transaction. | ||
| /// | ||
| /// The Transaction Context defines the metadata for a Performance Monitoring | ||
| /// Transaction, and also the connection point for distributed tracing. | ||
| #[derive(Debug)] | ||
| pub struct TransactionContext { | ||
| name: String, | ||
| op: String, | ||
| trace_id: protocol::TraceId, | ||
| parent_span_id: Option<protocol::SpanId>, | ||
| sampled: Option<bool>, | ||
| } |
There was a problem hiding this comment.
slightly nitpicky question; is there any reason why this couldn't be abstracted away into Transaction itself? what's the benefit of explicitly exposing TransactionContext as opposed to just having just Transaction by itself (presumably with all of TransactionContext's methods on Transaction instead)? you could also move start_transaction so it becomes Transaction::start(), and then creating a transaction is a matter of just:
Transaction::new("honk", "beep");
# Transaction::set_sampled(...);
Transaction::start();
or
Transaction::continue_from_headers(...);
Transaction::start();
There was a problem hiding this comment.
it also avoids interesting discrepancies between the two structs, such as TransactionContext's op being String but Transaction's op being Option<String>.
i guess the major drawback is that sentry::start_transaction() doesn't really exist with this suggestion... 🤔
There was a problem hiding this comment.
Interesting. I don’t really want to go down the route of bikeshedding this.
There was a problem hiding this comment.
overall this looks like a solid start 🎉 this is missing a few things on the Transaction/Span/TransactionOrSpan structs such as the ability to change or add a name after their creation, but they're not necessary for basic performance monitoring.
some unit tests ona few methods like continue_from_headers or iter_headers would be neat as well.
lets talk about that later today. This is needed for the followup #400 as its currently not possible to add data/tags to the span/transaction. |
This implements a manual performance monitoring API, which tries to follow the unified API spec.
One can start a transaction on its own, or based on a distributed tracing header (or another Span), as well as start new child Spans.
Hooking this up to other external services downstream should be possible via an
iter_headersthat allows attaching the headers to outgoing Http requests.Spans are recorded as part of the transaction they ultimately belong to on
finish.Transactions are being sent to sentry properly when they are being
finished.A Span can be attached to the scope as the current span, and queried via
Scope::set_span/get_span.This makes it possible to for example query for distributed tracing headers anywhere in the application, or create a child span anywhere.
The current span is also used to attach the trace context to any event that is being captured as long as a current span exists.
What is currently missing is the ability to add more attrs/metadata to a span after it was created, and the API as a whole would need some polishing down the road, however this implementation is enough to consider this feature "done" and to ship it to customers (and possibly dogfood it ourselves in symbolicator).