[processor/datadog] Convert into a connector

[djaglowski]

Component(s)

processor/datadog

Describe the issue you're reporting

See open-telemetry/opentelemetry-collector#7370 for additional context.

This component would more naturally be a connector, as it emits data from one pipeline to another.

[github-actions]

Pinging code owners:

• processor/datadog: @mx-psi @gbbr @dineshg13

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

[github-actions]

This issue has been inactive for 60 days. It will be closed in 60 days if there is no activity. To ping code owners by adding a component label, see Adding Labels via Comments, or if you are unsure of which component this issue relates to, please ping @open-telemetry/collector-contrib-triagers. If this issue is still relevant, please ping the code owners or leave a comment explaining why it is still relevant. Otherwise, please close it.

Pinging code owners:

• processor/datadog: @mx-psi @gbbr @dineshg13

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

[mx-psi]

@djaglowski How should we name this connector? There is already an exporter and a receiver named datadog. With a quick test, I believe a configuration like this works as expected:

receivers:
  datadog:

exporters:
  datadog:
    api::key: ${env:DD_API_KEY}

connectors:
  datadog/connector:

service:
  pipelines:
    traces:
      receivers: [datadog]
      exporters: [datadog/connector]
    metrics:
      receivers: [datadog/connector]
      exporters: [datadog]

But we are unsure whether this would be too confusing for end users; the error if you drop /connector is:

Error: invalid configuration: connectors::datadog: there's already an exporter named "datadog"

Do we want to have connectors with the same ID as an existing exporter or receiver? Or should we discourage that?

[djaglowski]

Do we want to have connectors with the same ID as an existing exporter or receiver? Or should we discourage that?

We had to add a restriction here because otherwise exporters: [datadog] could be ambiguous. ie. You could be referring to either the datadog exporter or connector. So it's technically ok to have a connector with the same type as a receiver or exporter, but it's not allowed to have an instance of that connector that have the same id (type/name) as an instance of a receiver or exporter.

It's not ideal, but I think either we have to accept that users may run into this, or, that the connector type is not exactly the same as the receiver & exporter (e.g. define the connector as datadogstats)

[mx-psi]

IMO using the same type should be fine and make configuration slightly more concise in some cases if the error is a bit friendlier. For example, it could say something like this (we can eventually bikeshed about wording):

Error: invalid configuration: ambiguous id 'datadog': Found both 'datadog' exporter and 'datadog' connector.
Add a suffix to one of the component's names to eliminate ambiguity (e.g. rename 'datadog' connector to 'datadog/connector')

Do we have all the information we need to build such an error message? Would that be okay with you if we contribute it upstream?

[djaglowski]

That sounds good to me. I agree the message could be friendlier. We have all the info right here.