Skip to content
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

[RFE] Add alternative enrichment naming option for l3address/l4address (and similar) formatters #2816

Open
flyth opened this issue May 7, 2024 · 0 comments

Comments

@flyth
Copy link
Member

flyth commented May 7, 2024

Current situation

Currently, when using specific known variable types, the formatter operator will add a string representation as alternative into the eBPF structure. That means that a source field defined as l4address will have a string field added as source.string, even though all other subfields of source are hidden after adding the string representation. We do this to prevent a change of the underlying type (field with subfields) caused by an operator.

Impact

source.string is unnecessarily long and causes trouble in the columns output.

Ideal future situation

source would actually be enough.

Implementation options

In order to keep the behavior of not changing the data layout depending on whether or not a specific operator is running, @alban proposed to add a _raw suffix to the eBPF field. If the formatter operator sees such a suffix, it could just remove it and use the remainder as the field name for the actual string representation and hide the _raw field.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: 🆕 New
Development

No branches or pull requests

1 participant