Create a NAM monitor

With network availability monitors (NAM), you can check the availability of your hosts, devices, and services.

There are three types of NAM monitors: ICMP, TCP, and DNS. To learn more about them, see NAM types. You can create NAM monitors in Synthetic in latest Dynatrace or through API.

Configuration

With NAM monitors, you can include more than one step.

For example, if you want to monitor a group of 4 hosts with an ICMP test, you want to apply the same conditions (such as frequency, location executing test, and number of packets) for each host from your group.

NAM offers you the possibility of addressing this in multiple ways:

You need to define constraints for each monitor. Constraints are conditions that need to be met to consider the monitor’s execution successful. It is obligatory to define the Success rate constraint. See step-level constraints to learn more.

Create a NAM monitor

To create a NAM monitor in latest Dynatrace

Select type

The Create synthetic monitor page shows the types of synthetic monitor you can create.

Select Network monitor (NAM) to get started.

General

After you specify the general settings, select Continue.

Requests

The Requests section has two editing modes. You can switch back and forth between these modes.

Settings per request (you can add multiple requests) are:

If you want to create another request, select Add next request and specify the above for the next request.

After you specify all requests, select Continue.

Frequency and locations

In the Frequency and locations section, specify the frequency and locations.

After you specify the frequency and locations, select Continue.

Outage and Performance

In Outage handling, you can enable and configure the following settings related to problem and alert generation:

After you specify the outage and performance settings, select Continue.

Summary

In the Summary section, verify your settings.

After you review the summary, select Save to create your monitor or Back to go back and adjust your monitor settings.

Target filter

Target filter gives an option to filter hosts monitored by Dynatrace or custom devices having IP addresses. With this filter, you can select those two types of targets based on:

IP range and IP mask are filters for hosts known for the Dynatrace server, not an option to scan the network.

Syntax

Examples

Performance thresholds

The performance threshold metric is compared to metric calculated for each request within monitor/step. For example, if TCP port check monitor, tests on the same host port 80 and 443 separately, Dynatrace compares threshold TCP connection establishment time twice, once for port 80 and once for port 443.

There are three performance metrics for three types of NAM monitors:

Violating defined performance triggers a Problem (Slowdown).

Similarly to availability problems:

You can configure the way Dynatrace aggregates results for each packet for ICMP requests with single execution. Dynatrace supports AVG, MAX and MIN with AVG as the default method.

Define thresholds

You can define performance thresholds when configuring the request for your synthetic monitor. The defined performance threshold is the same for all requests within a single step. In cases, where there's a need to build a multi-step NAM monitor, it's possible to define various thresholds for each step.

To define thresholds

Violation reporting

Red color annotation over performance charts indicates the period of time during which the performance threshold is raised. Additionally, a threshold is drawn on the performance chart, and you can examine which requests are above the threshold.

You may narrow down the time range only to that for which the problem was active using zoom functionality.

Manage NAM monitors with API

To manage your NAM monitors via REST API

See Synthetic monitors API v2 for more details.

Available script configuration properties

optional

Monitors consist of requests, always of the same type (ICMP, TCP, or DNS).

If you don't provide the value, defaults will apply.

ICMP

TCP

DNS

Script configuration constraints

Constraints are conditions that need to be met to consider monitor’s execution successful. You need to define constraints for each monitor.

Step-level constraints

SUCCESS_RATE_PERCENT

required

This is an obligatory constraint for all monitors' request success rate. The default value is >=80%.

Percentage of successful requests in a step.

Actual success rate = ratio of the number of requests that didn't fail to all requests.

For example, if 1 request out of 6 has failed, the ratio is (6-1)/6 = 83.33%.

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

For requests with only one target, we suggest setting the constraints values to 100.

Request-level constraints

ICMP request constraints

ICMP_SUCCESS_RATE_PERCENT

required

This is an obligatory constraint for ICMP monitors request success rate. The default value is >=80%.

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": "80",
    "operator": ">"
  }
}

TCP request constraints

TCP_PORT_UNREACHABLE

optional

This is an optional constraint for TCP monitors. 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

DNS_STATUS_CODE by default is 1, having status code =0 is the simplest example of a successful query.

{
  "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.

{
  "type": "DNS_IP_ADDRESS",
  "properties": {
    "quantifier": "any",
    "recordType": "A",
    "operator": "=",
    "address": "54.208.9.71"
  }
}

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

DNS_RECORD_COUNT

Verifies the count of records of a given type.

{
  "type": "DNS_RECORD_COUNT",
  "properties": {
    "recordType": "A",
    "operator": ">",
    "value": "80"
  }
}

DNS_TIME_TO_LIVE

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

{
  "type": "DNS_TIME_TO_LIVE",
  "properties": {
    "quantifier": "any",
    "recordType": "A",
    "operator": ">=",
    "value": "80"
  }
}

DNS_RECORD_VALUE

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

{
  "type": "DNS_RECORD_VALUE",
  "properties": {
    "quantifier": "any",
    "recordType": "TXT",
    "operator": "contains",
    "sequence": "ms71815323"
  }
}

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