How to enable Filebeat config reloading

Enabling config reloading in Filebeat keeps log collection flexible when applications, containers, or new log files are added regularly. Splitting inputs into small snippet files reduces churn in the main configuration and avoids unnecessary full-service restarts for routine collection changes.

Filebeat watches a Glob defined under filebeat.config.inputs or filebeat.config.modules and rescans it at the configured reload.period. When matching files are added, changed, or removed, the corresponding external inputs or modules are started and stopped to match the new snippet set.

Reloading does not apply to the main /etc/filebeat/filebeat.yml file, so changes there still require a service restart. Each external input file must begin with - type and overlapping paths across running inputs can duplicate harvesting. On POSIX systems, snippet files are still subject to Beats ownership and permission checks, and reload.period should stay at 1s or higher.

Steps to enable Filebeat config reloading:

Create a directory for external input snippets.
```
$ sudo install -d -m 0750 /etc/filebeat/inputs.d
```
Keep /etc/filebeat/inputs.d writable only by trusted administrators because any matching file can become an active Filebeat input.
Add an external input loader to /etc/filebeat/filebeat.yml.
```
filebeat.config.inputs:
  enabled: true
  path: /etc/filebeat/inputs.d/*.yml
  reload.enabled: true
  reload.period: 10s
```
Keep reload.period at 1s or higher, and define input-specific settings inside each snippet file rather than under filebeat.config.inputs.
Create an input definition file such as /etc/filebeat/inputs.d/app.yml.
```
- type: filestream
  id: app-logs
  paths:
    - /var/log/app.log
```
Use a unique id for each filestream input and avoid overlapping paths across running inputs, or the same log file can be harvested twice.
Test the Filebeat configuration before restarting the service.
```
$ sudo filebeat test config -c /etc/filebeat/filebeat.yml
Config OK
```
Related: How to test a Filebeat configuration
Restart the Filebeat service to load the reloader settings from the main configuration file.
```
$ sudo systemctl restart filebeat
```
Related: How to manage the Filebeat service with systemctl in Linux

Add another input snippet file to confirm that new inputs start without a second service restart.

$ sudo tee /etc/filebeat/inputs.d/nginx.yml >/dev/null <<'YAML'
- type: filestream
  id: nginx-access
  paths:
    - /var/log/nginx/access.log
YAML

Review recent Filebeat logs after at least one reload.period interval.

$ sudo journalctl --unit=filebeat --since "5 min ago" --no-pager | grep -E "Config reloader started|Input 'filestream' starting"
Apr 02 11:15:51 host filebeat[3356]: {"log.level":"info","@timestamp":"2026-04-02T11:15:51.135Z","log.logger":"crawler.input.reloader","message":"Config reloader started","service.name":"filebeat","ecs.version":"1.6.0"}
Apr 02 11:15:54 host filebeat[3356]: {"log.level":"info","@timestamp":"2026-04-02T11:15:54.139Z","log.logger":"input.filestream","message":"Input 'filestream' starting","service.name":"filebeat","id":"app-logs","ecs.version":"1.6.0"}
Apr 02 11:15:57 host filebeat[3356]: {"log.level":"info","@timestamp":"2026-04-02T11:15:57.143Z","log.logger":"input.filestream","message":"Input 'filestream' starting","service.name":"filebeat","id":"nginx-access","ecs.version":"1.6.0"}

One Config reloader started line plus a new Input 'filestream' starting message for the added snippet confirms that reload is active. Very small lab files can still delay actual harvesting, so the startup log lines are the cleanest verification.