HTTP span name for unknown methods

[lmolkova]

HTTP spec currently requires to use http.request.method:

semantic-conventions/docs/http/http-spans.md

Lines 69 to 70 in 098db1c

	is not generally aware of the "route", and therefore HTTP client spans SHOULD use
	`{http.request.method}`.

For custom/unsupported methods, it means _OTHER, however user experience could arguably be better if span names represented the original method such as get or ACL, which are captured in http.request.method_original.

The argument for _OTHER is low cardinality, but it is not a clear requirement - open-telemetry/opentelemetry-specification#3534.

Span name is a part of stability guarantees

[trask]

The span name SHOULD be the most general string that identifies a (statistically) interesting class of Spans

If the unknown methods are valid, then each unknown method makes an interesting group of span names

but if the unknown methods are invalid (spam), then grouping them all together makes an interesting group of span names

[lmolkova]

users and backends can still group using http.request.method attribute.

I just imagine spans looking like _OTHER in the list of span names - the immediate thing I'd do is to open the span to find out what it actually is, but if I see ThIS is SPaM, I immediately know what it is. And from my perspective, span names goal is to provide a quick summary of what it is. EDIT: and _OTHER does not serve this purpose well

[Oberon00]

The span name's primary purpose is grouping. Low cardinality is more important than human-readability, that is what the spec says. A cardinality explosion in the span name is just as bad as in a metric attribute. See open-telemetry/opentelemetry-specification#557

Backends can (and probably should) generate a different display name based on attributes.

[lmolkova]

discussed at semconv SIG:

• low-ish cardinality in default experience is more important than user friendliness
• span name definition is not documenting this trade-off - it's tracked in Clarify cardinality requirements of a span name opentelemetry-specification#3534

So closing this one.

[Oberon00]

@lmolkova I think it could still make sense to define a special case for "_OTHER" like "HTTP _OTHER", but OTOH, the spans were previously named "HTTP <method>", which was removed in open-telemetry/opentelemetry-specification#3165 (personally, I thought the variant with "HTTP <method>" was better)

(EDIT: Markdown parser ate my angle brackets)

[trask]

I kind of like the span name HTTP for the case where we don't have a known http method

EDIT: I guess unknown http methods could still have a route, in which case HTTP {http.route}

A nice this about this naming is that those spans will be more identifiable in a U/X as HTTP, as opposed to only saying _OTHER

[joaopgrassi]

A nice this about this naming is that those spans will be more identifiable in a U/X as HTTP, as opposed to only saying _OTHER

But that is something a back-end can easily do as a UI-only tweak. For ex Jaeger does this already - The URL is shown together with the span name. I think other back-ends also do something similar OR can do if they want.

All to say I'm unsure if changing the spec to convey such UI feature makes sense.

[Oberon00]

But that is something a back-end can easily do as a UI-only tweak.

No. It would need to determine that the span name comes from HTTP conventions. These can be mixed with other conventions and often HTTP is not the primary one. So this is not easy even though it may be doable, at least heuristically.

All to say I'm unsure if changing the spec to convey such UI feature makes sense.

This is not (only) an UI feature. It also avoids potential name collisions where unrelated spans would then group together (when using span name). Especially _OTHER was IIRC agreed upon as a standard enum value, so it may turn up in other conventions as well.

[lmolkova]

updated #270 to use HTTP, PTAL