Add ability to filter log records by body (maybe expr language)

[sumo-drosiek]

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

I want to filter in/out logs by specific body content

Describe the solution you'd like
I can see two solutions. All of them should be implemented in filterprocessor

• Simple solution: run regex against stringified (or only for string typed) body
• Complex solution: add support for expr language. This is already done for metrics

Describe alternatives you've considered
N/A

Additional context
N/A

[gillg]

It's a little bit related to that #4955

Today we can't work on body assuming it's a randomly structured or not data. But because attributes vs body usages are not always clear or respected we should at least have a way to work on it (or prevent bad usage in all receivers)

[sumo-drosiek]

In #5680 I use stringified body. I believe it's good starting point in terms of filtering. Also expr can be extended in the future to support structured body.

This is very unfortunate that there is no way to operate on Body right now

[pmalek-sumo]

Is there any work happening w.r.t to this issue?

Will changes in https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/transformprocessor be affecting https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/internal/coreinternal/processor/filterlog or other packages from internal which would allow us to provide the functionality that this issue describes (somewhat similar to what @sumo-drosiek had done in the above mentioned #5680) ?

Just to have a full picture here: this is doable in filelogreceiver's operators (specifically filter operator) but not in contrib's (or core's) processors, so users receiving log entries via different means (e.g. via fluentforwardreceiver) cannot filter logs in their pipelines.

cc: @djaglowski

[djaglowski]

I haven't found enough time to become very familiar with how we're approaching filtering in processors yet, but I'll point out a couple things that may help narrow the scope of what we need to support:

1. Somewhat recently, the logs data model was updated to specify that the body should be a string in all first party applications. Based on this, I think filtering capabilities should be primarily focus on the case where this is true.
2. Although, the body should be a string, it is not necessarily so. Therefore, even a simple solution should at least validate that the body is a string, rather than assume.

[github-actions]

Pinging code owners: @TylerHelmuth @kentquirk @bogdandrutu @evan-bradley. See Adding Labels via Comments if you do not have permissions to add labels yourself.

[TylerHelmuth]

I am currently working on an enhancement to the transform processor that will enable use to write a drop function that can use the OTTL's extensive condition framework, which allows access to the log's body.