- 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
- 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
Enable custom settings in an agent policy
editEnable custom settings in an agent policy
editIn certain cases it can be useful to enable custom settings that are not available in Fleet, and that override the default behavior for Elastic Agent. Examples include limiting the amount of CPU consumed by an agent, configuring the agent download timeout, and overriding the default port used for monitoring.
Use these custom settings with caution as they are intended for special cases. We do not test all possible combinations of settings which will be passed down to the components of Elastic Agent, so it is possible that certain custom configurations can result in breakages.
Limit CPU usage
editIf you need to limit the amount of CPU consumption you can use the agent.limits.go_max_procs
configuration option. This parameter limits the number of operating system threads that can be executing Go code simultaneously in each Go process. The agent.limits.go_max_procs
option accepts an integer value not less than 0
, which is the default value that stands for "all available CPUs".
The agent.limits.go_max_procs
limit applies independently to the agent and each underlying Go process that it supervises. For example, if Elastic Agent is configured to supervise two Beats with agent.limits.go_max_procs: 2
in the policy, then the total CPU limit is six, where each of the three processes (one Elastic Agent and two Beats) may execute independently on two CPUs.
This setting is similar to the Beats max_procs
setting. For more detail, refer to the GOMAXPROCS function in the Go runtime documentation.
To enable agent.limits.go_max_procs
, run a Fleet API request from the Kibana Dev Tools console to override your current Elastic Agent policy and add the go_max_procs
parameter. For example, to limit Go processes supervised by Elastic Agent to two operating system threads each, run:
PUT kbn:/api/fleet/agent_policies/<policy-id> { "name": "<policy-name>", "namespace": "default", "overrides": { "agent": { "limits": { "go_max_procs": 2 } } } }
Configure the agent download timeout
editYou can configure the the amount of time that Elastic Agent waits for an upgrade package download to complete. This is useful in the case of a slow or intermittent network connection.
PUT kbn:/api/fleet/agent_policies/<policy-id> { "name": "Test policy", "namespace": "default", "overrides": { "agent": { "download": { "timeout": "120s" } } } }
Override the default monitoring port
editYou can override the default port that Elastic Agent uses to send monitoring data. It’s useful to be able to adjust this setting if you have an application running on the machine on which the agent is deployed, and that is using the same port.
PUT kbn:/api/fleet/agent_policies/<policy-id> { "name": "Agent policy 1", "namespace": "default", "overrides": { "agent.monitoring.http.port": 6792 } }