You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The new Pipeline Component Telemetry RFC defines a set of attributes that should be used to describe which component instance a telemetry item comes from.
At the moment, the receiverhelper emits the receiver's component ID as a receiver attribute on metrics and as part of the span name for traces. To bring this in line with the RFC, we would need to add the following attributes to metrics and spans:
otelcol.component.kind: always receiver
otelcol.component.id: the component ID
otelcol.signal: logs, metrics, traces, profiles
(As mentioned in the RFC, otelcol.signal is not mandatory for singleton receivers, but adding it in all cases should be fine.)
All this information should already be available in the helper, but instead of implementing the attributes manually, I would recommend waiting to see if the pipeline telemetry implementation introduces a general mechanism for getting these attributes.
This would be a step towards the stabilization of the otlpreceiver: cf. #11139.
The text was updated successfully, but these errors were encountered:
The new Pipeline Component Telemetry RFC defines a set of attributes that should be used to describe which component instance a telemetry item comes from.
At the moment, the
receiverhelper
emits the receiver's component ID as areceiver
attribute on metrics and as part of the span name for traces. To bring this in line with the RFC, we would need to add the following attributes to metrics and spans:otelcol.component.kind
: alwaysreceiver
otelcol.component.id
: the component IDotelcol.signal
:logs
,metrics
,traces
,profiles
(As mentioned in the RFC,
otelcol.signal
is not mandatory for singleton receivers, but adding it in all cases should be fine.)All this information should already be available in the helper, but instead of implementing the attributes manually, I would recommend waiting to see if the pipeline telemetry implementation introduces a general mechanism for getting these attributes.
This would be a step towards the stabilization of the otlpreceiver: cf. #11139.
The text was updated successfully, but these errors were encountered: