-
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
[libbeat] Add lowercase_fields and uppercase_fields processors #34022
Conversation
This pull request does not have a backport label.
To fixup this pull request, you need to add the backport labels for the needed
|
❕ Build Aborted
Expand to view the summary
Build stats
Steps errors
Expand to view the steps failures
|
SonarCloud Quality Gate failed.
|
Pinging @elastic/elastic-agent-data-plane (Team:Elastic-Agent-Data-Plane) |
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.
Thank you very much for your contribution and especially for the full test coverage.
I think we should definitely improve the docs and naming of the processors. And we could refactor these 2 processor implementation into one parameterising the field changing function to avoid code duplication.
[source,json] | ||
------------------------------------------------------------------------------- | ||
{ | ||
"a.b": {} | ||
} | ||
------------------------------------------------------------------------------- |
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 example is very confusing.
- What is it supposed to demonstrate? Is it the end result?
- Does it lowercase the last field name (after the last
.
) or all the keys on the path? We need more examples covering these edge cases.
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.
- Yes, the end result.
- only the last field in a given path.
I agree, I should definitely improve the documentation and provide more examples.
[source,json] | ||
------------------------------------------------------------------------------- | ||
{ | ||
"a.B": {} | ||
} | ||
------------------------------------------------------------------------------- |
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.
The same comment from the lowercase
doc applies here. We need more examples "before" and "after" and to explicitly explain what segments of the dot notated paths are affected.
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.
Agreed, before and after cases would make a good examples for users.
|
||
var lower string | ||
if strings.ContainsRune(field, '.') { | ||
// In case of nested fields provided, we need to make sure to only modify the latest field in the chain |
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.
In my earlier comments I meant that this should have been added to the docs.
Also, how are we sure it's the desired behaviour for most of the users? Why not all the keys in the path?
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 will add it to the docs as well.
Regarding the desired behavior, I think lowercasing/uppercasing all the keys in the path is kind of restricting in case of a user only wanting to apply the action to one specific field,
While providing the ability to only apply the action to the latest field, may give the user a more flexibility and control in to which fields does the user want to apply the action to.
What do you think?
lastIndexRuneFunc := func(r rune) bool { return r == '.' } | ||
idx := strings.LastIndexFunc(field, lastIndexRuneFunc) | ||
lower = field[:idx+1] + strings.ToLower(field[idx+1:]) |
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.
not sure it's worth using runes here but I think it's okay.
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 actually wasn't sure it's required either, I will change that.
<titleabbrev>lowercase_fields</titleabbrev> | ||
++++ | ||
|
||
The `lowercase_fields` processor specifies a list of fields to lowercase. |
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.
After reading this I thought it would lowercase the values, not keys. I think we should explicitly explain what this processor is changing. The same goes for the upercase-fields
processor.
"github.com/pkg/errors" | ||
) | ||
|
||
type lowerCaseProcessor struct { |
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 it should be called lowerCaseFieldsProcessor
in case we would want lowerCaseValuesProcessor
in the future.
"github.com/pkg/errors" | ||
) | ||
|
||
type upperCaseProcessor struct { |
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 it should be called upperCaseFieldsProcessor
in case we would want upperCaseValuesProcessor
in the future.
} | ||
|
||
for _, field := range p.Fields { | ||
if err := p.upperCaseField(event, field); err != nil { |
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.
There is a lot of code duplication in these two processors. The only part that differs is what function we're applying to the field name (last segment of the path).
I think it would be better to implement a changeFieldProcessor
and a parameter called changeFunc
. We would avoid a lot of code duplication if we did this.
It will be still exposed as upperCaseFieldProcessor
and lowerCaseFieldProcessor
for external use but in their constructor function they would just create and return a changeFieldProcessor
with toLower
or toUpper
function as a parameter.
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.
Just to clarify, since this comment and your first comment are kind of confusing to me.
You mentioned on your first comment that these 2 processors can be replaced by one so why do I need to keep their *CaseFieldProcessor struct?
Also, where should I put the changeFieldProcessor? should I create it in another file?
Or should I create a new file change_fields.go that will include the changeFieldProcessor struct with both of the lowerCase/upperCase constructors that will return a changeFieldProcessor each with their relevant changeFunc?
This pull request is now in conflicts. Could you fix it? 🙏
|
@davidifr any sense of when development will be continued? If not, no big deal. |
Closing this one. Please reopen it when it ready for review again. |
@davidifr have you had a chance to work on this recently? |
I think @davidifr is no longer an active account. It would be nice of someone would take over and finish this |
@zez3 agreed! |
What does this PR do?
The PR adds lowercase and uppercase processors to libbeat.
Why is it important?
It's a basic requirement that came up from multiple users which are currently using different solutions in order to work around this missing feature (using
script
orrename
processors for example).Checklist
CHANGELOG.next.asciidoc
orCHANGELOG-developer.next.asciidoc
.Author's Checklist
How to test this PR locally
Related issues
Use cases
Users who desire to lowercase/uppercase some fields are currently required to use the
script
orrename
processors.With this PR, users will no longer need to use the above mentioned work arounds.
Screenshots
Logs