Skip to content

Conversation

@xgemx
Copy link

@xgemx xgemx commented Dec 9, 2025

In the base scenario open telemetry use scope.path as span.name param. But for endpoints with some id as a part of the route (for example /some/resource/123) there will be a span for every resource_id. First of all, that will be a problem for analytic of your spans. But the second one, it will garbage your span collector with unlimited span names. That's why this PR switch opentelemetry span names for litestar from /some/resource/123 to /some/resource/{resource_id}.

@lesnik512 lesnik512 requested review from insani7y and vrslev December 9, 2025 07:32
@vrslev
Copy link
Contributor

vrslev commented Dec 9, 2025

It would be nice to see some tests.

@vrslev
Copy link
Contributor

vrslev commented Dec 9, 2025

I think this kind of stuff should be done in Litestar itself though

@xgemx
Copy link
Author

xgemx commented Dec 22, 2025

I think this kind of stuff should be done in Litestar itself though

Looks like it is more OpenTelemetry staff like FastAPI or Django instrumentation. But there is no Litestar instrumentation for OpenTelemetry yet.

Also I'm not sure, that this is excellent span name builder for any Litestar user, looks like this is more our vision of right span names. Decision for everybody must be more flexible and generic and I have no time to implement it right now.

@vrslev
Copy link
Contributor

vrslev commented Dec 23, 2025

Method in span name is not compliant to the spec: open-telemetry/opentelemetry-python-contrib#3769

@vrslev
Copy link
Contributor

vrslev commented Dec 23, 2025

let's remove methods from span names, and merge)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants