[pkg/stanza] Improve error logs produced by transformer processors

[douglascamata]

Description

This improves the error messages of the log transformers processors to include the log file path and the original log record, effectively allowing users to quickly debug and investigate deeper the reason for the problem without having to use the debug exporter or using the highest verbosity level.

Here's an example of one of these failures:

2025-01-17T15:38:13.637Z error helper/transformer.go:114 Failed to process entry {"kind": "receiver", "name": "filelog", "data_type": "logs", "operator_id": "move5", "operator_type": "move", "log.file.path": "/var/log/pods/kube-system_kindnet-jxpz6_0784c9f9-ec2b-4829-aeb3-263ec66ef953/kindnet-cni/19.log", "entry.timestamp": "2025-01-17T15:38:07.645938111Z", "error": "move: field does not exist: attributes.uid", "action": "send"}

This log line could be even more helpful if the it included the regex pattern that was matched against the entry. I'm not sure about adding it now and it could be added in the future if desired.

A small note on the name of the log keys: they could have shorter names, like body and file_path but I think we could also use the attribute names from the semantic conventions for logs. I have no preference though and I'm happy to change it if needed.

Testing

• Ran it locally in a kind cluster.
• Some unit tests were updated to ensure the log.record.original key is present in the logs.

[douglascamata]

I have no idea about why this codeowners check is failing. I didn't touch the CODEOWNERS file and rebased with main a couple times.

[djaglowski]

I don't agree we should add the body. The body could contain sensitive information and is not necessarily the reason for the failure. Maybe the timestamp is enough?

[douglascamata]

I wanted to make the Collector's log useful enough so that we could avoid looking at the real log file.

I had totally overlooked the fact that the body can contain sensitive information. So I agree that we can't simply include it there. :/

Originally I wanted to include the line number of the entry, but because of the way the file scanning is working it got complicated (lots of wrapping of the scanner's splitfunc and some file position tracking is byte based instead of line based).

I think the timestamp will be a good substitute for now and I can try to get the line number working later. 👍

[douglascamata]

@djaglowski do you have some time to have another look at this, please?