feat: make the ASGI receive/send spans opt-out on FastAPI - #225
Merged
Merged
Conversation
lesnik512
force-pushed
the
feat/otel-exclude-spans
branch
from
September 19, 2026 11:30
1e7b554 to
5cbee38
Compare
Every request produces three spans today: the server span plus one each for the ASGI receive and send events. #185 benchmarked dropping the latter two at 33 µs/request, a quarter of the instrument's cost. The field is FastAPI-scoped because the parameter is: Litestar's instrumentor has no counterpart, so a shared OpenTelemetryConfig field would be inert everywhere but one bootstrapper. The default stays empty, since dropping spans changes what an existing service sees in Jaeger or Tempo.
lesnik512
force-pushed
the
feat/otel-exclude-spans
branch
from
September 19, 2026 11:35
5cbee38 to
793458e
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Closes #185.
opentelemetry_exclude_spansonFastAPIConfig, passed toFastAPIInstrumentor.instrument_app.Where the field lives
On
FastAPIConfig, not the sharedOpenTelemetryConfig.exclude_spansis a parameter ofFastAPIInstrumentor.instrument_app; Litestar's instrumentor has no counterpart, so a shared fieldwould be inert for every bootstrapper but one.
opentelemetry_middleware_clsonFastStreamConfigis the same shape, and the issue anticipated this.
The default does not change
Empty, so all three spans are recorded exactly as today.
["receive", "send"]is measurably cheaper— the issue benchmarked 33 µs/request, a quarter of the instrument's cost — but it removes two
thirds of the spans from an existing service's trace view. That is a knob to document, not a default
to impose in a library upgrade.
Passed unconditionally, like the sampler in #222:
[]andNoneare identical downstream, wherethe ASGI middleware reads
"receive" in exclude_spans if exclude_spans else False.No dependency change
exclude_spansexists at the declared floor. I checked the 0.49b0 wheel directly rather than theinstalled 0.65b0:
instrument_appcarries the parameter there too, solowest-directstays greenwithout a bump.
Tests
Two, following
test_faststream_opentelemetry_excluded_urls_in_built_set: they pin whatlite-bootstrap hands the instrumentor —
[]by default, and the configured value when set — ratherthan re-testing upstream's span output. An end-to-end assertion would have to reach the
process-global tracer provider, which is set-once and already owned by whichever test bootstrapped
first.
No ADR
An earlier revision of this branch carried one. It failed the bar in the
/domain-modelingskill:the placement is reversible (a field move plus the silent alias this repo already does for renames),
it is not surprising once the one-line comment at the field says why, and the trade-off is thin
since Litestar having no counterpart nearly forces it. The comment and the docs bullet carry what a
reader needs.