- 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
- append
- community_id
- convert
- copy_fields
- decode_base64_field
- 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
- rate_limit
- registered_domain
- rename
- replace
- script
- syslog
- translate_ldap_attribute
- translate_sid
- truncate_fields
- urldecode
- Autodiscover
- Internal queue
- Logging
- HTTP endpoint
- Regular expression support
- Instrumentation
- Feature flags
- 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 state fields
- Monitor summary fields
- Synthetics types fields
- TCP layer fields
- TLS encryption layer fields
- Monitor
- Secure
- Troubleshoot
- Get help
- Debug
- Understand logged metrics
- 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
TCP options
editTCP options
editAlso see Common monitor options.
The options described here configure Heartbeat to connect via TCP and optionally verify the endpoint by sending and/or receiving a custom payload.
Example configuration:
- type: tcp id: my-host-services name: My Host Services hosts: ["myhost"] ports: [80, 9200, 5044] schedule: '@every 5s'
hosts
editA list of hosts to ping. The entries in the list can be:
-
A plain host name, such as
localhost
, or an IP address. If you specify this option, you must also specify a value forports
. If the monitor is configured to use SSL, Heartbeat establishes an SSL/TLS-based connection. Otherwise, it establishes a plain TCP connection. -
A hostname and port, such as
localhost:12345
. Heartbeat connects to the port on the specified host. If the monitor is configured to use SSL, Heartbeat establishes an SSL/TLS-based connection. Otherwise, it establishes a TCP connection. -
A full URL using the syntax
scheme://<host>:[port]
, where:-
scheme
is one oftcp
,plain
,ssl
ortls
. Iftcp
orplain
is specified, Heartbeat establishes a TCP connection even if the monitor is configured to use SSL. Iftls
orssl
is specified, Heartbeat establishes an SSL connection. However, if the monitor is not configured to use SSL, the system defaults are used (currently not supported on Windows). -
host
is the hostname. -
port
is the port number. Ifport
is missing in the URL, theports
setting is required.
-
ports
editA list of ports to ping if the host specified in hosts
does not contain a port number. It is generally preferable to use a single value here,
since each port will be monitored using a separate id
, with the given id
value,
used as a prefix in the Heartbeat data, and the configured name
shared across events
sent via this check.
check
editAn optional payload string to send to the remote host and the expected answer.
If no payload is specified, the endpoint is assumed to be available if the
connection attempt was successful. If send
is specified without receive
,
any response is accepted as OK. If receive
is specified without send
, no
payload is sent, but the client expects to receive a payload in the form of a
"hello message" or "banner" on connect.
Example configuration:
- type: tcp id: echo-service name: Echo Service hosts: ["myhost"] ports: [7] check.send: 'Hello World' check.receive: 'Hello World' schedule: '@every 5s'
proxy_url
editThe URL of the SOCKS5 proxy to use when connecting to the server. The value must be a URL with a scheme of socks5://.
If the SOCKS5 proxy server requires client authentication, then a username and password can be embedded in the URL as shown in the example.
proxy_url: socks5://user:password@socks5-proxy:2233
When using a proxy, hostnames are resolved on the proxy server instead of on
the client. You can change this behavior by setting the
proxy_use_local_resolver
option.
proxy_use_local_resolver
editA Boolean value that determines whether hostnames are resolved locally instead of being resolved on the proxy server. The default value is false, which means that name resolution occurs on the proxy server.
ssl
editThe TLS/SSL connection settings. If the monitor is
configured to use SSL, it will attempt an SSL
handshake. If check
is not configured, the monitor will only check to see if
it can establish an SSL/TLS connection. This check can fail either at TCP level
or during certificate validation.
Example configuration:
- type: tcp id: tls-mail name: TLS Mail hosts: ["mail.example.net"] ports: [465] schedule: '@every 5s' ssl: certificate_authorities: ['/etc/ca.crt'] supported_protocols: ["TLSv1.0", "TLSv1.1", "TLSv1.2"]
Also see SSL for a full description of the ssl
options.