Network availability monitors

Preview

Network availability monitoring enables you create synthetic network availability monitors of type ICMP, TCP, or DNS.

The Synthetic - Network availability monitors API is part of the Environment API v2. Check the API Explorer (section-api#api-explorer) for more information.

Limitations

Number of requests

The maximum number of requests executed per network availability monitor is 1000.

If a monitor uses target filter, it might not be possible to precisely predict the number of requests in advance of execution (for example, when monitoring an entire host group or a subnet with a wide IP range). In such cases, the limit is applied when target filter is resolved before the monitor's execution into the actual list of addresses.

Operating system

Network availability monitors are not supported on Synthetic-enabled ActiveGate on Windows hosts.

Deployment type

Network availability monitors are supported only on private Synthetic locations.

Containerized locations

Network availability monitors are supported on containerized Synthetic-enabled ActiveGate deployments, but additional permissions are required.

ICMP monitors use the ping executable, which requires the CAP_NET_RAW capability set for the container executing the requests (synthetic-vuc). Additionally, the allowPrivilegeEscalation property of securityContext for this container has to be set to true, because the process that launches the ping executable does not have the required privileges set by default.

The entire securityContext for the synthetic-vuc container with enabled network availability monitors should look as follows.

securityContext:
  readOnlyRootFilesystem: true
  privileged: false
  allowPrivilegeEscalation: true
  runAsNonRoot: true
  capabilities:
    drop: ["all"]
    add: ["NET_RAW"]

POST create a multi-protocol monitor

Monitor schema SyntheticMultiProtocolMonitorUpdateDto

required

steps schema SyntheticMultiProtocolMonitorStepDto

requestConfigurations schema SyntheticMultiProtocolRequestConfigurationDto

constraints schema SyntheticMultiProtocolMonitorConstraintDto

syntheticMonitorOutageHandlingSettings schema SyntheticMonitorOutageHandlingSettingsDto

Examples

{
  "name": "Sample NAM monitor with ICMP step",
  "type": "MULTI_PROTOCOL",
  "frequencyMin": "1",
  "locations": [
    "SYNTHETIC_LOCATION-8A91FE7982E24C06"
  ],
  "active": "true",
  "steps": [
    {
      "name": "ICMP step 1",
      "requestType": "ICMP",
      "targetFilter": null,
      "targetList": [
        "127.0.0.1",
        "127.0.0.2",
        "127.0.0.3",
        "127.0.0.4"
      ],
      "name": "ICMP step 1",
      "requestType": "ICMP",
      "targetFilter": null,
      "targetList": [
        "127.0.0.1",
        "127.0.0.2",
        "127.0.0.3",
        "127.0.0.4"
      ],
      "constraints": [
        {
          "type": "SUCCESS_RATE_PERCENT",
          "properties": {
            "value": "49",
            "operator": ">"
          }
        }
      ],
      "properties": {
        "ICMP_NUMBER_OF_PACKETS": "3",
        "ICMP_TIMEOUT_FOR_REPLY": "PT1S",
        "ICMP_TIMEOUT_FOR_REPLY": "PT1S"
      },
      "requestConfigurations": [
        {
          "constraints": [
            {
              "type": "ICMP_SUCCESS_RATE_PERCENT",
              "properties": {
                "value": "100"
              }
            }
          ]
        }
      ]
    }
  ],
  "syntheticMonitorOutageHandlingSettings": {
    "globalOutages": true,
    "localOutages": false,
    "globalConsecutiveOutageCountThreshold": 1,
    "localLocationOutageCountThreshold": null,
    "localConsecutiveOutageCountThreshold": null
  },
  "tags": [
    {
      "key": "my-icmp-monitor"
    },
    {
      "key": "env",
      "value": "UAT"
    }
  ]
}

{
  "name": "Sample NAM monitor with TCP step",
  "type": "MULTI_PROTOCOL",
  "frequencyMin": "1",
  "locations": [
    "SYNTHETIC_LOCATION-8A91FE7982E24C06"
  ],
  "active": "true",
  "steps": [
    {
      "name": "TCP step 1",
      "requestType": "TCP",
      "targetFilter": "hostGroup == my-host-group0 and ipRange == 45-55.*.*.*",
      "targetList": [],
      "name": "TCP step 1",
      "requestType": "TCP",
      "targetFilter": "hostGroup == my-host-group0 and ipRange == 45-55.*.*.*",
      "targetList": [],
      "constraints": [
        {
          "type": "SUCCESS_RATE_PERCENT",
          "properties": {
            "value": "66",
            "operator": ">="
          }
        }
      ],
      "properties": {
        "TCP_PORT_RANGES": "22,443,5501-5509"
      },
      "requestConfigurations": [
        {
          "constraints": []
        }
      ]
    }
  ],
  "syntheticMonitorOutageHandlingSettings": {
    "globalOutages": true,
    "localOutages": false,
    "globalConsecutiveOutageCountThreshold": 1,
    "localLocationOutageCountThreshold": null,
    "localConsecutiveOutageCountThreshold": null
  },
  "tags": [
    {
      "key": "my-tcp-monitor"
    },
    {
      "key": "env",
      "value": "UAT"
    }
  ]
}

{
  "name": "Sample NAM monitor with DNS step",
  "type": "MULTI_PROTOCOL",
  "frequencyMin": 1,
  "locations": [
    "SYNTHETIC_LOCATION-6F3084B1ECD81DE1"
  ],
  "active": true,
  "steps": [
    {
      "name": "DNS step 1",
      "requestType": "DNS",
      "targetFilter": null,
      "targetList": [
        "dynatrace.com"
      ],
      "name": "DNS step 1",
      "requestType": "DNS",
      "targetFilter": null,
      "targetList": [
        "dynatrace.com"
      ],
      "constraints": [
        {
          "type": "SUCCESS_RATE_PERCENT",
          "properties": {
            "value": "90",
            "operator": ">="
          }
        }
      ],
      "properties": {
        "DNS_RECORD_TYPES": "A,AAAA",
        "DNS_SERVER": "10.102.40.11"
      },
      "requestConfigurations": [
        {
          "constraints": [
            {
              "type": "DNS_STATUS_CODE",
              "properties": {
                "status": "NOERROR",
                "operator": "="
              }
            }
          ]
        }
      ]
    }
  ],
  "syntheticMonitorOutageHandlingSettings": {
    "globalOutages": true,
    "localOutages": false,
    "globalConsecutiveOutageCountThreshold": 1,
    "localLocationOutageCountThreshold": null,
    "localConsecutiveOutageCountThreshold": null
  },
  "tags": [
    {
      "key": "my-dns-monitor"
    },
    {
      "key": "env",
      "value": "UAT"
    }
  ]
}

Available script configuration properties

ICMP

TCP

DNS

Script configuration constraints

Constraints describe success conditions.

Step-level constraints

SUCCESS_RATE_PERCENT

Percentage of successful requests in a step

Actual success rate = ratio of the number of requests that didn't fail (successful + skipped requests) to all requests

For example, if 1 request has failed, 2 requests are skipped, and 3 requests are successful, the ratio is (2+3)/6 = 83.33%.

{
  "type": "SUCCESS_RATE_PERCENT",
  "properties": {
    "value": "83",
    "operator": ">"
  }
}

ICMP request constraints

ICMP_SUCCESS_RATE_PERCENT

Percentage of successful pings (echo requests) in a request

Actual success rate = ratio of number of the packets received to number of packets sent

For example, if 5 packets were sent and 4 packets were received, the ratio is 4/5 = 80.00%.

{
  "type": "ICMP_SUCCESS_RATE_PERCENT",
  "properties": {
    "value": "79",
    "operator": ">"
  }
}

TCP request constraints

TCP_PORT_UNREACHABLE

This is a special constraint that inverts the execution status for TCP requests. It should be applied if it's expected that the port being checked is unreachable.

This constraint has no configuration properties.

If this constraint is applied:

{
  "type": "TCP_PORT_UNREACHABLE",
  "properties": {}
}

DNS request constraints

DNS_STATUS_CODE

Verifies the DNS response status code, which indicates whether a query was successful or not.

{
  "type": "DNS_STATUS_CODE",
  "properties": {
    "operator": "=",
    "statusCode": "0"
  }
}

{
  "type": "DNS_STATUS_CODE",
  "properties": {
    "operator": "=",
    "status": "NOERROR"
  }
}

DNS_IP_ADDRESS

Verifies the IP address value returned in A/AAAA records.

{
  "constraintType": "DNS_IP_ADDRESS",
  "attributes": {
    "quantifier": "any",
    "recordType": "A",
    "operator": "=",
    "address": "54.208.9.71"
  }
}

{
  "constraintType": "DNS_IP_ADDRESS",
  "attributes": {
    "quantifier": "all",
    "recordType": "A",
    "operator": "in",
    "subnet": "10.102.44.0/24"
  }
}

DNS_RECORD_COUNT

Verifies the count of records of a given type.

{
  "constraintType": "DNS_RECORD_COUNT",
  "attributes": {
    "recordType": "A",
    "operator": ">",
    "value": "0"
  }
}

DNS_TIME_TO_LIVE

Verifies the time to live (TTL) of records of a given type.

{
  "constraintType": "DNS_TIME_TO_LIVE",
  "attributes": {
    "quantifier": "any",
    "recordType": "A",
    "operator": ">=",
    "value": "30"
  }
}

DNS_RECORD_VALUE

Verifies the raw value of records of a given type, with the value format depending on the record type.

{
  "constraintType": "DNS_RECORD_VALUE",
  "attributes": {
    "quantifier": "any",
    "recordType": "TXT",
    "operator": "contains",
    "sequence": "ms71815323"
  }
}

{
  "constraintType": "DNS_RECORD_VALUE",
  "attributes": {
    "quantifier": "any",
    "recordType": "TXT",
    "operator": "matches",
    "pattern": "\"v=spf1 include:*"
  }
}

Target filter

With the target filter, you can select hosts monitored by Dynatrace based on tags (tag), host ID (hostId), host ID (hostId), host groups (hostGroup), management zones (managementZone), IP mask (ipMask) and IP range (ipRange).

Syntax

Examples

Metrics and dimensions

Dimensions (all network availability monitors)

Monitor metrics (all network availability monitors)

Step metrics (all network availability monitors)

Request metrics (all network availability monitors)

ICMP monitor metrics

TCP monitor dimensions

TCP monitor metrics

DNS monitor dimensions

DNS monitor metrics

Execution statuses

All network availability monitors

TCP monitor execution statuses

Sample DQL queries to extract data

Latest Dynatrace

These examples use Notebooks and demonstrate how to work with the results of network availability monitors. They use result metrics as a starting point to explore possibilities of extracting and interpreting data with DQL.

Host entity status for ICMP requests

The monitor MULTIPROTOCOL_MONITOR-5C2F92334DF71A90 executes ICMP requests and filters monitored hosts with "targetFilter": "hostGroup == e2e-synthetic-private-location" (which resolves to about 26 hosts). By using the dt.synthetic.multi_protocol.request.executions metric and splitting it by the dt.entity.host and multi_protocol.result.status dimensions, we can display the status of the connection to a particular monitored host entity in this host group. Some hosts do not fulfill expected success rate; instead of being HEALTHY, their requests are marked as CONSTRAINT_VIOLATED.

Timeseries status = avg(dt.synthetic.multi_protocol.request.executions),
by:{dt.entity.host, multi_protocol.result.status},
filter: dt.entity.multiprotocol_monitor == "MULTIPROTOCOL_MONITOR-5C2F92334DF71A90"

Number of ICMP packets sent and received

The monitor MULTIPROTOCOL_MONITOR-548C3CD54183CED9 executes ICMP requests to hosts with the explicitly defined IP addresses, 18.x.x.x, 10.x.x.x, and 34.x.x.x. Each of these IP addresses maps to a distinct host. We use the sum of the dt.synthetic.multi_protocol.icmp.packets_sent and the sum of the dt.synthetic.multi_protocol.icmp.packets_received metrics to get insight into how many packets were sent and received. We split results by the multi_protocol.request.target_address dimension and filter data for 18.x.x.x and 10.x.x.x only. For 18.x.x.x, the same number of packets were received as were sent, but for 10.x.x.x, all packets are lost and none were received.

timeseries {
  packets_sent = sum(dt.synthetic.multi_protocol.icmp.packets_sent),
  packets_received= sum(dt.synthetic.multi_protocol.icmp.packets_received)
},
by:{multi_protocol.request.target_address},
filter: dt.entity.multiprotocol_monitor == "MULTIPROTOCOL_MONITOR-548C3CD54183CED9"
    AND (
        multi_protocol.request.target_address == "18.x.x.x"
        OR multi_protocol.request.target_address == "10.x.x.x"
    )

Target status for TCP requests

The monitor MULTIPROTOCOL_MONITOR-74E68F22FF5E9227 executes TCP requests to hosts from a host group that resolves to the IP addresses 18.x.x.x, 34.x.x.x, and 44.x.x.x. By using the dt.synthetic.multi_protocol.request.executions metric and splitting it by the multi_protocol.request.target_address, multi_protocol.request.tcp_port_number, and multi_protocol.result.status dimensions, we can display the status of the TCP connection for an IP-port pair. Each host has the ports 22 (SSH) and 8080 (HTTP server) open, and each connection to the hosts on these ports succeeds with the HEALTHY status. No service uses the standard HTTP port 80. Therefore, connections to all hosts on that port fail with the TCP socket connection error status. Note that results of this query can be limited to just successful requests by filtering by the multi_protocol.result.status.code dimension (code == 0).

timeseries status = sum(dt.synthetic.multi_protocol.request.executions),
by: {multi_protocol.request.target_address, multi_protocol.request.tcp_port_number, multi_protocol.result.status},
filter: dt.entity.multiprotocol_monitor == "MULTIPROTOCOL_MONITOR-74E68F22FF5E9227"
//  and multi_protocol.result.status.code == 0

TCP connection time to target port

The monitor MULTIPROTOCOL_MONITOR-74E68F22FF5E9227 executes TCP requests to hosts from a host group that resolves to the IP addresses 18.x.x.x, 34.x.x.x, and 44.x.x.x. In this example, instead of IP addresses, we split the results by monitored host entity IDs. We use average of the dt.synthetic.multi_protocol.tcp.connection_time metric split by the dt.entity.host, multi_protocol.request.target_address, and multi_protocol.request.tcp_port_number dimensions to check typical time taken for a successful connection to the target port for a host. Only ports 22 (SSH) and 8080 (HTTP server) are open, and these are the only ports for which dt.synthetic.multi_protocol.tcp.connection_time is available. The hosts are effectively in different geographical locations (Ohio, Oregon, and North Virginia in the United States), a difference in connection times is expected.

timeseries duration = avg(dt.synthetic.multi_protocol.tcp.connection_time),
by:{dt.entity.host, multi_protocol.request.target_address, multi_protocol.request.tcp_port_number},
filter: dt.entity.multiprotocol_monitor == "MULTIPROTOCOL_MONITOR-74E68F22FF5E9227"