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.

1. 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.

2. 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.

3. 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.

4. 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

5. 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

6. 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

7. Verify the module now appears under Disabled.

   $ sudo filebeat modules list
   Enabled:
   system
   
   Disabled:
   activemq
   apache
   auditd
   aws
   awsfargate
   azure
   nginx
   ##### snipped #####