-
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 types in googlecloud/audit field renames #20465
Merged
andrewkroh
merged 2 commits into
elastic:master
from
andrewkroh:bugfix/fb/googlecloud-audit-mapping-exception
Aug 6, 2020
Merged
[Filebeat] Check types in googlecloud/audit field renames #20465
andrewkroh
merged 2 commits into
elastic:master
from
andrewkroh:bugfix/fb/googlecloud-audit-mapping-exception
Aug 6, 2020
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
Pinging @elastic/siem (Team:SIEM) |
I also fixed an error in cases where events did not have any authorization_info[] objects.
|
Specify type to the convert processor so that fields are renamed only if the value is (or can be coerced to) the desired type. This prevents the module from writing incompatible data types into fields and prevents mapping exceptions. The data in the google cloud audit logs can vary based on the source service so any time the module makes an assumption about a field that's not explicitly documented the module should be very defensive. The request/response object values would be good candidates for the flattened data type if we want to make a future change. Fixes elastic#18465
andrewkroh
force-pushed
the
bugfix/fb/googlecloud-audit-mapping-exception
branch
from
August 6, 2020 13:54
ed8e384
to
f9e1ed9
Compare
adriansr
approved these changes
Aug 6, 2020
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
6 tasks
andrewkroh
added a commit
to andrewkroh/beats
that referenced
this pull request
Aug 6, 2020
) Specify type to the convert processor so that fields are renamed only if the value is (or can be coerced to) the desired type. This prevents the module from writing incompatible data types into fields and prevents mapping exceptions. The data in the google cloud audit logs can vary based on the source service so any time the module makes an assumption about a field that's not explicitly documented the module should be very defensive. The request/response object values would be good candidates for the flattened data type if we want to make a future change. Fixes elastic#18465 (cherry picked from commit 924c239)
andrewkroh
added a commit
to andrewkroh/beats
that referenced
this pull request
Aug 6, 2020
) Specify type to the convert processor so that fields are renamed only if the value is (or can be coerced to) the desired type. This prevents the module from writing incompatible data types into fields and prevents mapping exceptions. The data in the google cloud audit logs can vary based on the source service so any time the module makes an assumption about a field that's not explicitly documented the module should be very defensive. The request/response object values would be good candidates for the flattened data type if we want to make a future change. Fixes elastic#18465 (cherry picked from commit 924c239)
6 tasks
andrewkroh
added a commit
that referenced
this pull request
Aug 6, 2020
…20479) Specify type to the convert processor so that fields are renamed only if the value is (or can be coerced to) the desired type. This prevents the module from writing incompatible data types into fields and prevents mapping exceptions. The data in the google cloud audit logs can vary based on the source service so any time the module makes an assumption about a field that's not explicitly documented the module should be very defensive. The request/response object values would be good candidates for the flattened data type if we want to make a future change. Fixes #18465 (cherry picked from commit 924c239)
andrewkroh
added a commit
that referenced
this pull request
Aug 11, 2020
…20480) Specify type to the convert processor so that fields are renamed only if the value is (or can be coerced to) the desired type. This prevents the module from writing incompatible data types into fields and prevents mapping exceptions. The data in the google cloud audit logs can vary based on the source service so any time the module makes an assumption about a field that's not explicitly documented the module should be very defensive. The request/response object values would be good candidates for the flattened data type if we want to make a future change. Fixes #18465 (cherry picked from commit 924c239)
melchiormoulin
pushed a commit
to melchiormoulin/beats
that referenced
this pull request
Oct 14, 2020
) Specify type to the convert processor so that fields are renamed only if the value is (or can be coerced to) the desired type. This prevents the module from writing incompatible data types into fields and prevents mapping exceptions. The data in the google cloud audit logs can vary based on the source service so any time the module makes an assumption about a field that's not explicitly documented the module should be very defensive. The request/response object values would be good candidates for the flattened data type if we want to make a future change. Fixes elastic#18465
leweafan
pushed a commit
to leweafan/beats
that referenced
this pull request
Apr 28, 2023
) (elastic#20479) Specify type to the convert processor so that fields are renamed only if the value is (or can be coerced to) the desired type. This prevents the module from writing incompatible data types into fields and prevents mapping exceptions. The data in the google cloud audit logs can vary based on the source service so any time the module makes an assumption about a field that's not explicitly documented the module should be very defensive. The request/response object values would be good candidates for the flattened data type if we want to make a future change. Fixes elastic#18465 (cherry picked from commit 1b0cc03)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Specify
type
to theconvert
processor so that fields are renamed onlyif the value is (or can be coerced to) the desired type. This prevents the
module from writing incompatible data types into fields and prevents
mapping exceptions.
The data in the google cloud audit logs can vary based on the source service
so any time the module makes an assumption about a field that's not explicitly
documented the module should be very defensive.
The request/response object values would be good candidates for the flattened data type
if we want to make a future change.
Why is it important?
It fixes a mapping exceptions that are occurring frequently.
Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Related issues
Screenshots
Once I copied over the new pipeline.js and restarted the errors dropped off.