- Filebeat Reference: other versions:
- Overview
- Getting Started With Filebeat
- 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 CSV fields
- Decode JSON fields
- Community ID Network Flow Hash
- Convert
- Drop events
- Drop fields from events
- Keep fields from events
- Rename fields from events
- Add Kubernetes metadata
- Add Docker metadata
- Add Host metadata
- Add Observer metadata
- Dissect strings
- DNS Reverse Lookup
- Add process metadata
- Script Processor
- Extract array
- 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
- Cisco module
- Coredns Module
- Elasticsearch module
- Envoyproxy Module
- haproxy module
- Icinga module
- IIS module
- Iptables module
- Kafka module
- Kibana module
- Logstash module
- MongoDB module
- MySQL module
- nats module
- NetFlow module
- Nginx module
- Osquery module
- Palo Alto Networks module
- PostgreSQL module
- RabbitMQ module
- Redis module
- Santa module
- Suricata module
- System module
- Traefik module
- Zeek (Bro) Module
- Exported fields
- Apache fields
- Auditd fields
- Beat fields
- Cisco fields
- Cloud provider metadata fields
- Coredns fields
- Docker fields
- ECS fields
- elasticsearch fields
- Envoyproxy fields
- haproxy fields
- Host fields
- Icinga fields
- IIS fields
- iptables fields
- Jolokia Discovery autodiscover provider fields
- Kafka fields
- kibana fields
- Kubernetes fields
- Log file content fields
- logstash fields
- mongodb fields
- MySQL fields
- nats fields
- NetFlow fields
- NetFlow fields
- Nginx fields
- Osquery fields
- panw fields
- PostgreSQL fields
- Process fields
- RabbitMQ fields
- Redis fields
- Google Santa fields
- Suricata fields
- System fields
- Traefik fields
- Zeek fields
- Monitoring Filebeat
- Securing Filebeat
- Troubleshooting
- Get help
- Debug
- Common problems
- Can’t read log files from network volumes
- Filebeat isn’t collecting lines from a file
- Too many open file handlers
- Registry file is too large
- Inode reuse causes Filebeat to skip lines
- Open file handlers cause issues with Windows file rotation
- Filebeat is using too much CPU
- Dashboard in Kibana is breaking up data fields incorrectly
- Fields are not indexed or usable in Kibana visualizations
- Filebeat isn’t shipping the last line of a file
- Filebeat keeps open file handlers of deleted files for a long time
- Filebeat uses too much bandwidth
- Error loading config file
- Found unexpected or unknown characters
- Logstash connection doesn’t work
- @metadata is missing in Logstash
- Not sure whether to use Logstash or Beats
- SSL client fails to connect to Logstash
- Monitoring UI shows fewer Beats than expected
- Contributing to Beats
Grant users access to secured resources
editGrant users access to secured resources
editYou can use role-based access control to grant users access to secured resources. The roles that you set up depend on your organization’s security requirements and the minimum privileges required to use specific features.
Filebeat users typically perform these main roles: they do the initial setup, publish monitoring information, and publish events. If they’re using Kibana, they view and sometimes create visualizations that access Filebeat indices.
X-Pack security provides pre-built roles that grant some of the privileges needed by Filebeat users. When possible, use the built-in roles to minimize the affect of future changes on your security strategy.
For privileges not granted by existing roles, create new roles. At a minimum, create a role for setting up Filebeat, a role for publishing events, and a role for reading Filebeat indices. Assign these new roles, along with the pre-built roles, to grant the full set of privileges required by Filebeat users.
The following sections describe the privileges and roles required to perform specific job roles.
Privileges needed for initial setup
editUsers who set up Filebeat typically need to load mappings, dashboards, and other objects used to index data into Elasticsearch and visualize it in Kibana. The privileges required depend on the setup tasks users need to perform.
These instructions assume that you are using the default name for Filebeat indices. If you are using a custom name, modify the privileges to match your index naming pattern.
Task | Required privileges and roles |
---|---|
Set up index templates |
|
|
|
|
|
Set up example dashboards |
|
Set up machine learning job configurations |
|
|
|
|
|
Set up ingest pipelines |
|
|
|
Set up index lifecycle policies |
|
|
|
Enroll and manage configurations in Beats central management |
|
Privileges needed to publish and view monitoring information
editX-Pack security provides the filebeat_system
built-in user and
filebeat_system
built-in
role for sending monitoring information. You can use the built-in user, or
create a user who has the privileges needed to send monitoring information.
If you use the filebeat_system
user, make sure you
set the password.
Task | Required privileges and roles |
---|---|
Send monitoring info |
|
Use Stack Monitoring in Kibana to monitor Filebeat |
|
Privileges needed to publish events
editUsers who publish events to Elasticsearch need to create and read from Filebeat indices. The privileges required for this role depend on the tasks users need to perform:
Task | Required privileges and roles |
---|---|
Send data to a secured cluster without index lifecycle management |
|
|
|
also requires privileges to set up index templates unless you’ve disabled automatic template loading |
|
Send data to a secured cluster that supports index lifecycle management |
|
|
|
Read configurations from Beats central management |
|
|
Privileges needed by Kibana users
editKibana users typically need to view dashboards and visualizations that contain Filebeat data. These users might also need to create and edit dashboards and visualizations. If you’re using Beats central management, they need to create and manage configurations.
The privileges required for Kibana users depend on the tasks they need to perform:
Task | Required privileges and roles |
---|---|
View Filebeat dashboards |
|
|
|
View and edit Filebeat dashboards |
|
|
|
Create and manage configurations in Beats central management |
|
|
Learn more about users and roles
editWant to learn more about creating users and roles? See Securing the Elastic Stack. Also see:
- Security privileges for a description of available privileges
- Built-in roles for a description of roles that you can assign to users
On this page