- 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
IMPORTANT: No additional bug fixes or documentation updates
will be released for this version. For the latest information, see the
current release documentation.
Add process metadata
editAdd process metadata
editThe Add process metadata processor enriches events with information from running processes, identified by their process ID (PID).
processors: - add_process_metadata: match_pids: [system.process.ppid] target: system.process.parent
The fields added to the event look as follows:
"process": { "name": "systemd", "title": "/usr/lib/systemd/systemd --switched-root --system --deserialize 22", "exe": "/usr/lib/systemd/systemd", "args": ["/usr/lib/systemd/systemd", "--switched-root", "--system", "--deserialize", "22"], "pid": 1, "ppid": 0, "start_time": "2018-08-22T08:44:50.684Z", }
Optionally, the process environment can be included, too:
... "env": { "HOME": "/", "TERM": "linux", "BOOT_IMAGE": "/boot/vmlinuz-4.11.8-300.fc26.x86_64", "LANG": "en_US.UTF-8", } ...
It has the following settings:
-
match_pids
- List of fields to lookup for a PID. The processor will search the list sequentially until the field is found in the current event, and the PID lookup will be applied to the value of this field.
-
target
-
(Optional) Destination prefix where the
process
object will be created. The default is the event’s root. -
include_fields
-
(Optional) List of fields to add. By default, the processor
will add all the available fields except
process.env
. -
ignore_missing
-
(Optional) When set to
false
, events that don’t contain any of the fields in match_pids will be discarded and an error will be generated. By default, this condition is ignored. -
overwrite_keys
-
(Optional) By default, if a target field already exists, it
will not be overwritten and an error will be logged. If
overwrite_keys
is set totrue
, this condition will be ignored. -
restricted_fields
-
(Optional) By default, the
process.env
field is not output, to avoid leaking sensitive data. Ifrestricted_fields
istrue
, the field will be present in the output.
Was this helpful?
Thank you for your feedback.