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

Message filters: on deployment, job or origin #273

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from

Conversation

hoegaarden
Copy link

@hoegaarden hoegaarden commented Mar 8, 2021

Similar to #175 & #162 we'd like to filter some messages before we push them out to splunk.

We have a use-case where we only want to forward stuff from any p-healthwatch2-UUID deployment but not from p-heathwatch2-expoerter-UUID. With this "filter language" this is possible with something like

FILTERS='deployment:mustContain:-healthwatch2-;deployment:mustNotContain:-expoter-'

This allows us to deploy the same config on multiple foundations (with different deployment UUID for the same tile).

While for now we'd only need the filter on deployment, I took the opportunity to also implement it for job and origin, as these can be implemented in the very same way. Additional filters could be implemented by implementing more eventfilter.supportedGetters. Similar goes for the comparison functions: mustContain and mustNotContain are implemented, additional ones could be added by appending them to eventfilter.supportedFilters.

Benchmarks have been implemented, those can be seen by running make testv or ginkgo ./eventrouter/.... According to those benchmarks, discarding messages is super fast & a single filter does not seem to have much of a performance impact. Multiple filters, though, might get a bit heavy. (BTW: happy to implement a limit on the numbers of filters allowed).

If this get's accepted, I would also go forward and implement this in the tile.

cc: @rockb1017 @luckyj5 (because you cut the last releases)

@hoegaarden
Copy link
Author

I think I will change the "filter language" to something like

deployment:mustContain:p-healthwatch2;deployment:mustNotContain:exporter;origin:mustContain:something

and implement the available matchers similar as the supportedGetters are implemented, which should make it easier to expand in case we'd want that.

But still, any feedback, esp. if this generally has a chance to be merged, would be great!

@hoegaarden
Copy link
Author

PR & PR description updated to the change of the "filter language". Some internal refactoring should make it easier to add new filters / getters; implementation is now saner (I think 🤷🏽).

@JuergenSu
Copy link

We also ran into this situation where we only want certain deployments to be exposed via firehose nozzle so a change like this would help us a lot in not flodding splunk with informations not needed...

@hoegaarden
Copy link
Author

@rockb1017 @luckyj5 Can you please let me know if you'd consider merging that? Or point me to some other devs I could work with?

@luckyj5
Copy link
Collaborator

luckyj5 commented Jun 25, 2021

@hoegaarden Thanks for reaching out. I have added this item to our backlog and it will be considered for the future release of the nozzle (not scheduled yet). Will reach out if any additional information is needed. Thanks!

@luckyj5
Copy link
Collaborator

luckyj5 commented Jun 25, 2021

Also, can you please rebase this with develop branch?

@hoegaarden
Copy link
Author

@luckyj5 I have rebased my changes onto develop. Do you also want me to change the PR to go into develop instead of master?

@luckyj5
Copy link
Collaborator

luckyj5 commented Jun 29, 2021

@hoegaarden, Yes, please raise it against develop branch. Thank you!

@hoegaarden hoegaarden changed the base branch from master to develop July 1, 2021 08:03
@hoegaarden
Copy link
Author

hoegaarden commented Jul 1, 2021

@hoegaarden, Yes, please raise it against develop branch. Thank you!

@luckyj5 Done.

Let me know what you think about those changes!

This allows filtering of events based on the above mentioned fields.
Multiple filters can be configured and they will run against a message
in the order specified.

A filter has the form

  field₀:comperator₀:value₀;field₁:comperator₁:value₁;…;fieldₙ,comperatorₙ,valueₙ

`field` is the messages field to check against.
`comperator` is how to compate the `field`'s value to the user provided value ('mustContain', 'mustNotContain')
`value` is the value the user want's to check messages for

Benchmarks have been added to get an understanding of the performance
impact of those filters.
@hoegaarden
Copy link
Author

@harshit-splunk @kashyap-splunk @luckyj5 -- I saw that development has kicked in again. Please let me know if you'd consider merging my PR. Thanks.

@kashyap-splunk
Copy link
Collaborator

Sure, we will look into this as soon as we can and let you know.

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

Successfully merging this pull request may close these issues.

4 participants