- 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
- Install Elastic Agent on Kubernetes using Helm
- Example: Install standalone Elastic Agent on Kubernetes using Helm
- Example: Install Fleet-managed Elastic Agent on Kubernetes using Helm
- 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
- Run Elastic Agent as an OTel Collector
- Run Elastic Agent without administrative privileges
- 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
- Package signatures
- Add an integration to an Elastic Agent policy
- View integration policies
- Edit or delete an integration policy
- Install and uninstall integration assets
- View integration assets
- Set integration-level outputs
- Upgrade an integration
- Managed integrations content
- Best practices for integrations assets
- Data streams
- 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 Host metadata
editAdd Host metadata
editInputs that collect logs and metrics use this processor by default, so you do not need to configure it explicitly.
The add_host_metadata
processor annotates each event with relevant metadata
from the host machine.
If you are using Elastic Agent to monitor external system, use the
add_observer_metadata
processor instead of
add_host_metadata
.
Example
edit- add_host_metadata: cache.ttl: 5m geo: name: nyc-dc1-rack1 location: 40.7128, -74.0060 continent_name: North America country_iso_code: US region_name: New York region_iso_code: NY city_name: New York
The fields added to the event look like this:
{ "host":{ "architecture":"x86_64", "name":"example-host", "id":"", "os":{ "family":"darwin", "type":"macos", "build":"16G1212", "platform":"darwin", "version":"10.12.6", "kernel":"16.7.0", "name":"Mac OS X" }, "ip": ["192.168.0.1", "10.0.0.1"], "mac": ["00:25:96:12:34:56", "72:00:06:ff:79:f1"], "geo": { "continent_name": "North America", "country_iso_code": "US", "region_name": "New York", "region_iso_code": "NY", "city_name": "New York", "name": "nyc-dc1-rack1", "location": "40.7128, -74.0060" } } }
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?
If host.*
fields already exist in the event, they are overwritten by
default unless you set replace_fields
to true
in the processor
configuration.
Name | Required | Default | Description |
---|---|---|---|
|
No |
|
Whether to include IP addresses and MAC addresses as fields |
|
No |
|
Sets the cache expiration time for the internal cache used by the processor. Negative values disable caching altogether. |
|
No |
User-definable token to be used for identifying a discrete location. Frequently a data center, rack, or similar. |
|
|
No |
Longitude and latitude in comma-separated format. |
|
|
No |
Name of the continent. |
|
|
No |
Name of the country. |
|
|
No |
Name of the region. |
|
|
No |
Name of the city. |
|
|
No |
ISO country code. |
|
|
No |
ISO region code. |
|
|
No |
|
Whether to replace original host fields from the event. If set |
On this page
ElasticON events are back!
Learn about the Elastic Search AI Platform from the experts at our live events.
Register now