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

Make the "host FS" location configurable #12

Open
andrewkroh opened this issue Apr 16, 2018 · 2 comments
Open

Make the "host FS" location configurable #12

andrewkroh opened this issue Apr 16, 2018 · 2 comments
Labels
enhancement New feature or request

Comments

@andrewkroh
Copy link
Member

There needs to be a way to pass in the host filesystem location as an option to allow collection from the host machine when operating inside of Docker. This is equivalent to how Metricbeat allows the -system.hostfs CLI option.

This must not be set as a global variable as it is in both gosigar and gopsutil.

I'm thinking to have an API like sysinfo.New(opts types.Option) and have an option that can be used like types.HostFS("/hostfs"). sysinfo.New would return an interface that has methods like Host(), Processes(), Process(), and Self().

And I think only the Linux provider would actually honor this option.

@andrewkroh andrewkroh added the enhancement New feature or request label Apr 16, 2018
@andrewkroh
Copy link
Member Author

This could also allow for testing from the outside because you could point sysinfo at some static directory to mock the proc filesystem. @fearful-symmetry

@uri-weisman
Copy link

The CSP team finds it useful as well, we run a go binary inside an elastic agent (container) and wish to collect the host's proc info.

fearful-symmetry added a commit to elastic/elastic-agent-system-metrics that referenced this issue Apr 18, 2024
…tainer (#140)

## 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:

- #141
- #135
- #139
- #132
- elastic/go-sysinfo#12

## Checklist

- [x] My code follows the style guidelines of this project
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] I have added tests that prove my fix is effective or that my
feature works
- [ ] I have added an entry in `CHANGELOG.md`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants