add_process_metadata: Support different integer types for pid field #26829
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
adriansr
added
bug
Filebeat
|
Pinging @elastic/security-external-integrations (Team:Security-External Integrations) |
botelastic
bot
added
needs_team
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪💚 Flaky test reportTests succeeded. Expand to view the summary
Test stats 🧪
|
|
/test |
andrewkroh
approved these changes
Jul 12, 2021
mergify bot
pushed a commit
that referenced
this pull request
Jul 12, 2021
…26829) Fixes a bug with the add_process_metadata processor where sometimes the lookup PID specified in match_pids cannot be parsed even if it's a valid integer. This is caused by the processor expecting the field to be of int type, while depending on how the field is populated, it can be other types, usually an int64 if the source is a json document. Fixes #26830 (cherry picked from commit 7be6e5e)
mergify bot
pushed a commit
that referenced
this pull request
Jul 12, 2021
…26829) Fixes a bug with the add_process_metadata processor where sometimes the lookup PID specified in match_pids cannot be parsed even if it's a valid integer. This is caused by the processor expecting the field to be of int type, while depending on how the field is populated, it can be other types, usually an int64 if the source is a json document. Fixes #26830 (cherry picked from commit 7be6e5e)
mergify bot
pushed a commit
that referenced
this pull request
Jul 12, 2021
…26829) Fixes a bug with the add_process_metadata processor where sometimes the lookup PID specified in match_pids cannot be parsed even if it's a valid integer. This is caused by the processor expecting the field to be of int type, while depending on how the field is populated, it can be other types, usually an int64 if the source is a json document. Fixes #26830 (cherry picked from commit 7be6e5e)
adriansr
added a commit
that referenced
this pull request
Jul 12, 2021
…26829) Fixes a bug with the add_process_metadata processor where sometimes the lookup PID specified in match_pids cannot be parsed even if it's a valid integer. This is caused by the processor expecting the field to be of int type, while depending on how the field is populated, it can be other types, usually an int64 if the source is a json document. Fixes #26830 (cherry picked from commit 7be6e5e)
adriansr
added a commit
that referenced
this pull request
Jul 12, 2021
…26829) (#26836) Fixes a bug with the add_process_metadata processor where sometimes the lookup PID specified in match_pids cannot be parsed even if it's a valid integer. This is caused by the processor expecting the field to be of int type, while depending on how the field is populated, it can be other types, usually an int64 if the source is a json document. Fixes #26830 (cherry picked from commit 7be6e5e) Co-authored-by: Adrian Serrano <adrisr83@gmail.com>
adriansr
added a commit
that referenced
this pull request
Jul 12, 2021
…26829) (#26838) Fixes a bug with the add_process_metadata processor where sometimes the lookup PID specified in match_pids cannot be parsed even if it's a valid integer. This is caused by the processor expecting the field to be of int type, while depending on how the field is populated, it can be other types, usually an int64 if the source is a json document. Fixes #26830 (cherry picked from commit 7be6e5e) Co-authored-by: Adrian Serrano <adrisr83@gmail.com>
adriansr
added a commit
that referenced
this pull request
Jul 13, 2021
…26829) (#26837) Fixes a bug with the add_process_metadata processor where sometimes the lookup PID specified in match_pids cannot be parsed even if it's a valid integer. This is caused by the processor expecting the field to be of int type, while depending on how the field is populated, it can be other types, usually an int64 if the source is a json document. Fixes #26830 (cherry picked from commit 7be6e5e) Co-authored-by: Adrian Serrano <adrisr83@gmail.com>
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?
Fixes a bug with the
add_process_metadataprocessor where sometimes the lookup PID specified inmatch_pidscannot be parsed even if it's a valid integer. This is caused by the processor expecting the field to be ofinttype, while depending on how the field is populated, it can be other types, usually anint64if the source is ajsondocument.Why is it important?
It prevents an error while using the processor.
It's been reported here: https://discuss.elastic.co/t/add-process-metadata-cannot-parse-pid-in-integer/263380
and experienced by me while populating a dummy pid field using
add_fieldsprocessor, for testing.Checklist
[ ] I have made corresponding changes to the documentation[ ] I have made corresponding change to the default configuration filesCHANGELOG.next.asciidocorCHANGELOG-developer.next.asciidoc.Logs
Related issues