Opentelemetry-js: High-cardinality HTTP span names

Created on 24 Mar 2020  路  10Comments  路  Source: open-telemetry/opentelemetry-js

The spans are GET /the/path/123 which are high-cardinality.

Instead, I suggest http.request:GET.

required-for-ga up-for-grabs

Most helpful comment

That is the core issue at question in this issue https://github.com/open-telemetry/opentelemetry-specification/issues/468

It seems like they're leaning towards keeping updateName but with a different name.

All 10 comments

Spec states http spans specifically should be named after the method (GET, POST, etc) if the route name is not available. https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/data-http.md#name

Correct me if I am wrong but I'm under the impression that high cardinality is the point of tracing data?

Names are not meant to uniquely identify a trace, but a class of traces. for instance, GET /user/:id is a good name, but GET /user/123 is bad because you can't easily search for all traces for the same route. @pauldraper's argument is that if you don't have enough information to get the route name, you should just use http GET rather than using the full URL.

@dyladan Using the route would require to the modify the span after it has been created (inside the express plugin for example).Correct me if i'm wrong but i believe there are no way to do that right now ?

That is the core issue at question in this issue https://github.com/open-telemetry/opentelemetry-specification/issues/468

It seems like they're leaning towards keeping updateName but with a different name.

I'm interested in picking up this issue, but just wanted to clarify the solution.

I think the change is going to be in the framework plugins (eg express/koa/hapi), having it call updateName on the parent span when it has the route name available.

Also, if that is correct and the change will be in the opentelemetry-js-contrib repo, should this issue be closed or moved over to that repo?

@gecgooden There are some code on the http plugin that should be removed too

Any progress on this? This is critical issue imho.
Are there any suggestions for implementation? Maybe add an option to disable adding path in the span name?

Spec says

Instrumentation MUST NOT default to using URI path as span name

Assigning @morigs because he opened the PR

Was this page helpful?
0 / 5 - 0 ratings