Feature Request: Add option to map array attributes into multiple tags with the same key

[squah-confluent]

OpenTelemetry supports array-valued attributes. When a metric with an array-valued attribute is exported to Datadog, the array is JSON-encoded here, then the tag rules in the Datadog documentation are applied.

Thus, an array-valued attribute like key=["value1", "value2"] gets turned into the tag key:_value1_value2, which is unintuitive and difficult to filter on. For some use cases (including mine), mapping array attributes into a tag for each element, such as key:value1 and key:value2, would be ideal and allow for more natural filtering within Datadog.

Could an option for this be added?

[mx-psi]

@squah-confluent Thanks for your issue! The current behavior is to map the value of attributes using the AsString() function, that gives a JSON-like serialization of attributes. Datadog is restrictive as to what characters are supported in tags, so what should be key:[value1,value2] ends up as key:_value1_value2 in Datadog.

Using the same key multiple times may lead to confusing behavior in the Datadog app. Additionally, in the OpenTelemetry world, this is not supported (the same key must not appear twice), so I would also not recommend this approach if you want to remain vendor agnostic.

Are you using the OpenTelemetry Collector Datadog exporter? Or are you using the Datadog Agent instead? I can help propose an alternative solution if you give more information about your setup.

[squah-confluent]

@mx-psi Thanks, I understand using multiple tags with the same key isn't recommended.

I'm using the OpenTelemetry Collector with the Datadog exporter. I can't go into much detail about the metric itself. The tags come from another system which I have little control over and I'm trying to transfer them into Datadog faithfully. Most series have 0 or 1 instances of a tag and some have 2 or more. There's no ordering to the tag values and they're only intended to be used for filtering within Datadog. Some vendor lock-in is okay for this use case.

[mx-psi]

@squah-confluent Thanks for the details! One more question: do you only need this for metrics? Or is there a need for this in other telemetry signals?

[squah-confluent]

@mx-psi This particular use case involves metrics only. I've no need for this in other telemetry signals.

[mx-psi]

331 is the first step to add support for this