-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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 skeleton x-pack Auditbeat module #8252
Add skeleton x-pack Auditbeat module #8252
Conversation
This adds an skeleton x-pack module to Auditbeat. The module is only included in the Elastic licensed Auditbeat binary. The config and fields.yml data are not yet included in the packaging. Additional updates are required.
138336e
to
b825251
Compare
It would be nice if we would only have 1 Makefile per Beat. So the Auditbeat Makefile when running We also need to figure out how we adapt the generation of the |
What about using a custom build tag, i.e.
So we can have some include.go that links whatever is 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.
LGTM, only have a naming question, but we can also decide that later. I’m good with merging as is.
@@ -0,0 +1,22 @@ | |||
== Sysinfo Module | |||
|
|||
The `sysinfo` module ... TODO. |
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.
I was thinking to name it system
to follow the Metricbeat and Filebeat tradition, but maybe that creates more confusion? I’m not sure.
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.
I think it would be OK to call it "system" if we avoid creating "metricsets" that have the same name as the existing ones in Metricbeat. We use nearly the exact same config between Auditbeat and Metricbeat so calling it the same thing could be confusing (even to us if we just glance at a config), but with unique names then it should be clear.
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.
I propose we merge it as is and let the module devs take ownership of naming.
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.
Agreed
|
||
// Modules without "datasets" should set their module and metricset names | ||
// to the same value then this will omit the event.dataset field. | ||
if module != metricSet { |
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.
Interesting. Lets discuss this in an other thread.
After we merge this I will rename |
LGTM |
This adds an skeleton x-pack module to Auditbeat. The module is only included in the Elastic licensed Auditbeat binary. The config and fields.yml data are not yet included in the packaging. Additional updates are required.
This adds an skeleton x-pack module to Auditbeat. The module is only included in the Elastic licensed Auditbeat binary. The config and fields.yml data are not yet included in the packaging. Additional updates are required.
This adds an skeleton x-pack module to Auditbeat. The module is only included in the Elastic licensed Auditbeat binary.
The config and fields.yml data are not yet included in the packaging. Additional updates are required in a separate PR. We need to decide on how we want to interact with the x-pack source code from a developer perspective (e.g. do we want to have separate Makefile for each Beat in the x-pack directory?).
If you run
go build
fromx-pack/auditbeat/
the generated binary will include this module.Note that this is targeted to a feature branch.