[chore] Propose additional attribute for 'otelcol.connector.produced.*' metrics

[djaglowski]

Without this attribute, it's not possible to accurately understand how data flows out of connectors.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.43%. Comparing base (0f5d764) to head (9e7ae77).
Report is 11 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main   #12815   +/-   ##
=======================================
  Coverage   91.43%   91.43%           
=======================================
  Files         487      487           
  Lines       26811    26811           
=======================================
  Hits        24514    24514           
  Misses       1814     1814           
  Partials      483      483           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mx-psi]

cc @open-telemetry/collector-approvers

I would consider this to be a minor change that does not need to go through the RFC process, but will wait to merge this a couple of days so people can disagree :)

[jade-guiton-dd]

Are otelcol.component.id + otelcol.signal + otelcol.signal.output not sufficient to identify which connector instance is involved, and thus which pipeline it is outputting to?

[djaglowski]

Are otelcol.component.id + otelcol.signal + otelcol.signal.output not sufficient to identify which connector instance is involved, and thus which pipeline it is outputting to?

These attributes are enough to identify the connector instance. However, connectors choose which pipeline(s) to send data to (e.g. routingconnector). Therefore, there is not a 1:1 relationship between data emitted by the connector and data consumed by the pipelines in which it acts as a receiver.

The reason I am proposing this as a data point attribute, as opposed to a scope attribute, is that the set of scope attributes can still provide a consistent identity for the connector instance.

[jade-guiton-dd]

I see, that makes sense. As long as we make it clear it's only an attribute on the pipeline metrics and not one we expect to have on all connector telemetry, that sounds good to me.

[djaglowski]

As long as we make it clear it's only an attribute on the pipeline metrics and not one we expect to have on all connector telemetry

I'm not sure what you mean by "pipeline metrics" but the proposal is to record the pipeline id as a data point attribute on the otelcol.connector.produced.* metrics.