- 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
- Configure index lifecycle management
- Load balance the output hosts
- Specify SSL settings
- Filter and enhance the exported data
- Define processors
- Add cloud metadata
- Add fields
- Add labels
- Add the local time zone
- Add tags
- Decode JSON fields
- Drop events
- Drop fields from events
- Keep fields from events
- Rename fields from events
- Add Kubernetes metadata
- Add Docker metadata
- Add Host metadata
- Dissect strings
- DNS Reverse Lookup
- Add process metadata
- Parse data by using ingest node
- Enrich events with geoIP information
- Configure project paths
- Configure 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
- Modules overview
- Apache module
- Auditd module
- Elasticsearch module
- haproxy module
- Icinga module
- IIS module
- Iptables module
- Kafka module
- Kibana module
- Logstash module
- MongoDB module
- MySQL module
- Nginx module
- Osquery module
- PostgreSQL module
- Redis module
- Santa module
- Suricata module
- System module
- Traefik module
- Zeek (Bro) Module
- Exported fields
- Apache fields
- Auditd fields
- Beat fields
- Cloud provider metadata fields
- Docker fields
- ECS fields
- elasticsearch fields
- haproxy fields
- Host fields
- Icinga fields
- IIS fields
- iptables fields
- Kafka fields
- kibana fields
- Kubernetes fields
- Log file content fields
- logstash fields
- mongodb fields
- MySQL fields
- NetFlow fields
- Nginx fields
- Osquery fields
- PostgreSQL fields
- Process fields
- Redis fields
- Google Santa fields
- Suricata fields
- System fields
- Traefik fields
- Zeek fields
- Monitoring Filebeat
- Securing Filebeat
- Troubleshooting
- Contributing to Beats
Use environment variables in the configuration
editUse environment variables in the configuration
editYou can use environment variable references in the config file to set values that need to be configurable during deployment. To do this, use:
${VAR}
Where VAR
is the name of the environment variable.
Each variable reference is replaced at startup by the value of the environment variable. The replacement is case-sensitive and occurs before the YAML file is parsed. References to undefined variables are replaced by empty strings unless you specify a default value or custom error text.
To specify a default value, use:
${VAR:default_value}
Where default_value
is the value to use if the environment variable is
undefined.
To specify custom error text, use:
${VAR:?error_text}
Where error_text
is custom text that will be prepended to the error
message if the environment variable cannot be expanded.
If you need to use a literal ${
in your configuration file then you can write
$${
to escape the expansion.
After changing the value of an environment variable, you need to restart Filebeat to pick up the new value.
You can also specify environment variables when you override a config
setting from the command line by using the -E
option. For example:
-E name=${NAME}
Examples
editHere are some examples of configurations that use environment variables and what each configuration looks like after replacement:
Config source | Environment setting | Config after replacement |
---|---|---|
|
|
|
|
no setting |
|
|
no setting |
|
|
|
|
|
no setting |
None. Returns an error message that’s prepended with the custom text. |
|
|
|
Specify complex objects in environment variables
editYou can specify complex objects, such as lists or dictionaries, in environment variables by using a JSON-like syntax.
As with JSON, dictionaries and lists are constructed using {}
and []
. But
unlike JSON, the syntax allows for trailing commas and slightly different string
quotation rules. Strings can be unquoted, single-quoted, or double-quoted, as a
convenience for simple settings and to make it easier for you to mix quotation
usage in the shell. Arrays at the top-level do not require brackets ([]
).
For example, the following environment variable is set to a list:
ES_HOSTS="10.45.3.2:9220,10.45.3.1:9230"
You can reference this variable in the config file:
output.elasticsearch: hosts: '${ES_HOSTS}'
When Filebeat loads the config file, it resolves the environment variable and
replaces it with the specified list before reading the hosts
setting.
Do not use double-quotes ("
) to wrap regular expressions, or the backslash (\
) will be interpreted as an escape character.