Opentelemetry-specification: Decide if semantic conventions require that attribute names across all areas should be unique

[tigrannajaryan]

We have semantic conventions for Resources, Spans and Metrics (in the future also Logs are expected). It is not clear if the attribute names across all convention areas should be globally unique.

Raised here https://github.com/open-telemetry/opentelemetry-specification/pull/807#discussion_r470836781

This needs to be resolved before GA since otherwise if there are any conflicts we won't be able to fix it in backward compatible manner.

[yurishkuro]

I would agree with that, because we need to target the lowest common denominator backends that do not make structural distinction between resource and span attributes. For example, in Zipkin span every attribute will be in a single flat list, while Jaeger span can structurally distinguish resource and span attributes (but not attributes from multiple/hierarchical resources, if we had them).

[jmacd]

I strongly support the proposal that attribute and label names should have the same interpretation across OpenTelemetry. I expect that finished Span will be translated into Metric events, for example, where (a subset of) span attributes become metric labels.

[gfuller1]

For the case where spans get converted to metric events, if you have http.status_code where it's stored as an integer on a span but metric labels don't support integers, we'd have to rename it since a string and an int aren't the same interpretation. In this case there doesn't seem like a clean way to rename the attribute. Something like http.status_code_str looks tacky and will most likely lead to confusion for users when querying.

What would you suggest for cases like this? I don't see a good way around it.

Context: #739

[tigrannajaryan]

@gfuller1 it is indeed a problem. A few possible solutions:

1. Allow non-string metric label values. Probably a no go since it complicates Metric API and OTLP (and I am not sure other metric protocols can support this).

2. Carve an exception in attribute-metric rules to allow the data type of the value to be different if the recording medium does not support a particular data type. In this case the _meaning_ of http.status_code label is still exactly the same as the meaning of http.status_code span attribute, but due to inability to record integer values we allow the string representation to be recorded in the metric label. The semantics remain the same. I think this is a reasonable exception but would like opinions about what can go wrong if we do this.

[gfuller1]

@tigrannajaryan for 1. I've heard that a lot of thought went into the decision for that around performance and other things so I agree that's a no go. For 2. I imagine querying backends could cause issues. If you want to see all events that have http.status_code=200 then without some complications it'll only return span events. Backends could do that conversion on their side but that would be a hassle to parse every string value of a label and check if it COULD be converted to a string. That's the main problem I can think of off the top of my head but I'm not in the ingest code at all so there might be other problems.

I'm curious what the benefits are to span attribute values being string or numeric.

[gfuller1]

I strongly support the proposal that attribute and label names should have the same interpretation across OpenTelemetry. I expect that finished Span will be translated into Metric events, for example, where (a subset of) span attributes become metric labels.

@jmacd how would you handle the above case for your scenario?

[tigrannajaryan]

I'm curious what the benefits are to span attribute values being string or numeric.

Numeric attributes would normally make sense if you want to do any sort of arithmetic, aggregation. Obviously that's pointless for HTTP status codes, but can be quite meaningfull for other attributes. I am open to changing http.status_code convention to be a string for Spans as well. Can't think of downsides at the moment.

[jkwatson]

for status codes, having a numeric value does let you find ranges (>= 200 AND < 300, for instance)

[tigrannajaryan]

@jkwatson that's a good point. Arguably that should also work with strings: >= "200" AND < "300" (all status codes are 3 digit so lexicographic ordering coincides with numeric ordering).

[jkwatson]

I wonder how many metric query engines support that kind of lexigraphic order querying?

[tigrannajaryan]

I wonder how many metric query engines support that kind of lexigraphic order querying?

Minor correction: not "metric engines" but "tracing engines" since we are discussing the possibility to change the data type of "http.status_code" _span_ attribute from integer to string.

Your question is still valid, but I don't think we need to worry about it. OpenTelemetry introduces so much that there is a lot of other opportunities to implement nice features for engine vendors anyway.

[jkwatson]

I wonder how many metric query engines support that kind of lexigraphic order querying?

Minor correction: not "metric engines" but "tracing engines" since we are discussing the possibility to change the data type of "http.status_code" _span_ attribute from integer to string.

Heh. I keep forgetting New Relic is probably unique in that it's the same query engine for both. :) You are correct, though!

[justinfoote]

I've recently made a proposal that has some overlap with this discussion: https://github.com/open-telemetry/opentelemetry-specification/issues/855

If we dictate something like this:

Identical namespaces or names in all these areas MUST have identical meanings.

I think it makes sense that there is a single canonical source for the meanings of names.