Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add expr language for logs and use it in filter processor #5680

Closed

Conversation

sumo-drosiek
Copy link
Member

@sumo-drosiek sumo-drosiek commented Oct 8, 2021

Description:

  • rename existing matcher to metric_matcher
  • add matcher for logs with support for Body (as string), Name, SeverityNumber ans SeverityText
  • use matcher in filterprocessor

Link to tracking Issue:
#5679

Testing:

  • unit tests

Documentation:

README

Dominik Rosiek added 2 commits October 11, 2021 12:38
Dominik Rosiek added 4 commits October 11, 2021 13:26
@sumo-drosiek sumo-drosiek marked this pull request as ready for review October 11, 2021 15:20
@sumo-drosiek sumo-drosiek requested review from a team and jpkrohling October 11, 2021 15:20
Dominik Rosiek added 2 commits October 11, 2021 20:20
Signed-off-by: Dominik Rosiek <[email protected]>
Signed-off-by: Dominik Rosiek <[email protected]>
@jpkrohling
Copy link
Member

Sorry for being slow in reviewing this. I plan on reviewing this tomorrow. Ping me again if I don't get it ready by then.

@sumo-drosiek
Copy link
Member Author

@jpkrohling pinging :)

Copy link
Member

@jpkrohling jpkrohling left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks very cool, I didn't know we had it for metrics already! I have only one question about the security considerations, and they might be documented already as part of the metrics part. There are also a couple of minor things to adjust, but overall, this LGTM!

processor/filterprocessor/README.md Outdated Show resolved Hide resolved
processor/filterprocessor/filter_processor_logs.go Outdated Show resolved Hide resolved
processor/filterprocessor/filter_processor_logs.go Outdated Show resolved Hide resolved
To ensure that everything is safe and secure:

- only basic types (like `string` instead of more complex log body) are being exposed
- expr has only access to a copy of object values
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible for an outside attacker to send a payload that would cause the collector to crash, perhaps as it would allocate much more memory than the payload itself? I guess not, but if there are any protections by the underlying library on this area, it would be good to mention here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't find answer in documentation. I believe @djaglowski should know more about expr language

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not very familiar with the internals of the dependency, but it appears there is some limit to the memory.

@jpkrohling jpkrohling added the ready to merge Code review completed; ready to merge by maintainers label Oct 19, 2021
Copy link
Member

@bogdandrutu bogdandrutu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general I like this approach, but @punya owes us the configuration for filtering that we should use for filter processors and for "transformation" processors.

@bogdandrutu bogdandrutu removed the ready to merge Code review completed; ready to merge by maintainers label Oct 19, 2021
@punya
Copy link
Member

punya commented Oct 21, 2021

@bogdandrutu I would like to take this as a starting point and commit to using it for filters and transforms as well. antonmedv/expr is general-purpose and can be applied there too.

@punya
Copy link
Member

punya commented Oct 25, 2021

@sumo-drosiek and @djaglowski, I created #5887 for the detailed evaluation. I'd love to work together on this - I'll reach out on Slack to find a time to kick off.

@github-actions
Copy link
Contributor

github-actions bot commented Nov 2, 2021

This PR was marked stale due to lack of activity. It will be closed in 7 days.

@github-actions github-actions bot added the Stale label Nov 2, 2021
@github-actions
Copy link
Contributor

github-actions bot commented Nov 9, 2021

Closed as inactive. Feel free to reopen if this PR is still being worked on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants