Use the request's uri as operation name for Span objects.

[carlosalberto]

Proposal for the uri as operation name ;)

[jakerobb]

Thanks! I've been meaning to submit an issue for this. I think it would be better to provide an interface and a default implementation for determining an operation name. In the Zipkin world, this is what Brave does (see https://github.com/openzipkin/brave/blob/master/brave-http/src/main/java/com/github/kristofa/brave/http/DefaultSpanNameProvider.java and related).

My personal preference for HTTP calls is to provide method + the path portion of the URI, e.g. "GET /users/123".

[sjoerdtalsma]

@jakerobb Surely /users/123 should be reduced to either something like /users/{id} or get_user?

From https://github.com/opentracing/specification/blob/master/specification.md#tracer:

An operation name, a human-readable string which concisely represents the work done by the Span (for example, an RPC method name, a function name, or the name of a subtask or stage within a larger computation). The operation name should be the most general string that identifies a (statistically) interesting class of Span instances. That is, "get_user" is better than "get_user/314159".

[objectiser]

This issue is being more generally discussed here: https://github.com/opentracing-contrib/meta/issues/25

Would be good to add any suggestions there, so they can be applied to all relevant framework integrations.

[pavolloffay]

@tedsuo can this be closed?

[tedsuo]

Yes, closing as URI's turn out to be bad for operation names.