-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
[Filebeat] Check if processor is supported by ES version #23763
[Filebeat] Check if processor is supported by ES version #23763
Conversation
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
Pinging @elastic/integrations (Team:Integrations) |
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.
Is there a good reason to put this validation into beats? Or said another way, why not rely on the errors coming back from Elasticsearch?
If we cannot do anything to fix the errors then I don't see a lot value from maintaining a list of the supported ES versions for particular processors.
It's because the beat will fail to install the pipeline on older versions if a single processor does not exist on that ES version. The reason this is implemented is to instead of failing it will remove the unsupported processors to allow the pipelines to be installed. I don't see any other place we can add this check than beats @andrewkroh ? |
I got confused by the method name, sorry, I skimmed it and thought it was just returning an error ("check" which is passive) whereas it's filtering incompatible processors. |
No worries! The idea is to iterate over the list of processors and remove the processors that needs a version higher than the current ES version. Since this is a slice I would need to create a new list of processors and overwrite the current one with the new one (called |
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
It makes sense for processors that can degrade gracefully without affecting the rest of the pipeline. But the result could be confusing:
So I'm a little worried that feature like this could make working with pipelines and debugging problems harder. Having a hard failure based on ES version might be simpler to reason about because it's an invariant. But of course this has trade-offs with out-of-box usability. |
I think that the pipelines that wants to use new processors should only do so if the pipelines can fully work without them. In the case of uri_parts processor there should be a simple fallback to handle urls as we would usually do in the older versions. The points you mention above is certainly valid, but we are already doing this for processor arguments/options in the same file that this PR modifies, and I feel that we either have to not use any new processors before 8.x or use something like this as a middleground. Users that are upgrading ES/beats would have needed to reinstall their pipeline to get updates either way right? |
Pinging @elastic/agent (Team:Agent) |
These should have been require.NoError otherwise panics occur.
Errors should not begin with capitals. Avoid double logging errors (both logging and returning them). Fix usage of deprecated logp functions. Remove unused code (ML module). Removed unneeded import alias. Avoid allocating empty slices. Add missing error check for config Unpack.
* adding possibility to remove processor if its unsupported * removing unused function while testing * was initially testing with a separate function, removed that for now * moving it to its own function * rewriting SetProcessors logic to be more extendable * added testcases for uri parts * stashing changes * Fix assert.NoError usages These should have been require.NoError otherwise panics occur. * Package cleanup Errors should not begin with capitals. Avoid double logging errors (both logging and returning them). Fix usage of deprecated logp functions. Remove unused code (ML module). Removed unneeded import alias. Avoid allocating empty slices. Add missing error check for config Unpack. * Add changelog Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co> (cherry picked from commit 9dbfd44)
… by ES version (#24044) * [Filebeat] Check if processor is supported by ES version (#23763) * adding possibility to remove processor if its unsupported * removing unused function while testing * was initially testing with a separate function, removed that for now * moving it to its own function * rewriting SetProcessors logic to be more extendable * added testcases for uri parts * stashing changes * Fix assert.NoError usages These should have been require.NoError otherwise panics occur. * Package cleanup Errors should not begin with capitals. Avoid double logging errors (both logging and returning them). Fix usage of deprecated logp functions. Remove unused code (ML module). Removed unneeded import alias. Avoid allocating empty slices. Add missing error check for config Unpack. * Add changelog Co-authored-by: Andrew Kroh <andrew.kroh@elastic.co> (cherry picked from commit 9dbfd44) * Update CHANGELOG.next.asciidoc * adding missing variable declaration and mage fmt update
…-arm * upstream/master: [Metricbeat][Kubernetes] Extend state_node with more conditions (elastic#23905) [CI] googleStorageUploadExt step (elastic#24048) Check fields are documented for aws metricsets (elastic#23887) Update go-concert to 0.1.0 (elastic#23770) [Libbeat][New Processor] XML Decode (elastic#23678) Fix: bad substitution of API key (elastic#24036) [Filebeat] Add Pensando DFW Module (elastic#21063) [Filebeat] Check if processor is supported by ES version (elastic#23763) Syslog system tests: be more forgiving (elastic#24021)
What does this PR do?
A new function to make it easy to set minimum versions for processors. This allows modules to have pipelines that includes newer processors, while having a fallback if the ES version is too old.
Compared to existing functions which checks for specific options inside a processor, this checks for processors as a whole.
This PR is needed to close #22768 .
Why is it important?
Allows Filebeat modules to use newer ingest pipeline processors while not having to worry about backwards compatibility with the processor itself.
Checklist
- [ ] I have added an entry inCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.