PoC: Add request_hook to all loaded instr libraries #123
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PoC: Adds
request_hook
kwarg toinstrument(**kwargs)
of all loaded instrumentation libraries at custom distro startup. Not for any ticket in particular and just for visualization. This might mean we have more opportunities for manipulating span creation in addition to what I've written in the doc section How do OTel Python spans get created!Some but not all OTel Python instrumentation libraries call its received
request_hook
method "right after a span is created for a request". For Django at least, the span at time ofrequest_hook
is mutable_Span
and we can change its attributes!Example stdout, where attributes include the arbitrary
request-hook-foo
as well as KVs we use for transaction name calculation while the span is still mutable:Example trace, where the
home_a_reentry/
,another/
, andhome_b/
server spans include the arbitraryrequest-hook-foo
attribute added to them by ourrequest_hook
method: https://my.na-01.cloud.solarwinds.com/140638900734749696/traces/42FA5A3869B78465B239FAD568A76BCC/04A0226E0217181C/details/breakdownI don't think this can be used for transaction filtering by way of early
DROP
because (a) the span has already been created, and (b) anything arequest_hook
method returns won't be used (how Django calls it here). So returning aNonRecordingSpan
can't drop the trace (I've tried this and we still get the same full trace).