[processor/attributes] Add support for profiles signal

[mx-psi]

Component(s)

processor/attributes

Describe the issue you're reporting

This processor would be useful for testing and validation of the experimental profiling signal.

As inspiration for how to add support this PR can be used: open-telemetry/opentelemetry-collector/pull/11071 (there is no processor with support as of the writing of this issue)

Example of configuration using profiles (needs service.profilesSupport feature gate to be enabled):

receivers:
  otlp:
    protocols:
      grpc:
exporters:
  otlp:
    endpoint: ${OTLP_ENDPOINT}
service:
  pipelines:
    profiles:
      receivers: [otlp]
      exporters: [otlp]

[github-actions]

Pinging code owners for processor/attributes: @boostchicken. See Adding Labels via Comments if you do not have permissions to add labels yourself.

[github-actions]

Pinging code owners:

• processor/attributes: @boostchicken

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[odubajDT]

Hi, if possible, I would like to look at this issue

[mx-psi]

@odubajDT Sure, go ahead! Profiles implementation may be a bit more complex since there are multiple places where there can be attributes. Feel free to ping me once you have the PR so we can find the right reviewers

[odubajDT]

After a brief investigation, there is a need to add support for profiles in pkg/ottl, therefore this issue depends on #36104

Additionally, support in internal/filter needs to be added as well, I will start working on this as part of my PR, but same for the processor, there is a dependency on pkg/ottl profiles support

[odubajDT]

/label internal/filter

[github-actions]

Pinging code owners for internal/filter: @open-telemetry/collector-approvers. See Adding Labels via Comments if you do not have permissions to add labels yourself.

[TylerHelmuth]

I want to throw out the idea that we don't add profile support to any component listed in #18643 and instead rely on profiles support in the transform processor.

[mx-psi]

I am okay with that, however there are changes coming to the profiles data model that may mean churn in the OTTL implementation. @dmathieu and the Profiling SIG can help inform what OTTL functions are 'safer' (in that we don't expect that part of the data model to change)

[dmathieu]

Seeing the number of changes currently being made in the OTLP for profiles, I think we can assume there won't be any "safe" location.

[mx-psi]

Then up to @TylerHelmuth to decide if they are willing to deal with the churn. We may also not do this and not do OTTL for now, focusing only on components that deal with the resource only/deal with the proto in an abstract way

[TylerHelmuth]

If the proto for profiles is churning, then pdata is churning, which means any attributes and OTTL will churn. It sounds like we should wait.

[dmathieu]

I agree to wait until the currently planned changes are shipped, after which I hope the profo should stabilize a little bit.
We shouldn't wait for them to be stable though, as that would prevent folks from experimenting with profiles, and make said stabilization rather harder.

[mx-psi]

Okay, let me put this on hold for now. @odubajDT see above, @dmathieu and the Profiling SIG will keep us updated when this can be marked as ready for review

[TylerHelmuth]

When we are ready to come back to this I do think we should only add support to the transformprocessor.