Latest Dynatrace
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.
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 can define 4 separate tests, one per host. The benefit of this approach is that Dynatrace triggers a separate problem for each host and you can assign separate notifications for each one. You can also adjust test parameters for each host separately.
You can define a single test with 4 requests (within 1 step). The same ICMP checks are executed, but there will be differences in reporting and alerting. The number or percentage of hosts that are down is reported with the Requests Success rate metric. You can configure a customized threshold for failing the whole monitor. For example, if it's OK that 1 out of 4 hosts is down, because of rolling out an update, you can define it on the >=75%
level. There's always a single problem generated for a monitor, yet still, it contains detailed info about hosts that don't respond. Another benefit of this approach is easier maintenance (adjusting single setting for all 4 hosts).
Finally, filters offer defining tests against dynamically changing structure, for example if you want to define ICMP tests against a given host group, you don't need to adjust the NAM monitor test after the host group configuration change.
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.
To create a NAM monitor in latest Dynatrace
The Create synthetic monitor page shows the types of synthetic monitor you can create.
Select Network monitor (NAM) to get started.
DNS
, ICMP
, or TCP
.After you specify the general settings, select Continue.
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.
Use Duplicate to duplicate a request and then edit it from that point instead of starting from scratch each time you add a request.
After you specify all requests, select Continue.
In the Frequency and locations section, specify the frequency and locations.
1 min
, 2 min
, 5 min
, 10 min
, 15 min
, 30 min
, or 1 h
) or select On demand only
for manual execution.After you specify the frequency and locations, select Continue.
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.
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 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:
type
)tag
)hostId
) (deprecated, works for hosts only, use entity ID instead)entityId
)hostGroup
)managementZone
)ipMask
)ipRange
)processGroupInstance
)interfacesOf
)extensionName
)IP range and IP mask are filters for hosts or devices known for the Dynatrace server, not an option to scan the network.
AND
and OR
(case insensitive)==
and !=
!=
.*
(selects all hosts monitored by Dynatrace)tag == tagname or hostGroup == group1
(tag == tagname1:tagvalue1 or tag == tagname1:tagvalue2) and (hostGroup == group1 or managementZone == zone1)
tag != tagname1 and tag != tagname2:tagvalue
tag == tagname:tagvalue and (managementZone == zone1 or managementZone == zone2)
tag == "[tagwithbrackets and spaces]":"value, with, commas, and, spaces"
ipMask == 127.0.0.1/24
hostId == HOST-000123
type == CUSTOM_DEVICE and ipMask == 172.17.0.2/24
entityId == HOST-045BFCDA3F507D30 or entityId == CUSTOM_DEVICE-13081D4B74B3E2C8
type == HOST and processGroupInstance == PROCESS_GROUP_INSTANCE-07611353BB98908C
type == CUSTOM_DEVICE and interfacesOf == CUSTOM_DEVICE-E1A88946BF04D5E7
type == CUSTOM_DEVICE and extensionName == "Docker devices"
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.
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
Follow the steps described in Create a NAM monitor section.
In the Requests step, scroll down the page and see Performance thresholds alerting section.
Select Generate a problem and send an alert on performance threshold violations. check box.
Turn on Advanced performance thresholds settings toggle.
In this section you can set the Number of request executions in analyzed sliding window and the Number of violating request executions in analyzed sliding window. For de-alerting samples we require n
most recent non-violating request executions.
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.