mirror of
https://github.com/simonw/datasette.git
synced 2026-09-04 15:44:08 +02:00
f5eada266e
Nothing in Datasette created a span for the HTTP request itself, so every span the database layer emits was a root span. Measured on this branch: one faceted table page produces 70 spans in 36 separate traces, none of which carries a URL. A trace UI shows that as dozens of unrelated single-span traces per page, interleaved across concurrent requests - worse than ?_trace=1 at the exact job people reach for tracing to do. With the request span it is 71 spans in 1 trace. `opentelemetry-instrument` does not fix this on its own: auto-instrumentation only picks up frameworks that ship an instrumentor entry point, and Datasette's raw ASGI app is not one. TelemetryMiddleware is mounted outermost in Datasette.app(), after the asgi_wrapper() plugin loop, so plugin middleware and the CSRF layer run *inside* the span. Putting it in DatasetteRouter instead would leave a span created by an instrumented plugin as an orphan root - reintroducing the problem for exactly the code most likely to be instrumented. It stays at ~90 lines, against roughly 700 for opentelemetry-instrumentation-asgi, because Datasette's app does not return before its body is sent: route_path awaits response.asgi_send(send), and a streaming CSV export runs its generator inline inside AsgiStream.asgi_send. So a plain `finally` covers the response body and no deferred-end machinery is needed. Two decisions worth flagging for review: - Inbound W3C traceparent and baggage are extracted, using the *global* propagator. That is the ecosystem norm (Flask, Django, FastAPI, the ASGI instrumentation), and going through the global propagator leaves the operator in control with no Datasette setting to invent: OTEL_PROPAGATORS=none disables it entirely. A public instance that does not want client-influenced traces should strip those headers at the proxy. - url.query is not recorded, anywhere. Datasette query strings carry user-supplied SQL in ?sql= and canned query parameters. client.address is not recorded either. The status code is sniffed from the ASGI http.response.start message rather than read off a Response, because asgi_static, the favicon route, AsgiStream and AsgiFileDownload all send that message themselves and never build one. Only a >= 500 sets an error status - per semantic conventions a 4xx is the client's mistake, and Datasette 404s are routine enough that treating them as errors would bury a real 500. The registry gains a `dynamic` flag, because this span's name is composed at runtime and so can never equal a fixed registry string. Dynamic entries resolve by span kind instead, and only after exact and prefix matching has failed, so they cannot shadow a span that does have a registered name. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| _static | ||
| _templates | ||
| .gitignore | ||
| authentication.rst | ||
| auto-build.sh | ||
| binary_data.rst | ||
| changelog.rst | ||
| cli-reference.rst | ||
| codespell-ignore-words.txt | ||
| conf.py | ||
| configuration.rst | ||
| contributing.rst | ||
| csv_export.rst | ||
| custom_templates.rst | ||
| datasette-0.51.png | ||
| datasette-logo.svg | ||
| deploying.rst | ||
| ecosystem.rst | ||
| events.md | ||
| facets.rst | ||
| full_text_search.rst | ||
| getting_started.rst | ||
| index.rst | ||
| installation.rst | ||
| internals.rst | ||
| introspection.rst | ||
| javascript_plugins.rst | ||
| json_api.rst | ||
| json_api_doc.py | ||
| Makefile | ||
| metadata.rst | ||
| metadata_doc.py | ||
| pages.rst | ||
| performance.rst | ||
| plugin_hooks.rst | ||
| plugins.rst | ||
| publish.rst | ||
| settings.rst | ||
| spatialite.rst | ||
| sql_queries.rst | ||
| telemetry_doc.py | ||
| template_context.rst | ||
| template_context_doc.py | ||
| testing_plugins.rst | ||
| upgrade-1.0a20.md | ||
| upgrade_guide.md | ||
| writing_plugins.rst | ||
