rfc(feature): Continue trace over process boundaries #71
Conversation
627e00f
to
688a80b
Compare
| - `SENTRY_TRACING_BAGGAGE` (similar to `baggage` HTTP header) | ||
| - `SENTRY_TRACING_SENTRY_TRACE` (similar to `sentry-trace` HTTP header) | ||
|
|
||
| The environment variables contain the same strings that the respecitve HTTP headers would contain. |
There was a problem hiding this comment.
We should also define what happens when multiple mechanisms are enabled, e.g. when SENTRY_TRACING_USE_ENVIRONMENT is set to true, but also we have incoming HTTP/other requests with different sentry-trace values.
It raises some questions: for example, should the trace-id from SENTRY_TRACING_SENTRY_TRACE "override" all other trace-ids, received via HTTP? Probably not.
Or do we want to limit this RFC to purely non-server environments?
There was a problem hiding this comment.
There can only ever be once trace so when an incoming HTTP request is coming in, it starts a new trace in a new hub, shadowing the process one. We do not have a trace to trace relationship so they will be disconnected which is reasonable.
|
This would allow errors to be associated to trace IDs as well correct? That's probably the more immediate case for the Cron monitoring feature, is being able to trace errors in sentry to specific monitor checkin failures. |
There was a problem hiding this comment.
I believe a non covered omission here is if we want a flag on a transaction that says "do not emit me" but do consider me sampled (to avoid charging customers unnecessary transactions). I don't think it should be part of the RFC, but it should me mentioned in a section that refers to out of scope discussions.
| - `SENTRY_TRACING_BAGGAGE` (similar to `baggage` HTTP header) | ||
| - `SENTRY_TRACING_SENTRY_TRACE` (similar to `sentry-trace` HTTP header) | ||
|
|
||
| The environment variables contain the same strings that the respecitve HTTP headers would contain. |
There was a problem hiding this comment.
There can only ever be once trace so when an incoming HTTP request is coming in, it starts a new trace in a new hub, shadowing the process one. We do not have a trace to trace relationship so they will be disconnected which is reasonable.
Yes, this is possible @evanpurkhiser |
Co-authored-by: Anton Ovchinnikov <[email protected]>
To make it possible to continue a trace over process boundaries (think of one program starting another one) For this to work we will use environment variables as the carrier.
Rendered RFC