Consistent allowed attribute types

[Oberon00]

We currently have key-value pairs at different places:

1. Span attributes
2. Span link attributes
3. Span event attributes
4. Resource attributes
5. Metric labels

2 and 3 reference 1 (although IMHO that could be spelled out more clearly) and are thus always in sync. Resources currently have the following differences:

• Instead of numeric values, they allow double and int64 (cf. Vague spec: Span attributes may be "numeric" #425)
• They were not updated to allow arrays (cf. Allow array values for attributes #368)

IMHO, we should change the spec here to also reference Span's definition of attributes (first use case for arrays that comes to mind: List of a host's IP addresses or host names).

I couldn't find any specification at all on what a metric label value can be on master (but haven't looked in any PR). Clearly, there needs to be some specification here (probably not allowing array values).

Related: #76 "API: Consistent tag/attribute/field/resource namespacing and structure".

[arminru]

related: @jmacd's issue #387 about restricting metric and label names

[bogdandrutu]

@Oberon00 I am not sure exactly what is required to "fix" this issue, can you summarize?

[Oberon00]

I think we should split attributes in their own api-attributes document and reference them in all the other places (probably only allowing primitive types for metric label values). Coincidentally, this is also how opentelemetry-proto is currently implemented.

[jmacd]

My opinion is that all of the attributes in OpenTelemetry should have the same type and structure. I can't see any reasons why any key:value might not appear as any one of the above five kinds of attribute (span attribute, span link attribute, span event attribute, resource, metric) or as a Correlation Context value. Semantically, I believe there is no difference between using a resource as compared with a span attribute. Likewise, it means the same thing if an attribute appears in a metric label set or as a resource.

For example, a hostname attribute is commonly applied as a resource, but a proxy that forwards data from multiple hosts might attach it as a span attribute or a metric label.

There is a concern, I'm aware, that some attribute value types are not commonly accepted in some systems. For example, metric systems typically accept label values in string form. All values have a canonical translation to a string format, and I believe we should specify that this as the standard behavior for coercing attributes into export formats. If an export format does not support null-valued or number-valued labels, then those values should be converted to a string for export. Likewise, if an export format does not support multi-valued list attributes, those values should be coerced to comma-separated values in the exporter.

[bogdandrutu]

So we have 1-4 all using and referring to the properties as attributes. I think Metrics calls the properties "labels" and not attributes so it is clear that it is a distinction, more than that all systems that I know of use string only values). Also Correlation context as defined in w3c supports only string values.

So we still have two groups: one that supports all attributes values and one that only supports string.

[Oberon00]

"Also Correlation context as defined in w3c supports only string values"
We could still add encoding on top of the correlation context I suppose. But I agree that's an argument.

[bogdandrutu]

Closing this since I think we resolved the issue: resource, events, links, span use attributes; metrics use labels;

[Oberon00]

That may be how the spec is understood and implemented today, but not what it says. Resources still have their own definition for allowed values and do not reference the definition of Attributes that is in the span API (where it probably shouldn't be if it is to be shared). See https://github.com/open-telemetry/opentelemetry-specification/blob/master/specification/resource/sdk.md#create

[Oberon00]

Maybe this just needs a small cleanup PR and not much discussion, but it is still unsolved in the current specification text.

[jmacd]

It would be great if we could stop thinking labels and attributes as different things. When a span is used to construct a metric, we're going to convert attributes into labels and -- they're the same thing.