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

Allow to ignore process arguments #1898

Merged
merged 2 commits into from
Oct 21, 2024
Merged

Conversation

erthalion
Copy link
Contributor

Description

Add an internal option to not collect process arguments, as a workaround for ROX-25845.

Checklist

  • Investigated and inspected CI test results
  • Updated documentation accordingly

Automated testing

  • Added unit tests
  • Added integration tests
  • Added regression tests

Testing Performed

Previous evaluation in the field with the debugging image.

@erthalion erthalion requested a review from a team as a code owner October 18, 2024 14:21
@erthalion erthalion force-pushed the feature/ignore-arguments branch 3 times, most recently from b474823 to 330b1d4 Compare October 18, 2024 15:54
Copy link
Collaborator

@Molter73 Molter73 left a comment

Choose a reason for hiding this comment

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

LGTM! Just a couple of minor comments, but they are nothing major, so feel free to ignore them.

@@ -52,6 +56,8 @@ class ProcessSignalFormatter : public ProtoSignalFormatter<sensor::SignalStreamM
const EventNames& event_names_;
std::unique_ptr<system_inspector::EventExtractor> event_extractor_;
ContainerMetadata container_metadata_;

const CollectorConfig* config_;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could we store this as a reference to make it clear it can never be null and it won't be reassigned? (at least for now).

Suggested change
const CollectorConfig* config_;
const CollectorConfig& config_;

@@ -34,6 +42,8 @@ class ProcessSignalHandler : public SignalHandler {
ProcessSignalFormatter formatter_;
system_inspector::Stats* stats_;
RateLimitCache rate_limiter_;

const CollectorConfig* config_;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Same question here.

Comment on lines 17 to 33
class MockCollectorConfig : public CollectorConfig {
public:
MockCollectorConfig() = default;

void SetDisableProcessArguments(bool value) {
disable_process_arguments_ = value;
}
};

class MockProcessSignalFormatter : public ProcessSignalFormatter {
public:
MockProcessSignalFormatter(sinsp* inspector, const CollectorConfig& config) : ProcessSignalFormatter(inspector, config) {};

ProcessSignal* MockCreateProcessSignal(sinsp_evt* event) {
return CreateProcessSignal(event);
}
};
Copy link
Collaborator

Choose a reason for hiding this comment

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

Could we use FRIEND_TEST definitions here instead of mocks? Ideally, we would have an easy way to create a config object with any configuration we want without any of these methods, but for now, I think I prefer not having mocks when all we are using them for is access to private/protected fields, WDYT?

http://google.github.io/googletest/reference/testing.html#FRIEND_TEST

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, why not. It sorts of leaks tests details into the implementation, but it's not so bad.

Pass CollectorConfig to the ProcessSignalHandler and
ProcessSignalFormatter. It's needed for the future work, involving
conditional logic in the process handler.
@erthalion erthalion merged commit 19eafba into master Oct 21, 2024
66 of 69 checks passed
@erthalion erthalion deleted the feature/ignore-arguments branch October 21, 2024 15:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants