-
Notifications
You must be signed in to change notification settings - Fork 419
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
Init commit of linux system tests #1340
Init commit of linux system tests #1340
Conversation
Pinging @elastic/integrations (Team:Integrations) |
💚 Build Succeeded
Expand to view the summary
Build stats
Test stats 🧪
Trends 🧪 |
Could you elaborate on this? Are you talking about |
For system tests of metrics so far I think that we are only checking that metrics are collected without errors, we are not checking their values. For this case it may be also enough with checking that it collects any data, so the actual For logs you can use |
Yes, along with a few other things. Depending on the OS config, some procfs files (such as RAID) won't contain any useful information for the metricset to parse. Some, such as cgroup files, won't exist at all inside a container. I spent some time hacking at the container orchestration that exists now to do that, but it was awfully ugly and I decided not to. At minimum, it would be nice to omit the "auxillary" container that |
I'm very much onboard with this for the initial batch of tests (this PR). It won't be testing the full package but many parts of it are still valid. On top of that (maybe later), we could also have a @mtojek @jsoriano any thoughts on the need for a dummy container when there is no need for it? I'm not particularly concerned with its need by I see @fearful-symmetry point |
This is a specific use case where you don't need to deploy anything. Temporarily you can use a lightweight/micro/dummy image. Definitely not a blocker, but could be considered as a feature. Please open an issue in elastic-package for this. |
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.
As you introduce the dependency on ECS, could you please review and adjust also other data streams? I see there are potential candidates, not sure about others:
https://github.com/fearful-symmetry/integrations/blob/linux-system-tests/packages/linux/data_stream/users/fields/ecs.yml
https://github.com/fearful-symmetry/integrations/blob/linux-system-tests/packages/linux/data_stream/socket/fields/ecs.yml
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.
LGTM, but I left one comment regarding error.message
to double-check.
@@ -0,0 +1,11 @@ | |||
- name: ecs.version | |||
external: ecs | |||
- name: error.message |
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.
Usually we don't add error.message
fields. Is there any reason why you added it here? I mean, are there any problems with system tests? If so, then they should be fixed first.
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.
Ah, that was probably just me copying the ECS fields from other data streams. I can remove it.
* init commit of linux system tests * fix changelog version * format code * use import ECS values * format, again * add ecs fields to the rest of the data_streams * remove error ecs fields
What does this PR do?
This adds system tests to (most) of the linux data streams, which should help in the future with catching low-hanging bugs.
However, we may want to look into expanding the test architecture somewhat, and I'd like input from @mtojek before this gets merged. The system integration is a bit odd, in that 90% of the code can be covered by pointed at a test file, without any external services, containers, etc. If we want to expand the system tests used in
linux
andsystem
further, we need some kind of system that populates a test directory inside theagent
container with a handful of files that the data streams can read from. I struggled to hack up a solution with what we have now, but decided it wasn't quite worth the ugliness. The system also seems to require test container service...so I had to make a dummy one.Checklist
changelog.yml
file.How to test this PR locally
elastic-package -v test system
in thelinux
directory