-
Notifications
You must be signed in to change notification settings - Fork 442
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
Negative performance impact on wildcard field #568
Comments
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
@ruflin I saw your message later in the benchmark discussion, I see quite a few usage of wildcards in the integration packages, I agree we are not affected as drastically as beats but we should probably audit the above, there is a lot of reference of wildcards especially on the zeek integration. Are we using it correctly ? |
@ph -- these fields were changed to bring the packages to parity with the beats modules. We're using them "correctly" in the sense that these fields are all marked as Personally I'd be fine keeping these as wildcard since the changes are slightly more constrained than beats, as @ruflin mentioned, but if we want to revert them in the same way the 7.11 beats modules are getting reverted, I'm fine with that too. WRT |
Thanks for the details @andrewstucki I am fine with keeping them as is and will be closing this. |
We are going to revert the wildcard changes in packages to be consistent with Beats for the time being. We'll swap over to using on the non-experimental fields for ECS 1.7. After ECS promotes the wildcard fields to non-experimental status we'll adopt them. |
quoted from elastic/beats#23671:
Looking at the integration fields we seems to have a few
wildcard
reference.The text was updated successfully, but these errors were encountered: