Profiles: Clarify what types can be used in attributes

[aalexand]

AnyValue is defined today to be able to contain the following types:

  oneof value {
    string string_value = 1;
    bool bool_value = 2;
    int64 int_value = 3;
    double double_value = 4;
    ArrayValue array_value = 5;
    KeyValueList kvlist_value = 6;
    bytes bytes_value = 7;
  }

which is basically capable of carrying a recursive JSON/XML-like data structure.

At the same time, this spec defines attributes as

An Attribute is a key-value pair, which MUST have the following properties:

• The attribute key MUST be a non-null and non-empty string.
  • Case sensitivity of keys is preserved. Keys that differ in casing are treated as distinct keys.
• The attribute value 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.

But a recent OTEP 4485 talks about extending this to complex types.

We should clarify what attribute value types we want to support in profiling 1.0 release.

With the dictionary approach we use, producing a profile and performing common operations on it like merge requires dealing with uniqueness-by-value for attributes and doing that for complex types has nuances:

• Handling the equality or hashing for complex type is more complicated. For example, a variant type that supports a few primitive types can be a simple struct in Go that can be used as a key in a map. With a complex hierarchical type this needs to involve string serialization or some sort of hash digest.
• We'll need to define what differences are significant vs not. For example, the OTEP mentions that the order of keys in the Keyvalue type of Any is not significant, this would need to be handled.

Also note that #683 adds limitations for types for certain attributes already.

@open-telemetry/profiling-maintainers @jsuereth

[felixge]

Thanks for raising this.

Given that we use dictionary aka CAS approach to store attributes

Our dictionary doesn't use hashes for the keys, so I don't think it classifies as CAS?

supporting arbitrarily recursive types can be inefficient and complex.

Can you elaborate? I'm assuming you're talking about the inefficiencies of storing two deeply nested AnyValue's that are mostly similar?

[aalexand]

Thanks for raising this.

Given that we use dictionary aka CAS approach to store attributes

Our dictionary doesn't use hashes for the keys, so I don't think it classifies as CAS?

supporting arbitrarily recursive types can be inefficient and complex.

Can you elaborate? I'm assuming you're talking about the inefficiencies of storing two deeply nested AnyValue's that are mostly similar?

I rewrote that paragraph to hopefully clarify both points. I removed the CAS reference, this was a distraction.