Dynatrace version 1.296+ ActiveGate version 1.295+
Network availability monitoring (NAM) allows you to monitor the availability of remote hosts or services over the network when an HTTP/HTTPS endpoint isn't available.
You can use NAM for infrastructure-related use cases or to deepen the root cause analysis for HTTP and browser monitors.
You can create synthetic network availability monitors of ICMP, TCP, or DNS type.
You can configure NAM monitors and access their performance results in Synthetic in latest Dynatrace. See create a NAM monitor to learn how to set up your monitor in Synthetic or via API.
There are three types of network availability monitors.
To find out more about NAM types, see available script configuration properties.
Latest Dynatrace
In Synthetic, to display the preview panel for a monitor, select the monitor's name in the Monitor name column of the Synthetic monitors page.
To browse between your monitors, open the preview panel for any monitor and then select another monitor name to switch the preview to the newly selected monitor. Filters are persistent.
The preview panel shows:
Use the controls in the upper-right corner of the preview panel to:
On-demand monitor execution via web UI is available as part of DPS license only. The retention period for data from monitor execution is 35 days.
For Non-DPS license users, monitor execution is possible via API. You can access the results for the last 6 hours.
To display a reporting page for your monitor, select View details in upper-right corner of the preview panel.
The default reporting pages consists of:
Tiles displaying information at a glance about global outages, active issues, number of affected locations, availability, total downtime, and duration.
Availability—A chart of availability over time. Availability for NAM monitors is calculated by comparing the request success rate to defined constraints. A period when availability is 0% is called an outage.
You can narrow the chart's time range to cover just the outage period. This allows you to identify, for example, requests that negatively impact availability. By default, the availability chart is collapsed when showing 0% or 100% for the whole time range. To open it, simply select Availability.
Success rate—A chart of the success rate over time, where the success rate is the percentage of all executed requests that were sucessful.
Performance—A chart of performance over time, where performance is calculated as an average for all successful requests. Note that performance metrics are not reported for failed requests.
Problems are created on the monitor level.
To receive alerts when problems are generated
To analyze a problem
There are certain limitations when using network availability monitors. You can find out more about them below.
The maximum number of network activities executed per network availability monitor is 1,000. Network activity is a single DNS request, single TCP request, or single ICMP packet. Dynatrace may use multiple packets within a single ICMP request, if configured.
If a monitor uses a 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 the target filter is resolved before the monitor's execution into the actual list of addresses.
The number of requests depends on the number of hosts matching the filter. For example, when monitoring an entire host group or filtering the monitored hosts using a subnet with a wide IP range.
You can have up to 5,000 NAM monitors per environment. Other types of monitors don't contribute to this limit.
Network availability monitors are supported only on private Synthetic locations.
Network availability monitors are supported on containerized Synthetic-enabled ActiveGate deployments, but additional permissions are required for ICMP tests.
To enable ICMP request type for NAM execution
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 doesn't 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: trueprivileged: falseallowPrivilegeEscalation: truerunAsNonRoot: truecapabilities:drop: ["all"]add: ["NET_RAW"]