- Filebeat Reference: other versions:
- Overview
- Getting Started With Filebeat
- Step 1: Install Filebeat
- Step 2: Configure Filebeat
- Step 3: Configure Filebeat to use Logstash
- Step 4: Load the index template in Elasticsearch
- Step 5: Set up the Kibana dashboards
- Step 6: Start Filebeat
- Step 7: View the sample Kibana dashboards
- Quick start: modules for common log formats
- Repositories for APT and YUM
- Setting up and running Filebeat
- Upgrading Filebeat
- How Filebeat works
- Configuring Filebeat
- Specify which modules to run
- Configure inputs
- Manage multiline messages
- Specify general settings
- Load external configuration files
- Configure the internal queue
- Configure the output
- Set up index lifecycle management
- Load balance the output hosts
- Specify SSL settings
- Filter and enhance the exported data
- Parse data by using ingest node
- Enrich events with geoIP information
- Set up project paths
- Set up the Kibana endpoint
- Load the Kibana dashboards
- Load the Elasticsearch index template
- Configure logging
- Use environment variables in the configuration
- Autodiscover
- YAML tips and gotchas
- Regular expression support
- HTTP Endpoint
- filebeat.reference.yml
- Beats central management
- Modules
- Exported fields
- Alias fields
- Apache2 fields
- Auditd fields
- Beat fields
- Cloud provider metadata fields
- Docker fields
- elasticsearch fields
- haproxy fields
- Host fields
- Icinga fields
- IIS fields
- Kafka fields
- kibana fields
- Kubernetes fields
- Log file content fields
- logstash fields
- mongodb fields
- MySQL fields
- Nginx fields
- Osquery fields
- PostgreSQL fields
- Redis fields
- System fields
- Traefik fields
- Monitoring Filebeat
- Securing Filebeat
- Troubleshooting
- Migrating from Logstash Forwarder to Filebeat
- Contributing to Beats
Live reloading
editLive reloading
editYou can configure Filebeat to dynamically reload external configuration files
when there are changes. This feature is available for input and module
configurations that are loaded as
external configuration files. You cannot
use this feature to reload the main filebeat.yml configuration file.
To configure this feature, you specify a path (Glob) to watch for configuration changes. When the files found by the Glob change, new inputs and/or modules are started and stopped according to changes in the configuration files.
This feature is especially useful in container environments where one container is used to tail logs for services running in other containers on the same host.
To enable dynamic config reloading, you specify the path and reload options
under filebeat.config.inputs or filebeat.config.modules sections.
For example:
filebeat.config.inputs: enabled: true path: configs/*.yml reload.enabled: true reload.period: 10s
-
path - A Glob that defines the files to check for changes.
-
reload.enabled -
When set to
true, enables dynamic config reload. -
reload.period -
Specifies how often the files are checked for changes. Do not
set the
periodto less than 1s because the modification time of files is often stored in seconds. Setting theperiodto less than 1s will result in unnecessary overhead.
On systems with POSIX file permissions, all Beats configuration files are subject to ownership and file permission checks. For more information, see Config File Ownership and Permissions in the Beats Platform Reference.