-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
feat(processors.regex): Allow batch transforms using named groups #13971
feat(processors.regex): Allow batch transforms using named groups #13971
Conversation
a2b18d3
to
1cb4a2b
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.
As usual the coe looks fine, but I'll go through it again during a final review. My questions are around the config and ensuring we aren't breaking existing users.
I also question the addition of the append boolean. This seems like scope creep.
edit: I of course forgot to say, thank you for this. This was clearly a ton of work ;) The refactor makes this much easier to view in the future.
For metrics transforms, `key` denotes the element that should be | ||
transformed. Furthermore, `result_key` allows control over the behavior applied | ||
in case the resulting `tag` or `field` name already exists. | ||
|
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.
You removed these comments? Are the covered below now?
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 as the behavior is now described in the sample.conf
part in my view...
apply the conversion. If any of the given criteria does not apply the conversion | ||
is not applied to the metric. | ||
|
||
The `replacement` option specifies the value of the resulting tag or field. It |
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.
Should there be another header here for replacement?
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.
No it describes how the replacement
setting is interpreted in this setup. That's also why it repeats for every subsection...
to be named in the `pattern`. Additional non-capturing ones or other | ||
expressions are allowed. Furthermore, neither `replacement` nor `result_key` | ||
can be set as the resulting tag/field name is the name of the group and the | ||
value corresponds to the group's content. |
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.
Worth an example below here? Or even below each of these?
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 an example in ### Named groups
and I think also for each of the sections...
Download PR build artifacts for linux_amd64.tar.gz, darwin_amd64.tar.gz, and windows_amd64.zip. 🥳 This pull request decreases the Telegraf binary size by -2.15 % for linux amd64 (new size: 197.7 MB, nightly size 202.0 MB) 📦 Click here to get additional PR build artifactsArtifact URLs |
resolves #5505
This PR restructures and simplifies the regexp-processor and then implements the possibility to transform multiple tags/fields using named capture-groups. In the course, it unifies the ability to specify wildcards on tags and fields (previously only possible on tags) by using standard
filter
expressions.Finally, it improves the README explaining behavior of the possible operations and modi in more detail.