- Fleet and Elastic Agent Guide: other versions:
- Fleet and Elastic Agent overview
- Beats and Elastic Agent capabilities
- Quick starts
- Migrate from Beats to Elastic Agent
- Deployment models
- Install Elastic Agents
- Install Fleet-managed Elastic Agents
- Install standalone Elastic Agents
- Install Elastic Agents in a containerized environment
- Run Elastic Agent in a container
- Run Elastic Agent on Kubernetes managed by Fleet
- Advanced Elastic Agent configuration managed by Fleet
- Configuring Kubernetes metadata enrichment on Elastic Agent
- Run Elastic Agent on GKE managed by Fleet
- Run Elastic Agent on Amazon EKS managed by Fleet
- Run Elastic Agent on Azure AKS managed by Fleet
- Run Elastic Agent Standalone on Kubernetes
- Scaling Elastic Agent on Kubernetes
- Using a custom ingest pipeline with the Kubernetes Integration
- Environment variables
- Install Elastic Agent from an MSI package
- Installation layout
- Air-gapped environments
- Using a proxy server with Elastic Agent and Fleet
- Uninstall Elastic Agents from edge hosts
- Start and stop Elastic Agents on edge hosts
- Elastic Agent configuration encryption
- Secure connections
- Manage Elastic Agents in Fleet
- Configure standalone Elastic Agents
- Create a standalone Elastic Agent policy
- Structure of a config file
- Inputs
- Providers
- Outputs
- SSL/TLS
- Logging
- Feature flags
- Agent download
- Config file examples
- Grant standalone Elastic Agents access to Elasticsearch
- Example: Use standalone Elastic Agent with Elastic Cloud Serverless to monitor nginx
- Example: Use standalone Elastic Agent with Elasticsearch Service to monitor nginx
- Debug standalone Elastic Agents
- Kubernetes autodiscovery with Elastic Agent
- Monitoring
- Reference YAML
- Manage integrations
- Define processors
- Processor syntax
- add_cloud_metadata
- add_cloudfoundry_metadata
- add_docker_metadata
- add_fields
- add_host_metadata
- add_id
- add_kubernetes_metadata
- add_labels
- add_locale
- add_network_direction
- add_nomad_metadata
- add_observer_metadata
- add_process_metadata
- add_tags
- community_id
- convert
- copy_fields
- decode_base64_field
- decode_cef
- decode_csv_fields
- decode_duration
- decode_json_fields
- decode_xml
- decode_xml_wineventlog
- decompress_gzip_field
- detect_mime_type
- dissect
- dns
- drop_event
- drop_fields
- extract_array
- fingerprint
- include_fields
- move_fields
- parse_aws_vpc_flow_log
- rate_limit
- registered_domain
- rename
- replace
- script
- syslog
- timestamp
- translate_sid
- truncate_fields
- urldecode
- Command reference
- Troubleshoot
- Release notes
Add Docker metadata
editAdd Docker metadata
editInputs that collect logs and metrics use this processor by default, so you do not need to configure it explicitly.
The add_docker_metadata
processor annotates each event with relevant metadata
from Docker containers. At startup the processor detects a Docker environment
and caches the metadata.
For events to be annotated with Docker metadata, the configuration must be valid, and the processor must be able to reach the Docker API.
Each event is annotated with:
- Container ID
- Name
- Image
- Labels
When running Elastic Agent in a container, you need to provide access to Docker’s unix
socket in order for the add_docker_metadata
processor to work. You can do this
by mounting the socket inside the container. For example:
docker run -v /var/run/docker.sock:/var/run/docker.sock ...
To avoid privilege issues, you may also need to add --user=root
to the docker
run
flags. Because the user must be part of the Docker group in order to access
/var/run/docker.sock
, root access is required if Elastic Agent is running as
non-root inside the container.
If the Docker daemon is restarted, the mounted socket will become invalid, and metadata will stop working. When this happens, you can do one of the following:
- Restart Elastic Agent every time Docker is restarted
-
Mount the entire
/var/run
directory (instead of just the socket)
Example
edit- add_docker_metadata: host: "unix:///var/run/docker.sock" #match_fields: ["system.process.cgroup.id"] #match_pids: ["process.pid", "process.parent.pid"] #match_source: true #match_source_index: 4 #match_short_id: true #cleanup_timeout: 60 #labels.dedot: false # To connect to Docker over TLS you must specify a client and CA certificate. #ssl: # certificate_authority: "/etc/pki/root/ca.pem" # certificate: "/etc/pki/client/cert.pem" # key: "/etc/pki/client/cert.key"
Configuration settings
editElastic Agent processors execute before ingest pipelines, which means that they process the raw event data rather than the final event sent to Elasticsearch. For related limitations, refer to What are some limitations of using processors?
Name | Required | Default | Description |
---|---|---|---|
|
No |
|
Docker socket (UNIX or TCP socket). |
|
No |
SSL configuration to use when connecting to the Docker socket. For a list of available settings, refer to SSL/TLS, specifically the settings under Table 4, “Common configuration options” and Table 5, “Client configuration options”. |
|
|
No |
List of fields to match a container ID. At least one of the fields most hold a container ID to get the event enriched. |
|
|
No |
|
List of fields that contain process IDs. If the process is running in Docker, the event will be enriched. |
|
No |
|
Whether to match the container ID from a log path present in the |
|
No |
|
Whether to match the container short ID from a log path present in the |
|
No |
|
Index in the source path split by a forward slash ( |
|
No |
|
Time of inactivity before container metadata is cleaned up and forgotten. |
|
No |
|
Whether to replace dots ( |
On this page