resource attributes from container operator are not passed to downstream connector

[zeitlinger]

Component(s)

connector/otlpjson, receiver/filelog

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

With this setup

receivers:
  filelog/otlp-json-logs:
    include:
      - /var/log/pods/*/*/*.log
    include_file_path: true
    operators:
      - id: container-parser
        type: container

connectors:
  otlpjson:

exporters:
  debug:
    verbosity: detailed

service:
  pipelines:
    logs/raw_otlpjson:
      receivers: [ filelog/otlp-json-logs ]
      processors: [ ]
      exporters: [ otlpjson ]
    logs/otlp:
      receivers: [ otlpjson ]
      processors: [ ]
      exporters: [ debug ]

Describe the solution you'd like

The detected resource attributes from the container parser (e.g. k8s.container.name) should be added to the resource attributes of the log entries.

However, there is no way to propagate resource attributes from the file receiver to a connector IIUC.
See https://github.com/open-telemetry/opentelemetry-collector/blob/720f3a86a3de10bc679e3cb8f8f5de4b868455e6/service/internal/graph/graph.go#L296

Describe alternatives you've considered

No response

Additional context

No response

[github-actions]

Pinging code owners:

• connector/otlpjson: @djaglowski @ChrsMark
• receiver/filelog: @djaglowski

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

[ChrsMark]

I think that's a known generic "limitation" of this connector. Right now the connector just extracts the otlpjson from the log records' body and forwards it to the next metrics'/traces'/logs' consumer accordingly. So any attributes or resource attributes of the original log record are discarded.

We could probably provide the option to keep the original resource attributes as well but that should be optional because that assumption might not apply to every use-case.

[zeitlinger]

We could probably provide the option to keep the original resource attributes as well but that should be optional because that assumption might not apply to every use-case.

yes, that would be great

can you provide a hint how this option could be implemented?