Consistent transform of attribute values

There has been some recent discussion about how to handle the differences in what the .NET APIs allows as attribute values and what is declared in the OpenTelemetry specification. Opening this issue to continue the discussion. (#1966, #1973)

The specification states that an attribute values is either:

• A primitive type: string, boolean, double precision floating point (IEEE 754-1985) or signed 64 bit integer.
• An array of primitive type values. The array MUST be homogeneous, i.e. it MUST NOT contain values of different types. For protocols that do not natively support array values such values SHOULD be represented as JSON strings.

The API for setting a tag on a .NET Activity is broader in scope than what the OpenTelemetry specification requires. A tag’s value can be any type.

public System.Diagnostics.Activity SetTag (string key, object? value);

Currently, the exporters in this project convert tag values to a string, boolean, double, or int64 - or an array of these - as appropriate.

I propose we continue to embrace the flexibility of the .NET Activity API and ensure that we are consistently converting all C# built-in types to the most appropriate type declared in the OpenTelemetry specification as follows:

• All numeric types which would not be truncated should be converted to a double or int64 value.
  • Examples: short, int, long, float, double
• All numeric types which may be truncated if converted to a double or int64 should be converted to a string.
  • Examples: decimal, ulong
• A bool is a bool
• All other types would be converted to a string.

For the most part, I think this is pretty close to what the exporters already do, but there are a few open questions:

1. There exist numeric built-in types that are currently converted to a string
   • byte, sbyte, ushort, uint
2. Arrays of built-in types should work
   • Currently a byte[], char[], or decimal[], for example, are converted to the string System.Byte[] and System.Char[], and System.Decimal[].
3. ToString can be perilous. Should we be concerned?
   • ToString on an arbitrary type could result in an exception (or worse a deadlock… I’ve actually seen this). Currently, I think our exporters would throw away an entire batch if an exception were thrown when transforming an attribute value. Should we be more defensive here and discard attributes that cannot be transformed?

[alanwest]

This needs some more clarification though. E.g. if you interpreted the OTel spec very strictly, then int values (32 bit in .NET) are not valid, only long. And what about unsigned?

Given that the .NET API is not strict (allows object-typed tag values), I’d like us to settle on a happy medium ground between a strict read of the spec and handling what we think will be commonly used datatypes that are also easy to handle.

[cijothomas]

I think handling just array keeps things simple.

+1 to this