If you run Starlette or FastAPI in production with an APM tool, you should keep an eye on PR #3438. It adds native OpenTelemetry HTTP server spans directly into the framework. No external instrumentor, no monkeypatching. Just spans emitted from the router itself.
At Scout Monitoring, we instrument Starlette and FastAPI through our Python agent. A change like this touches how every APM tool in the Python ecosystem works with these frameworks, ours included.
What the PR Does
The PR, authored by Marcelo Trylesinski (Kludex), adds OpenTelemetry HTTP server span creation to Starlette’s request lifecycle. When a tracer provider is configured, Starlette will create spans for each request using the global tracer provider. If no provider exists (or if opentelemetry-api isn’t installed), the framework behaves exactly as it does today.
- Route templates come from actual dispatch. The spans include the matched route template from Starlette’s router, including mounts and host-based routing. External instrumentors typically reconstruct this through middleware wrapping, and they often get it wrong.
opentelemetry-apiis an optional dependency. If you don’t install it, nothing changes. Starlette checks for it at runtime and skips span creation if the package isn’t there.- Zero-touch Logfire setup. The PR documents that calling
logfire.configure()is enough to start tracing. No Starlette-specific configuration required.
The test suite passes: 1,048 tests, 100% statement and branch coverage.
Why This Matters for APM Users
Most Python APM tools, Scout included, instrument Starlette by wrapping its middleware stack or patching internal methods. This is how we capture request timing, route information, and error data. It works, but it means the APM agent and the framework are doing separate work to produce similar information.
When a framework starts emitting its own OpenTelemetry spans, three things can happen:
Duplicate spans. If your APM agent creates a span for an incoming HTTP request and Starlette also creates one, you end up with two spans representing the same work. Depending on how your tool processes traces, this can show up as inflated request counts or confusing trace waterfalls.
Conflicting span attributes. APM agents and the framework may set different values for the same span attributes. Route template names are a common source of disagreement, especially with mounted sub-applications or path parameters.
An opportunity to simplify. The optimistic case: APM tools can consume the framework’s native spans instead of wrapping everything themselves. That’d mean more accurate route templates (the framework knows its own routing better than any external observer) and less surface area for instrumentation bugs.
What This Means for Scout Users
This PR isn’t merged yet. It’s an open pull request, so nothing changes in Starlette today. But if it lands in a release, here’s what we’re thinking about:
Our Python agent instruments Starlette and FastAPI by wrapping middleware and request handlers. We capture route names, request timing, database queries, and errors across the full request lifecycle. Native OTel spans from Starlette would overlap with part of that work, mainly the HTTP server span and route identification.
We’re tracking this PR and will test against it once it ships. The goal is to make sure Scout’s instrumentation works correctly whether or not Starlette is emitting its own spans. If the native spans turn out to be reliable and complete, there’s a path toward consuming them directly and cutting down on the wrapping our agent needs to do.
For now, no action is needed on your end. Your Scout agent will continue working the same way it does today. When Starlette ships this change, we’ll validate compatibility and update the agent if needed.
The Bigger Picture for Python Web Frameworks
This PR is part of a broader trend. Frameworks are starting to own their observability story instead of leaving it all to external tools. Django has had similar discussions. FastAPI already benefits from any Starlette-level instrumentation since it’s built on top of Starlette.
For developers, that means fewer “install this instrumentor package and configure this middleware” steps when setting up tracing. For APM vendors like us, it means learning to consume framework telemetry instead of only producing our own.
This is a good direction for the ecosystem. Frameworks know their own internals best. When they produce that data as standard OpenTelemetry spans, every observability tool gets more accurate information.
Try Scout Monitoring
We instrument Starlette, FastAPI, Django, Flask, and more. If you need application monitoring for your Python stack, Scout Monitoring is the fastest path to useful information without the bloat. Start your free trial.