[receiver/filelog] Set instrumentation scope name and version

[TylerHelmuth]

Component(s)

receiver/filelog

Is your feature request related to a problem? Please describe.

I noticed today that the filelog receiver does not set an instrumentation scope name or version on the logs its scrapes.

Describe the solution you'd like

In my mind it would be appropriate for otelcol/filelogreceiver (following the mdatagen pattern) to be the name and the collector build version to be the version.

Describe alternatives you've considered

I recognize this may be on purpose since the log being scraped might provide a scope name/version based on the instrumentation that wrote the log.

Additional context

I noticed missing scope name/version in filelog receiver first, but basically all our receivers that are not using mdatagen but should have these fields are missing them. I'm opening this specific issue first, but it would probably be good to update scope name/version for all applicable receivers.

[github-actions]

Pinging code owners:

• receiver/filelog: @djaglowski

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

[djaglowski]

I am not convinced this is the desired functionality. The scope is meant to indicate the logger which emitted the log, not the machinery that read it from where it was emitted. This distinction is described in the semantic conventions here.

Additionally, the pkg/stanza operators include a scope name parser, which is intended to allow users to isolate the actual scope from logs, when present. (Though #23387 indicates this does not work as intended yet pending analysis of performance implications.)

[TylerHelmuth]

The scope is meant to indicate the logger which emitted the log, not the machinery that read it from where it was emitted. This distinction is described in the semantic conventions here.

Ok cool, I figured this was a possible outcome of the issue.

If the stance is that the the scope name/version should be settable from the log then I agree we should move forward with #23387 and close this issue.

[djaglowski]

Closing in favor of #23387