Instrumentation scope is not set for stanza based receivers

[rogercoll]

Component(s)

receiver/filelog, receiver/journald, receiver/syslog, receiver/otlpjsonfile

What happened?

Description

Instrumentation Scope OpenTelemetry log record field is not set for receivers that are created using Stanza's internal package. This field is very useful when configuring routing pipelines based on the receiver name/type.

Steps to Reproduce (Linux)

$ make otelcontribcol
$ ./bin/otelcontribcol_linux_amd64 --config filelog.yaml 2>&1 | grep InstrumentationScope

(write some logs, e.g: echo "hii" >> /tmp/hello.log)

Expected Result

InstrumentationScope  github.com/open-telemetry/opentelemetry-collector-contrib/receiver/filelog 0.117.0-dev
InstrumentationScope  github.com/open-telemetry/opentelemetry-collector-contrib/receiver/filelog 0.117.0-dev
InstrumentationScope  github.com/open-telemetry/opentelemetry-collector-contrib/receiver/filelog 0.117.0-dev

Actual Result

InstrumentationScope
InstrumentationScope
InstrumentationScope

Collector version

v0.117.0, 1b93d01

Environment information

Environment

OS: Arch
Compiler: go1.23.4

OpenTelemetry Collector configuration

receivers:
  filelog:
    include:
      - /tmp/hello.log
processors:
  batch:
exporters:
  debug/vvv:
    verbosity: detailed
service:
  pipelines:
    logs:
      receivers: [filelog]
      processors: [batch]
      exporters: [debug/vvv]

Log output

Additional context

No response

[github-actions]

Pinging code owners:

• receiver/filelog: @djaglowski
• receiver/journald: @sumo-drosiek @djaglowski
• receiver/syslog: @djaglowski @andrzej-stencel
• receiver/otlpjsonfile: @djaglowski @atoulme

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

[bacherfl]

@djaglowski Would it make sense to extend the InputConfig in stanza to include an instrumentation scope? Since TelemetrySettings that are passed to the build the InputConfig contain the name and version of the collector, this could be relatively easy to add here.
The Entry in stanza already contains a ScopeName which could then be set by the NewEntry method of the InputConfig - maybe we could also add a ScopeVersion to that struct.

If this is a valid approach, I can look into providing a PR for this

[djaglowski]

I don't necessarily agree that the receiver should be represented as the instrumentation scope, just as the collector is not the resource which generated the log.

The instrumentation scope is intended to describe the portion of code which emitted the log, which is in some other service. This is why we have a scope parser, so users can assign the instrumentation scope based on the content of the log. (e.g. a logger name)

[bacherfl]

Thank you for the response @djaglowski! should we in this case close this issue, as the scope parser is the recommended way of providing the instrumentation scope?

[rogercoll]

I don't necessarily agree that the receiver should be represented as the instrumentation scope, just as the collector is not the resource which generated the log.

I would say that not the raw log but the processed (attributes, parsed timestamp), summarized, or transformed (pLog) version of it (telemetry).

The instrumentation scope is intended to describe the portion of code which emitted the log, which is in some other service.

Do you mean the entity that generated the raw log (e.g. nginx app)? IMO the raw log is different from the one processed and emitted by the receiver (e.g. data model). To describe the resource (logger name) that generated the log, I would opt for using resource attributes.