filterprocessor: fix filtering non-string body by bodies property

[sumo-drosiek]

Description:

Convert body to string before filtering

Link to tracking Issue: #22736

Testing: Unit tests

Documentation: N/A

[TylerHelmuth]

Thank you for bringing this to our attention.

With #18642 in the works I really really don't want to make changes to filterspan, filtermetric, or filterlog anymore. The ability to index body via OTTL has been introduced via #22102 and will be available in the next release of the collector to solve the problem this PR solves.

filter:
  logs:
    log_record:
    - 'IsMatch(body["some key"], "some value")'

I am willing to hear arguments as to why we should also patch this in filterlog, but blocking the PR for now.

[sumo-drosiek]

I am willing to hear arguments as to why we should also patch this in filterlog, but blocking the PR for now.

I wouldn't say this is the same. First of all, the current behavior of bodies is just wrong. We are rejecting all logs which aren't string. Also, the usecase is to have one common configuration for logs, where body may be both maps and strings (not sure if OTTL supports that).

With #18642 in the works I really really don't want to make changes to filterspan, filtermetric, or filterlog anymore. The ability to index body via OTTL has been introduced via #22102 and will be available in the next release of the collector to solve the problem this PR solves.

Totally understand, but raised it because IMHO it's bug in bodies behavior and should be either fixed or removed at all

[TylerHelmuth]

Also, the usecase is to have one common configuration for logs, where body may be both maps and strings (not sure if OTTL supports that

OTTL currently supports fetching the log as whatever type it is and with version 0.79.0 you'll be able to index it if it is a map or a slice. At the moment filterprocessor can take advantage of the OTTL filter interface, and soon all the other components using internal/filter will as well via #18642.

IMHO it's bug in bodies behavior

Agreed, but I feel the fix to the bug should be to get people off of this configuration and on to OTTL.

That said, only filterprocessor has the option to use the OTTL configuration, so it isn't a viable fix for attributesprocessor (the only other component using filterlog), so that is a reason to move forward with this PR.