- Heartbeat Reference: other versions:
- Heartbeat overview
- Quick start: installation and configuration
- Set up and run
- Configure
- Monitors
- Task scheduler
- General settings
- Project paths
- Output
- Kerberos
- SSL
- Index lifecycle management (ILM)
- Elasticsearch index template
- Processors
- Define processors
- 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_json_fields
- decode_xml
- decode_xml_wineventlog
- decompress_gzip_field
- detect_mime_type
- dissect
- dns
- drop_event
- drop_fields
- extract_array
- fingerprint
- include_fields
- rate_limit
- registered_domain
- rename
- script
- translate_sid
- truncate_fields
- urldecode
- Autodiscover
- Internal queue
- Logging
- HTTP endpoint
- Regular expression support
- Instrumentation
- heartbeat.reference.yml
- How to guides
- Exported fields
- Beat fields
- Synthetics browser metrics fields
- Cloud provider metadata fields
- Common heartbeat monitor fields
- Docker fields
- ECS fields
- Host fields
- HTTP monitor fields
- ICMP fields
- Jolokia Discovery autodiscover provider fields
- Kubernetes fields
- Process fields
- Host lookup fields
- APM Service fields
- SOCKS5 proxy fields
- Monitor summary fields
- Synthetics types fields
- TCP layer fields
- TLS encryption layer fields
- Monitor
- Secure
- Troubleshoot
- Get help
- Debug
- Common problems
- Heartbeat uses too much bandwidth
- Error loading config file
- Found unexpected or unknown characters
- Logstash connection doesn’t work
- Publishing to Logstash fails with "connection reset by peer" message
- @metadata is missing in Logstash
- Not sure whether to use Logstash or Beats
- SSL client fails to connect to Logstash
- Monitoring UI shows fewer Beats than expected
- High RSS memory usage due to MADV settings
- Contribute to Beats
Configure general settings
editConfigure general settings
editYou can specify settings in the heartbeat.yml
config file to control the
general behavior of Heartbeat.
General configuration options
editThese options are supported by all Elastic Beats. Because they are common options, they are not namespaced.
Here is an example configuration:
name: "my-shipper" tags: ["service-X", "web-tier"]
name
editThe name of the Beat. If this option is empty, the hostname
of the server is
used. The name is included as the agent.name
field in each published transaction. You can
use the name to group all transactions sent by a single Beat.
Example:
name: "my-shipper"
tags
editA list of tags that the Beat includes in the tags
field of each published
transaction. Tags make it easy to group servers by different logical properties.
For example, if you have a cluster of web servers, you can add the "webservers"
tag to the Beat on each server, and then use filters and queries in the Kibana
web interface to get visualisations for the whole group of servers.
Example:
tags: ["my-service", "hardware", "test"]
fields
editOptional fields that you can specify to add additional information to the
output. Fields can be scalar values, arrays, dictionaries, or any nested
combination of these. By default, the fields that you specify here will be
grouped under a fields
sub-dictionary in the output document. To store the
custom fields as top-level fields, set the fields_under_root
option to true.
Example:
fields: {project: "myproject", instance-id: "574734885120952459"}
fields_under_root
editIf this option is set to true, the custom fields are
stored as top-level fields in the output document instead of being grouped under
a fields
sub-dictionary. If the custom field names conflict with other field
names, then the custom fields overwrite the other fields.
Example:
fields_under_root: true fields: instance_id: i-10a64379 region: us-east-1
processors
editA list of processors to apply to the data generated by the beat.
See Processors for information about specifying processors in your config.
max_procs
editSets the maximum number of CPUs that can be executing simultaneously. The default is the number of logical CPUs available in the system.
ElasticON events are back!
Learn about the Elastic Search AI Platform from the experts at our live events.
Register now