- 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
- 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
- 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
Configuring Kubernetes metadata enrichment on Elastic Agent
editConfiguring Kubernetes metadata enrichment on Elastic Agent
editKubernetes metadata refer to contextual information extracted from Kubernetes resources. Metadata information enrich metrics and logs collected from a Kubernetes cluster, enabling deeper insights into Kubernetes environments.
When the Elastic Agent’s policy includes the Kubernetes Integration which configures the collection of Kubernetes related metrics and container logs, the mechanisms used for the metadata enrichment are:
- Kubernetes Provider for log collection
- Kubernetes metadata enrichers for metrics
In case the Elastic Agent’s policy does not include the Kubernetes integration, but Elastic Agent runs inside a Kubernetes environment, the Kubernetes metadata are collected by the add_kubernetes_metadata. The processor is configurable when Elastic Agent is managed by Fleet.
Kubernetes Logs
editWhen it comes to container logs collection, the Kubernetes Provider is used. It monitors for pod resources in the cluster and associates each container log file with a corresponding pod’s container object. That way, when a log file is parsed and an event is ready to be published to Elasticsearch, the internal mechanism knows to which actual container this log file belongs. The linkage is established by the container’s ID, which forms an integral part of the filename for the log. The Kubernetes autodiscover provider has already collected all the metadata for that container, leveraging pod, namespace and node watchers. Thus, the events are enriched with the relevant metadata.
In order to configure the metadata collection, the Kubernetes provider needs to be configured. All the available configuration options of the Kubernetes provider can be found in the Kubernetes Provider documentation.
- For Standalone Elastic Agent configuration:
Follow information of add_resource_metadata
parameter of Kubernetes Provider
Example of how to configure kubernetes metadata enrichment.
apiVersion: v1 kind: ConfigMap metadata: name: agent-node-datastreams namespace: kube-system labels: k8s-app: elastic-agent data: agent.yml: |- kubernetes.provider add_resource_metadata: namespace: #use_regex_include: false include_labels: ["namespacelabel1"] #use_regex_exclude: false #exclude_labels: ["namespacelabel2"] node: #use_regex_include: false include_labels: ["nodelabel2"] include_annotations: ["nodeannotation1"] #use_regex_exclude: false #exclude_labels: ["nodelabel3"] #deployment: false #cronjob: false
- Managed Elastic Agent configuration:
The Kubernetes provider can be configured following the steps in Advanced Elastic Agent configuration managed by Fleet.
Kubernetes metrics
editThe Elastic Agent metrics collection implements metadata enrichment based on watchers, a mechanism used to continuously monitor Kubernetes resources for changes and updates. Specifically, the different datasets share a set of resource watchers. Those watchers (pod, node, namespace, deployment, daemonset etc.) are responsible for watching for all different resource events (creation, update and deletion) by subscribing to the Kubernetes watch API. This enables real-time synchronization of application state with the state of the Kubernetes cluster. So, they keep an up-to-date shared cache store of all the resources' information and metadata. Whenever metrics are collected by the different sources (kubelet, kube-state-metrics), before they get published to Elasticsearch as events, they are enriched with needed metadata.
The metadata enrichment can be configured by editing the Kubernetes integration.
Only in metrics collection, metadata enrichment can be disabled by switching off the Add Metadata
toggle in every dataset. Extra resource metadata such as
node, namespace labels and annotations, as well as deployment and cronjob information can be configured per dataset.
- Managed Elastic Agent configuration:

add_resource_metadata block needs to be configured to all datasets that are enabled
- For Standalone Elastic Agent configuration:
Elastic Agent Standalone manifest sample.
[output trunctated ...] - data_stream: dataset: kubernetes.state_pod type: metrics metricsets: - state_pod add_metadata: true hosts: - 'kube-state-metrics:8080' period: 10s add_resource_metadata: namespace: enabled: true #use_regex_include: false include_labels: ["namespacelabel1"] #use_regex_exclude: false #exclude_labels: ["namespacelabel2"] node: enabled: true #use_regex_include: false include_labels: ["nodelabel2"] include_annotations: ["nodeannotation1"] #use_regex_exclude: false #exclude_labels: ["nodelabel3"] #deployment: false #cronjob: false
The add_resource_metadata
block configures the watcher’s enrichment functionality. See Kubernetes Provider for full description of add_resource_metadata. Same configuration parameters apply.
Note
editAlthough the add_kubernetes_metadata
processor is by default enabled when using elastic-agent, it is skipped whenever Kubernetes integration is detected.
On this page