Currently, if a user specifies multiple Beats receivers in the same OpenTelemetry Collector configuration, there is no way to differentiate which receiver ingested a particular document. Beats currently expose the service.name field, which reflects the name of the Beat that ingested the data. A similar field would make it easier to distinguish between documents ingested by standard Beats and those ingested via Beats receivers, as well as the receiver name in the pipeline.
The OpenTelemetry Collector logger provides several fields that can help differentiate log messages:
- otelcol.component.id – the name of the component, e.g.,
filebeatreceiver/1
- otelcol.component.kind – the kind of component; for Beats receivers, this is always
receiver
- otelcol.signal – the signal type; for Beats receivers, this is always
logs
I propose that we add these fields to the ingested documents. I believe otelcol.component.id is the most relevant here, but I’m open to including the others as well.
In order to avoid conflicting with existing fields from monitoring, the receivers will have these fields nested into the agent root object.
Reference: https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/rfcs/component-universal-telemetry.md#receivers
Currently, if a user specifies multiple Beats receivers in the same OpenTelemetry Collector configuration, there is no way to differentiate which receiver ingested a particular document. Beats currently expose the service.name field, which reflects the name of the Beat that ingested the data. A similar field would make it easier to distinguish between documents ingested by standard Beats and those ingested via Beats receivers, as well as the receiver name in the pipeline.
The OpenTelemetry Collector logger provides several fields that can help differentiate log messages:
filebeatreceiver/1receiverlogsI propose that we add these fields to the ingested documents. I believe
otelcol.component.idis the most relevant here, but I’m open to including the others as well.In order to avoid conflicting with existing fields from monitoring, the receivers will have these fields nested into the
agentroot object.Reference: https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/rfcs/component-universal-telemetry.md#receivers