-
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: Ensure module pipelines compatibility with previous versions of Elasticsearch #26737
Conversation
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
This reverts commit 9357409.
While testing those modules in 7.11-compat mode, the tests would fail because the pipelines leave some unexpected fields behind. This cleans them up. This is caused by the uri_parts processor being removed and leaving behind a temporary field that is cleaned up by the `remove_if_successful` flag.
Pinging @elastic/security-external-integrations (Team:Security-External 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.
LGTM. This will help a lot in catching future problems. 🥇
filebeat/fileset/compatibility.go
Outdated
// adaptPipelineForCompatibility iterates over all processors in the pipeline | ||
// and adapts them for version of Elasticsearch used. Adapt can mean modifying | ||
// processor options or removing the processor. | ||
func adaptPipelineForCompatibility(esVersion common.Version, pipelineID string, content map[string]interface{}, log *logp.Logger) (err error) { | ||
p, ok := content["processors"] | ||
log = log.With("pipelineID", pipelineID) |
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.
I think lower snake case has been used almost everywhere else for key names passed to the logger. Recommend change for consistency.
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
* upstream/master: (430 commits) CI: increase timeout (elastic#26764) Heartbeat: add datastream fields to synthetics (elastic#26774) Osquerybeat: Change the query timeout from 3 secs to 60 secs (elastic#26775) Remove experimental warning for inputs with variables. (elastic#26762) Add latest k8s versions in testing (elastic#26729) change type of max_bytes to ByteType (elastic#26699) [Elastic Agent] Fix broken enrollment command (elastic#26749) Update agent managed manifest to include enrolment token variable (elastic#26756) Filebeat: Ensure module pipelines compatibility with previous versions of Elasticsearch (elastic#26737) Forward port changelog for 7.13.3 (elastic#26731) to master (elastic#26754) Upgrade PyYAML dependency used for tests (elastic#26746) Add agent fleet enrolment k8s manifest (elastic#26566) CI: retry the step only (elastic#26736) Osquerybeat: Fix the configuration poll interval setting (elastic#26739) [Filebeat] Replace copy_from with templated value (elastic#26631) Reduce the verbosity of the debug log for monitoring (elastic#26583) Add instructions on testing metricbeat kubernetes module (elastic#26643) Revert "[CI] fight the flakiness with some retry option in the CI only for the Pull Requests (elastic#26617)" (elastic#26704) Packaging: linux/armv7 is not supported (elastic#26706) Cyberarkpas: Link to official docs on how to setup TLS (elastic#26614) ...
@Mergifyio backport 7.x |
…s of Elasticsearch (#26737) Improve the pipeline/compatibility code so that all processors in a pipeline are scanned and acted-upon to ensure compatibility. This means: - Scan processors in on_failure section (both the pipeline's and each individual processor on-failure handler). - Scan the inner processor in a foreach processor. Add a new CI stage, module-compat-7.11, to filebeat/Jenkinsfile.yml and x-pack/filebeat/Jenkinsfile.yml, in order to run Filebeat modules tests under ES 7.11.2 to ensure that all pipelines are functional. This test uses a new flag, TESTING_FILEBEAT_SKIP_DIFF, to instruct the integration test to skip the comparison between the generated documents and the golden/expected files. The test will ensure that the pipeline loads, there are no ingest errors, the fields in the generated documents are valid and the number of returned documents matches the expected. This is intended to avoid having to maintain multiple versions of the golden files due to differences between ES versions and available processors. Also fixes the fortinet and threatintel modules pipelines so that they pass the new test, as some fields were left behind due to the uri_parts processor being removed. (cherry picked from commit 181cf69) # Conflicts: # x-pack/filebeat/module/threatintel/abuseurl/ingest/pipeline.yml # x-pack/filebeat/module/threatintel/anomali/ingest/pipeline.yml
Command
|
…s of Elasticsearch (backport #26737) (#27841) * Filebeat: Ensure module pipelines compatibility with previous versions of Elasticsearch (#26737) Improve the pipeline/compatibility code so that all processors in a pipeline are scanned and acted-upon to ensure compatibility. This means: - Scan processors in on_failure section (both the pipeline's and each individual processor on-failure handler). - Scan the inner processor in a foreach processor. Add a new CI stage, module-compat-7.11, to filebeat/Jenkinsfile.yml and x-pack/filebeat/Jenkinsfile.yml, in order to run Filebeat modules tests under ES 7.11.2 to ensure that all pipelines are functional. This test uses a new flag, TESTING_FILEBEAT_SKIP_DIFF, to instruct the integration test to skip the comparison between the generated documents and the golden/expected files. The test will ensure that the pipeline loads, there are no ingest errors, the fields in the generated documents are valid and the number of returned documents matches the expected. This is intended to avoid having to maintain multiple versions of the golden files due to differences between ES versions and available processors. Also fixes the fortinet and threatintel modules pipelines so that they pass the new test, as some fields were left behind due to the uri_parts processor being removed. (cherry picked from commit 181cf69) * Remove script.cache.max_size / script.max_compilations_rate from Filebeat tests (#19896) These setting has been removed as per elastic/elasticsearch#59262 causing the ES container to not launch. elasticsearch_1 | java.lang.IllegalArgumentException: unknown setting [script.cache.max_size] please check that any required plugins are installed, or check the breaking changes documentation for removed settings * Configure ingest node options in env and not in FB test_modules.py Co-authored-by: Adrian Serrano <[email protected]> Co-authored-by: Andrew Kroh <[email protected]>
What does this PR do?
This PR makes two changes:
Improve the pipeline/compatibility code so that all processors in a pipeline are scanned and acted-upon to ensure compatibility. This means:
on_failure
section (both the pipeline's and each individual processor on-failure handler).foreach
processor.Add a new CI stage,
module-compat-7.11
, tofilebeat/Jenkinsfile.yml
andx-pack/filebeat/Jenkinsfile.yml
, in order to run Filebeat modules tests under ES 7.11.2 to ensure that all pipelines are functional.This test uses a new flag,
TESTING_FILEBEAT_SKIP_DIFF
, to instruct the integration test to skip the comparison between the generated documents and the golden/expected files. The test will ensure that the pipeline loads, there are no ingest errors, the fields in the generated documents are valid and the number of returned documents matches the expected. This is intended to avoid having to maintain multiple versions of the golden files due to differences between ES versions and available processors.Why is it important?
To ensure that Filebeat is backwards-compatible with 7.x releases of ES.
Checklist
[ ] I have made corresponding changes to the documentation[ ] I have made corresponding change to the default configuration files[ ] I have added an entry inCHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Related issues