8000 trace.Event interface refactor by NDStrahilevitz · Pull Request #4742 · aquasecurity/tracee · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

trace.Event interface refactor #4742

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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

NDStrahilevitz
Copy link
Collaborator

1. Explain what the PR does

"Replace me with make check-pr output"

2. Explain how to test it

3. Other comments

Copy link
Member
@geyslan geyslan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All seems neat. 👍🏻 This will bring us the possibility to include metrics and other stuff in the event object as well.

@NDStrahilevitz please call me again when possible.

@@ -14,42 +14,39 @@ import (
)
< 8000 span class="blob-code-inner blob-code-marker-context">
// Event is a single result of an ebpf event process. It is used as a payload later delivered to tracee-rules.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's a good opportunity to renew this description.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmmm, have any good ideas? @yanivagman Do you have something somewhere from the "everything is an event" docs?

@NDStrahilevitz NDStrahilevitz force-pushed the pipeline_event_wrapper branch 3 times, most recently from fb9c0dc to e487eff Compare May 6, 2025 10:20
The trace.Event is no longer a struct, but rather an interface that
tracee will implement internally.
This change will facillitate easier refactors in the event structure in
the future and provides an easy opportunity for later backwards
compatibility. Signature authors in particular should take note of this
change and realign to its usage.
This change moves the event struct (largely intact from the types package)
into a new pipeline package. This is a step towards decoupling the
event structure from the event implementation internal to tracee.

Accordingly, all the pipeline and event handling logic now uses the struct
defined in the pipeline package. The interface is left to signatures.
@NDStrahilevitz NDStrahilevitz force-pushed the pipeline_event_wrapper branch from e487eff to 3ba434d Compare May 19, 2025 12:56
@NDStrahilevitz NDStrahilevitz requested a review from geyslan May 19, 2025 13:01
@NDStrahilevitz NDStrahilevitz marked this pull request as ready for review May 19, 2025 13:01
Copy link
Member
@geyslan geyslan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@geyslan
Copy link
Member
geyslan commented Jun 2, 2025

@NDStrahilevitz, while reviewing @trvll's high-CPU profiles, we noticed that the decode stage is a significant contributor. Currently, eCtx is fully populated during decoding, but most of its fields are immediately reassigned to the final Event object. We believe it would be more efficient to decode directly into the Event type, which should help reduce CPU usage. WDYT? @yanivagman FYI.

@NDStrahilevitz
Copy link
Collaborator Author

@NDStrahilevitz, while reviewing @trvll's high-CPU profiles, we noticed that the decode stage is a significant contributor. Currently, eCtx is fully populated during decoding, but most of its fields are immediately reassigned to the final Event object. We believe it would be more efficient to decode directly into the Event type, which should help reduce CPU usage. WDYT? @yanivagman FYI.

I think this PR is just what may be able to facilitate this kind of optimization. Again, I tend on the side of doing this in its own PR, but it will be a good testing ground for the stability of the interface change. Just note that the context has various constant size byte arrays, whereas we want to present strings. So again, this relates to the previous discussion thread on aligning the field sizes to the context field sizes.

@NDStrahilevitz NDStrahilevitz requested a review from yanivagman June 4, 2025 16:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
0