How to disable a Filebeat module

Disabling an unused Filebeat module stops that module's prebuilt log collection path, which helps keep shipped events focused on the services that still matter and avoids unnecessary parsing or pipeline activity for logs that no longer need to be ingested.

On package installs, Filebeat reads module snippets through filebeat.config.modules in /etc/filebeat/filebeat.yml and loads enabled module files from /etc/filebeat/modules.d. The filebeat modules disable command changes a module from <module>.yml to <module>.yml.disabled, which removes it from the active module glob the next time Filebeat reads that directory.

The modules command only works when filebeat.config.modules.path still points at modules.d, and a running service only notices the change immediately when reload.enabled is turned on for module configs. Otherwise, test the configuration first and restart filebeat.service so the disabled module is unloaded cleanly. Disabling a module does not delete previously indexed data or affect standalone inputs configured outside the module system.

Steps to disable a Filebeat module:

List module states to confirm the exact module name before disabling it.
```
$ sudo filebeat modules list
Enabled:
nginx
system

Disabled:
activemq
apache
auditd
aws
awsfargate
azure
##### snipped #####
```
Modules appear under Enabled when a matching <module>.yml file exists in /etc/filebeat/modules.d.
Disable the module.
```
$ sudo filebeat modules disable nginx
Disabled nginx
```
Disabling the wrong module stops that module's log collection after the change is applied.

Disable more than one module at once by listing them after disable, for example filebeat modules disable nginx system.
Confirm the module file was renamed out of the active modules.d glob.
```
$ sudo ls -1 /etc/filebeat/modules.d/nginx*
/etc/filebeat/modules.d/nginx.yml.disabled
```
The current filebeat.config.modules.path setting in /etc/filebeat/filebeat.yml must still point to ${path.config}/modules.d/*.yml if filebeat modules disable is expected to manage module state.
Test the Filebeat configuration before touching the running service.
```
$ sudo filebeat test config -c /etc/filebeat/filebeat.yml
Config OK
```
Related: How to test a Filebeat configuration
Restart the Filebeat service when module reloading is disabled.
```
$ sudo systemctl restart filebeat
```
If filebeat.config.modules.reload.enabled is true, Filebeat can detect the renamed module file automatically after the next reload.period scan and a restart is usually unnecessary.

Related: How to enable Filebeat config reloading
Related: How to manage the Filebeat service with systemctl in Linux
Confirm the Filebeat service is still running after the module change.
```
$ sudo systemctl status filebeat --no-pager
● filebeat.service - Filebeat sends log files to Logstash or Elasticsearch.
     Loaded: loaded (/usr/lib/systemd/system/filebeat.service; enabled; preset: enabled)
     Active: active (running) since Wed 2026-04-02 12:14:21 UTC; 4s ago
##### snipped #####
```
A failed service state after the restart usually means the configuration test was skipped, the wrong config file was tested, or another change in /etc/filebeat is invalid.

Related: How to manage the Filebeat service with systemctl in Linux

Verify the module now appears under Disabled.

$ sudo filebeat modules list
Enabled:
system

Disabled:
activemq
apache
auditd
aws
awsfargate
azure
nginx
##### snipped #####