-
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
[Filebeat][proposal] Disable filesets that are not configured #17256
Comments
I agree, right now when user trying to run Filebeat with only cloudtrail fileset enabled, the config file looks like this:
|
Pinging @elastic/integrations (Team:Integrations) |
+1 on doing this, filesets requiring special settings should be manually enabled to avoid errors and wasting cpu cycles |
btw this is a breaking change, right? How do you feel about how it will affect existing deployments? |
+1 , we are seeing issues with this behavior as well in |
Pinging @elastic/agent (Team:Agent) |
This changes fileset loading so that only filesets that are explicitly defined in the configuration are enabled. Until now, an enabled module will have all its filesets enabled unless explicitly disabled, which makes for a bad user experience with modules that contain a lot of filesets. Closes elastic#17256
This changes fileset loading so that only filesets that are explicitly defined in the configuration are enabled. Until now, an enabled module will have all its filesets enabled unless explicitly disabled, which makes for a bad user experience with modules that contain a lot of filesets. Closes #17256
…c#27526) This changes fileset loading so that only filesets that are explicitly defined in the configuration are enabled. Until now, an enabled module will have all its filesets enabled unless explicitly disabled, which makes for a bad user experience with modules that contain a lot of filesets. Closes elastic#17256
The default behavior for Filebeat modules is that all filesets are enabled by default. This puts a burden on users of modules when they upgrade versions. When a new fileset is added this is a breaking change to the end-user because they must take some action to change their configuration in order maintain the same behavior.
For example, when we add a new fileset to AWS module the end-user must add the new fileset to the configuration file just to disable it. If they don't then they will end up with errors because configuration is required for the new fileset to function.
A similar problem also manifests itself to users of the CLI when trying to enable particular filesets of a module. They get all filesets enabled by default. If they want to enable a subset of filesets they must use a wildcard option (that's undocumented AFAIK)
-M aws.*.enabled=false
.My proposal is to change the default behavior of filesets to disabled by default when they do not appear in the configuration.
The text was updated successfully, but these errors were encountered: