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

[EBPF-595] Create a common process consumer for eventmonitor #30559

Merged

Conversation

gjulianm
Copy link
Contributor

@gjulianm gjulianm commented Oct 28, 2024

What does this PR do?

This PR adds a ProcessConsumer type that can be directly used by callers interested just in exec/exit callbacks without having to manually implement all the necessary interfaces.

Motivation

Removing coupling between UprobeAttacher and ProcessMonitor, which caused problems with the process monitor initialization being called in multiple places. This PR allows GPU and DI module to use a consumer for the event monitor stream quickly, without having to copy-paste existing code.

Describe how to test/QA your changes

Possible Drawbacks / Trade-offs

Additional Notes

Related PR: #30554

@gjulianm gjulianm force-pushed the guillermo.julian/eventmonitor-common-process-consumer branch 2 times, most recently from ed95e39 to fd3481e Compare October 28, 2024 18:10
Copy link

cit-pr-commenter bot commented Oct 28, 2024

Regression Detector

Base automatically changed from valeri.pliskin/eventmonitor-rename-interfaces to main October 29, 2024 12:38
@gjulianm gjulianm force-pushed the guillermo.julian/eventmonitor-common-process-consumer branch from fd3481e to 0b2b370 Compare October 29, 2024 13:41
@gjulianm gjulianm force-pushed the guillermo.julian/eventmonitor-common-process-consumer branch from 0b2b370 to 1a38ab4 Compare October 29, 2024 13:52
@gjulianm gjulianm marked this pull request as ready for review October 29, 2024 13:52
@gjulianm gjulianm requested review from a team as code owners October 29, 2024 13:52
@gjulianm gjulianm added changelog/no-changelog qa/done Skip QA week as QA was done before merge and regressions are covered by tests labels Oct 29, 2024
@gjulianm gjulianm force-pushed the guillermo.julian/eventmonitor-common-process-consumer branch from 1a38ab4 to 52219d7 Compare October 29, 2024 14:08
@agent-platform-auto-pr
Copy link
Contributor

agent-platform-auto-pr bot commented Oct 29, 2024

[Fast Unit Tests Report]

On pipeline 48141503 (CI Visibility). The following jobs did not run any unit tests:

Jobs:
  • tests_deb-arm64-py3
  • tests_deb-x64-py3
  • tests_flavor_dogstatsd_deb-x64
  • tests_flavor_heroku_deb-x64
  • tests_flavor_iot_deb-x64
  • tests_rpm-arm64-py3
  • tests_rpm-x64-py3
  • tests_windows-x64

If you modified Go files and expected unit tests to run in these jobs, please double check the job logs. If you think tests should have been executed reach out to #agent-devx-help

Copy link
Contributor

@val06 val06 left a comment

Choose a reason for hiding this comment

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

reviewed

pkg/eventmonitor/consumers/doc.go Outdated Show resolved Hide resolved
pkg/eventmonitor/consumers/doc.go Show resolved Hide resolved
pkg/eventmonitor/consumers/process.go Show resolved Hide resolved
pkg/eventmonitor/consumers/process.go Show resolved Hide resolved
callbacks map[*ProcessCallback]struct{}

// mutex is the mutex that protects the callbacks map
mutex sync.RWMutex
Copy link
Contributor

Choose a reason for hiding this comment

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

what is the common pattern to use this struct?
in some cases rwmutex perform worse than the regular mutex

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I took the same pattern as there is in process-monitor, I assumed it was tested to be the best option.

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

common use case - adding all callbacks (write lock), and then calling them (read lock)

normally, all callbacks are being added (or removed) before (or after) the operation.
We can use regular mutex here, but, if we do intend to make the change - it should be tested to show it improves the usage of rwmutex

Copy link
Contributor

Choose a reason for hiding this comment

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

me and @brycekahle discussed rwmutex in some other context. and in some cases the rwmutex actually creates slight overhead (even when just using the readerlock without writer lock).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think we can do that, we're always going to (potentially) have two goroutines accessing the callback map concurrently, one from the event stream and another one from the subscription.

Copy link
Contributor

@val06 val06 Oct 31, 2024

Choose a reason for hiding this comment

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

do we have any subscriptions happening in "execution" phase or rather we can limit the subscription during the "init" phase before the handler go-routine starts?

Copy link
Contributor

@val06 val06 Oct 31, 2024

Choose a reason for hiding this comment

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

also these benchmarks for reference

(maybe sync.Map is a better choice)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It might not always be possible to limit the subscriptions, specially considering that the current way of adding event stream consumers requires having a global variable to share the consumer, and that could probably change later. Also, it'd require changing the SubscribeX signatures to be able to return an error.

I think it's a good idea to research this a bit more, but I think we should have a better view of dependencies in system-probe modules first to see how that fits with those phases.

Copy link
Contributor

Choose a reason for hiding this comment

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

i agree that we can leave it out of scope for this PR. Resolving the comment

@github-actions github-actions bot added long review PR is complex, plan time to review it and removed medium review PR review might take time labels Oct 29, 2024
@agent-platform-auto-pr
Copy link
Contributor

agent-platform-auto-pr bot commented Oct 29, 2024

Test changes on VM

Use this command from test-infra-definitions to manually test this PR changes on a VM:

inv create-vm --pipeline-id=48141503 --os-family=ubuntu

Note: This applies to commit d632825

Copy link
Contributor

@val06 val06 left a comment

Choose a reason for hiding this comment

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

reviewed

pkg/eventmonitor/consumers/process.go Outdated Show resolved Hide resolved
pkg/eventmonitor/consumers/process.go Outdated Show resolved Hide resolved
pkg/eventmonitor/consumers/process.go Outdated Show resolved Hide resolved
@gjulianm gjulianm changed the title [EBPF-594] Create a common process consumer for eventmonitor [EBPF-595] Create a common process consumer for eventmonitor Nov 4, 2024
Copy link
Contributor

@val06 val06 left a comment

Choose a reason for hiding this comment

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

reviewed

pkg/eventmonitor/consumers/process.go Outdated Show resolved Hide resolved
@gjulianm
Copy link
Contributor Author

gjulianm commented Nov 4, 2024

/merge

@dd-devflow
Copy link

dd-devflow bot commented Nov 4, 2024

🚂 MergeQueue: pull request added to the queue

The median merge time in main is 22m.

Use /merge -c to cancel this operation!

@dd-mergequeue dd-mergequeue bot merged commit 8803d71 into main Nov 4, 2024
221 checks passed
@dd-mergequeue dd-mergequeue bot deleted the guillermo.julian/eventmonitor-common-process-consumer branch November 4, 2024 16:21
@github-actions github-actions bot added this to the 7.61.0 milestone Nov 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog/no-changelog component/system-probe long review PR is complex, plan time to review it qa/done Skip QA week as QA was done before merge and regressions are covered by tests team/agent-security team/ebpf-platform
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants