-
Notifications
You must be signed in to change notification settings - Fork 23
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
Add a test framework for monitoring the host system from inside a container #140
Add a test framework for monitoring the host system from inside a container #140
Conversation
# install docker | ||
|
||
# DOCKER_VERSION="25.0" | ||
|
||
# curl -fsSL https://get.docker.com -o get-docker.sh | ||
# sudo sh ./get-docker.sh --version $DOCKER_VERSION |
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.
Do we need to keep those here?
Was it left over from development or is it likely to be needed?
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.
Depending on how creative I get with the buildkite images later, I might need it, so I'm leaving it in
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.
Looks good!
What does this PR do?
Closes elastic/beats#38241
This adds a lightweight test framework that runs a set of system tests under a container with the goal of monitoring the host system. The goal with these tests is to catch the numerous edge cases that happen when the system metrics function from a
/hostfs
path inside a container.The tests have a fairly large matrix of configurations, as we need to test both a wide variety of container permission settings, as well as differences in how linux distros will configure cgroups.
The framework here was designed with the goal of being relatively idiomatic; you can just run the framework with
go test
as you would normally.You can run the tests yourself with
go test -v ./tests
As you may have noticed, there's a non-zero amount of TODO statements here, since these tests were built to aggravate a bunch of existing bugs, so certain parts of the tests will remain un-implemented until those bugs are fixed.
Why is it important?
See elastic/beats#38241, we really need test for this particular case.
List of bugs that are responsible for TODO statements in the tests:
avoidFileSystem()
needs to handle an alternate rootfs #141/proc/[pid]/exe
don't account for kernel processes or docker permissions shenanigans #135SubsystemMountpoints()
can return wong V2 path for non-root container environments #139Checklist
CHANGELOG.md