[chore]: datadog receiver: Tags translation #33922
Conversation
jesusvazquez
changed the title
jesusvazquez
force-pushed
the
jvp/datadog-receiver-tags-translation
branch
2 times, most recently
from
ff93214
to
37f9b03
Compare
Signed-off-by: Jesus Vazquez <jesus.vazquez@grafana.com>
jesusvazquez
force-pushed
the
jvp/datadog-receiver-tags-translation
branch
from
37f9b03
to
e114373
Compare
| // to only support key:value pairs. | ||
| // The following is a workaround to map unnamed inputTags to key:value pairs and its subject to future | ||
| // changes if OTel supports unnamed inputTags in the future or if there is a better way to do this. | ||
| key = fmt.Sprintf("unnamed_%s", tag) |
There was a problem hiding this comment.
is this common practice elsewhere as well? As a user that tagged something with "foo", I'd probably expect to see it translated to foo=foo or foo=true, or even just "foo=" (empty value).
There was a problem hiding this comment.
The problem doing that is that perhaps there was already a label name called foo?
Because we don't know in advance, I thought about prefixing the label with something that is not common, such as unnamed_.
I particularly don't make use of unnamed tags so I wonder what would be the best approach here too. We can always change it when some users try it out.
There was a problem hiding this comment.
The problem with changing it later is that we'd break users who start depending on the behavior introduced on this PR here. I don't have a good solution for the moment, and I think it would be OK to add a note to the readme stating that it currently is "unnamed_" and might change later, and that the appropriate solution is to perhaps be more explicit (foo:foo, foo:, :foo, foo:true).
There was a problem hiding this comment.
This change to the readme can be done on a subsequent PR. I'm merging this.
**Description:** This PR adds support for V1 series, as well as batches the metrics by resource, scope, and datapoint attributes. The batching code will also be required for future PRs which will add support for v2 series endpoints, service checks, and sketches. Follow up of #33631 and #33922. The full version of the code can be found in the `cedwards/datadog-metrics-receiver-full` branch, or in Grafana Alloy: https://github.com/grafana/alloy/tree/main/internal/etc/datadogreceiver **Link to tracking Issue:** #18278 **Testing:** Unit tests, as well as an end-to-end test, have been added. --------- Co-authored-by: Federico Torres <federico.sa.torres@gmail.com>
Description:
This PR is a follow up to the former #33631 extending the existing tags translation structure. This will be required for the follow up PRs adding support for v1 and v2 series endpoints, service checks, as well as sketches.
The full version of the code can be found in the cedwards/datadog-metrics-receiver-full branch, or in Grafana Alloy: https://github.com/grafana/alloy/tree/main/internal/etc/datadogreceiver
Link to tracking Issue:
#18278
Testing:
Unit tests have been added. More thorough tests will be included in follow-up PRs as the remaining functionality is added.
Notes:
[chore]to the title of the PR because https://github.com/grafana/opentelemetry-collector-contrib/blob/ab4d726aaaa07aad702ff3b312a8e261f2b38021/.chloggen/datadogreceiver_metrics.yaml#L1-L27 already exists.