Skip to content

Latest commit

 

History

History
125 lines (96 loc) · 4.64 KB

filebeat-modules-options.asciidoc

File metadata and controls

125 lines (96 loc) · 4.64 KB

Configure modules

Modules
Note
 Using {beatname_uc} modules is optional. You may decide to configure inputs manually if you’re using a log type that isn’t supported, or you want to use a different setup.

{beatname_uc} modules provide a quick way to get started processing common log formats. They contain default configurations, {es} ingest pipeline definitions, and {kib} dashboards to help you implement and deploy a log monitoring solution.

You can configure modules in the modules.d directory (recommended), or in the {beatname_uc} configuration file.

Before running {beatname_uc} with modules enabled, make sure you also set up the environment to use {kib} dashboards. See [{beatname_lc}-installation-configuration] for more information.

Configure modules in the modules.d directory

The modules.d directory contains default configurations for all the modules available in {beatname_uc}. To enable or disable specific module configurations under modules.d, run the modules enable or modules disable command. For example:

The default configurations assume that your data is in the location expected for your OS and that the behavior of the module is appropriate for your environment. To change the default behavior, configure variable settings. For a list of available settings, see the documentation under [{beatname_lc}-modules].

For advanced use cases, you can also override input settings.

Tip
 You can enable modules at runtime by using the --modules flag. This is useful if you’re getting started and want to try things out. Any modules specified at the command line are loaded along with any modules that are enabled in the configuration file or modules.d directory. If there’s a conflict, the configuration specified at the command line is used.

Configure modules in the {beatname_lc}.yml file

When possible, you should use the config files in the modules.d directory.

However, configuring modules directly in the config file is a practical approach if you have upgraded from a previous version of {beatname_uc} and don’t want to move your module configs to the modules.d directory. You can continue to configure modules in the {beatname_lc}.yml file, but you won’t be able to use the modules command to enable and disable configurations because the command requires the modules.d layout.

To enable specific modules in the {beatname_lc}.yml config file, add entries to the {beatname_lc}.modules list. Each entry in the list begins with a dash (-) and is followed by settings for that module.

The following example shows a configuration that runs the nginx,mysql, and system modules:

{beatname_lc}.modules:
- module: nginx
  access:
  error:
- module: mysql
  slowlog:
- module: system
  auth:

Override input settings

Behind the scenes, each module starts a {beatname_uc} input. Advanced users can add or override any input settings. For example, you can set close_eof to true in the module configuration:

- module: nginx
  access:
    input:
      close_eof: true

Or at the command line when you run {beatname_uc}:

-M "nginx.access.input.close_eof=true"

You can use wildcards to change variables or settings for multiple modules/filesets at once. For example, you can enable close_eof for all the filesets in the nginx module:

-M "nginx.*.input.close_eof=true"

You can also enable close_eof for all inputs created by any of the modules:

-M "*.*.input.close_eof=true"