Following on the part I of this series that discussed ICMP,  the focus of this post is the Elastic Heartbeat time metrics – TCP Monitors.

Monitors Configuration

In order to understand the Heartbeat TCP  monitor time metrics I’ve set up the following monitors:

• tcp_simple – establishes connection with test.smtp.org on port 25.
• tcp_check_resolve – verifies receiving a 220 response from the same server after connecting

You can see the extract from the heartbeat.yml configuration file relevant to these TCP monitors

- type: tcp
  name: tcp_simple
  schedule: '@every 60s'
  hosts: ["test.smtp.org:25"]

- type: tcp
  name: tcp_check_resolve
  schedule: '@every 60s'
  hosts: ["test.smtp.org:25"]
  check.receive: "220 test.smtp.org ESMTP Sendmail 8.16.0.16 ready"

The data returned by the monitors

After letting it run for a while  let’s check what data Heartbeat is sending to Elasticsearch

For the tcp_simple monitor

{
  "@timestamp": "2018-03-18T19:28:23.336Z",
  "beat": {
    "hostname": "DESKTOP-9LR2P8D",
    "name": "DESKTOP-9LR2P8D",
    "version": "5.6.1"
  },
  "duration": {
    "us": 937865
  },
  "host": "test.smtp.org",
  "ip": "52.2.168.164",
  "monitor": "tcp_simple-plain@test.smtp.org:25",
  "port": "25",
  "resolve_rtt": {
    "us": 654323
  },
  "scheme": "tcp",
  "tcp_connect_rtt": {
    "us": 282543
  },
  "type": "tcp_simple",
  "up": true
}

For the tcp_check_resolve monitor

{
  "@timestamp": "2018-03-18T19:28:23.336Z",
  "beat": {
    "hostname": "DESKTOP-9LR2P8D",
    "name": "DESKTOP-9LR2P8D",
    "version": "5.6.1"
  },
  "duration": {
    "us": 6892437
  },
  "host": "test.smtp.org",
  "ip": "52.2.168.164",
  "monitor": "tcp_check_resolve-plain@test.smtp.org:25",
  "port": "25",
  "resolve_rtt": {
    "us": 654323
  },
  "scheme": "tcp",
  "tcp_connect_rtt": {
    "us": 283541
  },
  "type": "tcp_check_resolve",
  "up": true,
  "validate_rtt": {
    "us": 5954572
  }
}

Time Metrics

The tcp_simple monitor has only 3 time metrics – duration, resolve_rtt and tcp_connect_rtt. While the more “complex” tcp_check_resolve monitor has an additional validate_rtt. The first 3 metrics description will be almost the same as for the ICMP Monitor metrics while the validate_rtt is “new” to us.

• duration – Total monitoring test duration
• resolve_rtt – Duration required to resolve an IP from hostname.
• tcp_connect_rtt – Duration required to establish a TCP connection based on already available IP address.
• validate_rtt –  Duration of validation step based on existing TCP connection.

Visualisation

TBC