-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[attributesprocessor] Support filter by severity #9132
Conversation
09276d0
to
b18780d
Compare
I think the change looks good overall. I think before merging it would be good taking the item raised by @djaglowski, i.e. if we want to have separate filter for log severity number and if that's the case then how the configuration keys should be named for them. As a digression, I think that while having ability to filter records when attributes processor is concerned is helpful, it would be even more useful to have similiar capabilities exposed in filterprocessor as well |
@pmm-sumo would you be awesome and file an issue for the digression? That sounds like a good move. Agree on your comments folks, will make the filter's name more clear. The problem with severity number fwiw is that you'd be well tempted to use a |
+1, This processor is is filtering on several non-attributes at this point. |
b7ab705
to
742853c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The change looks good to me. @djaglowski @pmm-sumo please review and approve if your comments have been addressed.
Sure thing: #9235
I think that filtering by severity text is already pretty useful, don't want to block this PR due to lack of filtering by number but I wanted to hear from @djaglowski on his take on that :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay. LGTM
Tangentially related, when should new capabilities be added to the attribute processor vs the transform processor? |
That's a good question. In my opinion it's OK to add small features here that users want and then port those to transform processor after it's considered ready to be used There is a PR that adds some log processing capabilities. This makes it already quite useful IMO |
Description:
Adds a severity text matcher for the attributesprocessor.
Link to tracking Issue:
No issue.
Testing:
Unit tests
Documentation:
README and configuration