NAM monitor metrics
Metrics and dimensions
Dimensions (all network availability monitors)
multi_protocol.request.type
icmp
, tcp
multi_protocol.request.target_address
54.171.216.19
dt.entity.host
HOST-024C103F7F86A290
dt.entity.synthetic_location
SYNTHETIC_LOCATION-A4F834D72840EFC1
dt.entity.multiprotocol_monitor
MULTIPROTOCOL_MONITOR-3F6C9D500287BBAF
multi_protocol.step.id
1
multi_protocol.request.id
2
multi_protocol.result.status
HEALTHY
, CONSTRAINT_VIOLATED
multi_protocol.result.status.code
0
, 1401
Monitor metrics (all network availability monitors)
dt.synthetic.multi_protocol.execution_time
(latest Dynatrace)
builtin:synthetic.multiProtocol.executionTime
(previous Dynatrace)
dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
Metric available only if visit execution took place; both start time and end times must be available.
dt.synthetic.multi_protocol.success_rate
(latest Dynatrace)
builtin:synthetic.multiProtocol.successRate
(previous Dynatrace)
dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
We take into account steps that were actually executed rather than steps intended to be executed. For example, with 2 successful steps, 1 failed step, and 8 not started, the ratio is 2/3, or 66.67%.
dt.synthetic.multi_protocol.availability
(latest Dynatrace)
builtin:synthetic.multiProtocol.availability
(previous Dynatrace)
dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
- 100% for code=
0
: HEALTHY
, SCRIPT_FINISH
, SKIPPED
- 0% for error status codes such as
1401 - CONSTRAINT_VIOLATED
dt.synthetic.multi_protocol.executions
(latest Dynatrace)
builtin:synthetic.multiProtocol.executions
(previous Dynatrace)
dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.result.status
multi_protocol.result.status.code
Step metrics (all network availability monitors)
dt.synthetic.multi_protocol.step.execution_time
(latest Dynatrace)
builtin:synthetic.multiProtocol.step.executionTime
(previous Dynatrace)
multi_protocol.request.type
dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
Metric available only if step execution took place, with a well-defined end time; therefore, it's not available for skipped steps.
dt.synthetic.multi_protocol.step.success_rate
(latest Dynatrace)
builtin:synthetic.multiProtocol.step.successRate
(previous Dynatrace)
multi_protocol.request.type
dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
If a step was skipped (by any of its preceding steps), it doesn't have a success rate; we treat it as if it wasn't executed.
If a step doesn't have executed requests (because its pre-execution script failed or issued
SCRIPT_FINISH
), we return the value 0%
(for failures) or 100%
(for finished).For example, with 2 successful, 1 failed, and 4 skipped requests, the ratio is 6/7, or 85.71%.
dt.synthetic.multi_protocol.step.availability
(latest Dynatrace)
builtin:synthetic.multiProtocol.step.availability
(previous Dynatrace)
multi_protocol.request.type
dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
- 100% for code=
0
: HEALTHY
, SCRIPT_FINISH
, SKIPPED
- 0% for error status codes such as
1401 - CONSTRAINT_VIOLATED
dt.synthetic.multi_protocol.step.executions
(latest Dynatrace)
builtin:synthetic.multiProtocol.step.executions
(previous Dynatrace)
multi_protocol.request.type
dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
multi_protocol.result.status
multi_protocol.result.status.code
Request metrics (all network availability monitors)
dt.synthetic.multi_protocol.request.availability
(latest Dynatrace)
builtin:synthetic.multiProtocol.request.availability
(previous Dynatrace)
multi_protocol.request.type
multi_protocol.request.target_address
dt.entity.host
(only for monitors with filter
defined)dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
multi_protocol.request.id
- 100% for code=
0
: HEALTHY
, SCRIPT_FINISH
, SKIPPED
- 0% for error status codes such as
1401 - CONSTRAINT_VIOLATED
dt.synthetic.multi_protocol.request.executions
(latest Dynatrace)
builtin:synthetic.multiProtocol.request.executions
(previous Dynatrace)
multi_protocol.request.type
multi_protocol.request.target_address
dt.entity.host
(only for monitors with filter
defined)dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
multi_protocol.request.id
multi_protocol.result.status
multi_protocol.result.status.code
ICMP monitor metrics
dt.synthetic.multi_protocol.icmp.success_rate
(latest Dynatrace)
builtin:synthetic.multiProtocol.icmp.successRate
(previous Dynatrace)
multi_protocol.request.type
multi_protocol.request.target_address
dt.entity.host
(only for monitors with filter defined)dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
multi_protocol.request.id
Doesn't take into account the configured number of packets to be sent.
For example, out of 10 packets to be sent, if 5 were sent and 4 were received, the ratio is 4/5, or 80.00%.
dt.synthetic.multi_protocol.icmp.packets_sent
(latest Dynatrace)
builtin:synthetic.multiProtocol.icmp.packetsSent
(previous Dynatrace)
multi_protocol.request.type
multi_protocol.request.target_address
dt.entity.host
(only for monitors with filter defined)dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
multi_protocol.request.id
dt.synthetic.multi_protocol.icmp.packets_received
(latest Dynatrace)
builtin:synthetic.multiProtocol.icmp.packetsReceived
(previous Dynatrace)
multi_protocol.request.type
multi_protocol.request.target_address
dt.entity.host
(only for monitors with filter defined)dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
multi_protocol.request.id
dt.synthetic.multi_protocol.icmp.round_trip_time
(latest Dynatrace)
builtin:synthetic.multiProtocol.icmp.roundTripTime
(previous Dynatrace)
multi_protocol.request.type
multi_protocol.request.target_address
dt.entity.host
(only for monitors with filter defined)dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
multi_protocol.request.id
dt.synthetic.multi_protocol.icmp.request_execution_time
(latest Dynatrace)
builtin:synthetic.multiProtocol.icmp.requestExecutionTime
(previous Dynatrace)
multi_protocol.request.type
multi_protocol.request.target_address
dt.entity.host
(only for monitors with filter defined)dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
multi_protocol.request.id
This metric is always provided, even if actual request execution did not take place (for example, because of exceptions or timeouts).
Diagnostic metric—allows for validation of external ping process execution time.
TCP monitor dimensions
multi_protocol.request.tcp_port_number
665
TCP monitor metrics
dt.synthetic.multi_protocol.tcp.connection_time
(latest Dynatrace)
builtin:synthetic.multiProtocol.tcp.connectionTime
(previous Dynatrace)
multi_protocol.request.type
multi_protocol.request.target_address
dt.entity.host
(only for monitors with filter defined)dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
multi_protocol.request.id
multi_protocol.request.tcp_port_number
Metric available only if request execution took place (with no exceptions or timeouts), with a well-defined end time
DNS monitor dimensions
multi_protocol.request.dns_record_type
A
, AAAA
, CNAME
DNS monitor metrics
dt.synthetic.multi_protocol.dns.resolution_time
(latest Dynatrace)
builtin:synthetic.multiProtocol.dns.resolutionTime
(previous Dynatrace)
multi_protocol.request.type
multi_protocol.request.target_address
dt.entity.host
(only for monitors with filter defined)dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
multi_protocol.request.id
Metric available only if request execution took place (with no exceptions or timeouts), with a well-defined end time
DQL queries to extract data
Latest Dynatrace
Use DQL queries to extract data with metrics and dimensions.
The following examples use Notebooks to 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 the 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
.
To display the status of the TCP connection for an IP-port pair, we use the dt.synthetic.multi_protocol.request.executions
metric and splitting it by the dimensions:
multi_protocol.request.target_address
multi_protocol.request.tcp_port_number
multi_protocol.result.status
In this example:
- Each host has the ports
22
(SSH) and8080
(HTTP server) open, and each connection to the hosts on these ports succeeds with theHEALTHY
status. - No service uses the standard HTTP port
80
. Therefore, connections to all hosts on that port fail with theTCP 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.
To check typical time taken for a successful connection to the target port for a host, we use the average of the dt.synthetic.multi_protocol.tcp.connection_time
metric split by the dimensions:
dt.entity.host
multi_protocol.request.target_address
multi_protocol.request.tcp_port_number
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), so 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"
Execution statuses
All network availability monitors
0 HEALTHY
-1 UNEXPECTED_ERROR
1401 CONSTRAINT_VIOLATED
1604 VALIDATION_ERROR
12013 UNKNOWN_HOST
- Invalid hostname
- DNS server unreachable
- DNS cache issues
- Firewall or proxy interference
12033 Execution timeout
- Network issues
- Slow or unresponsive server or service
- Connection blocked by firewall rules
- Timeout is too small.
TCP monitor execution statuses
22000 TCP socket connection error
java.net.SocketException
is thrown during the connection attempt. Possible causes:- Service is not listening on the specified port.
- Service reached resource or connection limit.
- Service became unavailable during the socket connection process.