-
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
Add basic wildcard/keyword fallback for upcoming ECS releases #22521
Conversation
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Steps errorsExpand to view the steps failures
|
💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
This is looking good for now. The next version of ECS will only introduce the I'm not familiar enough about the codebase, but it's important that this fallback happens for any field using basic types, not just ECS fields. I don't have insight into what custom fields are in Beats or will be added, but if any of them is basic or changes to a basic type, they will need to fall back to an OSS type as well, where possible. As a corollary to this previous point, perhaps you should consider falling back
So to recap, as far as the next version of ECS is concerned, only |
@webmat my understanding of this code is that the |
Not required per ECS, so feel free to move forward as is. But as I said, I don't have insight into all of the other Beats fields. Trying each OSS Beats' |
x-pack/libbeat/cmd/inject.go
Outdated
@@ -21,6 +22,10 @@ import ( | |||
_ "github.com/elastic/beats/v7/x-pack/libbeat/autodiscover/providers/aws/elb" | |||
) | |||
|
|||
func init() { | |||
version.ElasticLicensed = true |
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.
This is setting a global, that we are trying to avoid cc @urso
Perhaps we should come up with a way to passing this to the beat initialization?
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.
Yeah, +1 on not introducing globals. Beats query the ES version and Basic queries the license on startup.
We pass the agent name and version via beat.Info
. Maybe this would be the right place to put this information.
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'm not a fan of globals either, and made the change, but due to the way that the root cobra commands are initialized in each beat and the way the info propagates from the command to the processor, the changes are quite a bit more invasive. So, I'm going to keep this conversation unresolved for some context in case we want to revert back to the global.
7aec4aa
to
c734cb9
Compare
c734cb9
to
165004c
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.
We are almost there, I left a minor comment on naming, apart from that this LGTM! Thank you for working on it
c4d2e80
to
ca9346b
Compare
ca9346b
to
591d5a5
Compare
cc @elastic/apm-server when pulling this change in with a beats update we have to ensure to set the |
Pulling in changes from elastic/beats#22521
* Update to elastic/beats@0fda3061815d Pulling in changes from elastic/beats#22521 * Set ElasticLicensed for enabling wildcard support.
* Update to elastic/beats@0fda3061815d Pulling in changes from elastic/beats#22521 * Set ElasticLicensed for enabling wildcard support.
What does this PR do?
This sets the groundwork for #21674 by adding a simple fallback mechanism for wildcard fields in unsupported Elasticsearch versions and non-OSS Beats distros. If you're publishing to ES < 7.9.0 you get
keyword
fields instead of wildcard, if you're coming from OSS Beats you get the same.This will allow us to move forward with the migration to ECS 1.7.0 with upcoming wildcard support..
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.