NAM monitor metrics

Metrics and dimensions

Dimensions (all network availability monitors)

NameTypeDescriptionExample value
multi_protocol.request.typestringType of requesticmp, tcp
multi_protocol.request.target_addressstringAddress of target entity54.171.216.19
dt.entity.hoststringIf available, monitored entity ID for targetHOST-024C103F7F86A290
dt.entity.synthetic_locationstringSynthetic location ID (monitored entity ID)SYNTHETIC_LOCATION-A4F834D72840EFC1
dt.entity.multiprotocol_monitorstringMonitor ID (monitored entity ID)MULTIPROTOCOL_MONITOR-3F6C9D500287BBAF
multi_protocol.step.idnumericStep sequential ID1
multi_protocol.request.idnumericRequest sequential ID2
multi_protocol.result.statusstringExecution statusHEALTHY, CONSTRAINT_VIOLATED
multi_protocol.result.status.codenumericNumeric representation of the execution status0, 1401

Monitor metrics (all network availability monitors)

NameTypeDimensionsDescription
dt.synthetic.multi_protocol.execution_time
(latest Dynatrace)
builtin:synthetic.multiProtocol.executionTime
(previous Dynatrace)
numericdt.entity.synthetic_location
dt.entity.multiprotocol_monitor
Duration between start and end time of visit execution (in milliseconds)
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)
numericdt.entity.synthetic_location
dt.entity.multiprotocol_monitor
Ratio of executed steps that didn't fail (successes + skips) to all executed steps
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)
numericdt.entity.synthetic_location
dt.entity.multiprotocol_monitor
Availability calculated based on the execution status of visits
- 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)
numericdt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.result.status
multi_protocol.result.status.code
Number of monitor executions in time

Step metrics (all network availability monitors)

NameTypeDimensionsDescription
dt.synthetic.multi_protocol.step.execution_time
(latest Dynatrace)
builtin:synthetic.multiProtocol.step.executionTime
(previous Dynatrace)
numericmulti_protocol.request.type
dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
Duration between start and end time of step execution (in milliseconds)
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)
numericmulti_protocol.request.type
dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
Ratio of executed requests that didn't fail (successes + skips) to all executed requests
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)
numericmulti_protocol.request.type
dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
Availability calculated based on the execution status of steps
- 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)
numericmulti_protocol.request.type
dt.entity.synthetic_location
dt.entity.multiprotocol_monitor
multi_protocol.step.id
multi_protocol.result.status
multi_protocol.result.status.code
Number of step executions in time

Request metrics (all network availability monitors)

NameTypeDimensionsDescription
dt.synthetic.multi_protocol.request.availability
(latest Dynatrace)
builtin:synthetic.multiProtocol.request.availability
(previous Dynatrace)
numericmulti_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
Availability calculated based on the execution status of requests
- 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)
numericmulti_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
Number of request executions in time

ICMP monitor metrics

NameTypeDimensionsDescription
dt.synthetic.multi_protocol.icmp.success_rate
(latest Dynatrace)
builtin:synthetic.multiProtocol.icmp.successRate
(previous Dynatrace)
numericmulti_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
Ratio of received packets to sent packets
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)
numericmulti_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
Total number of packets sent
dt.synthetic.multi_protocol.icmp.packets_received
(latest Dynatrace)
builtin:synthetic.multiProtocol.icmp.packetsReceived
(previous Dynatrace)
numericmulti_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
Number of packets that were returned successfully
dt.synthetic.multi_protocol.icmp.round_trip_time
(latest Dynatrace)
builtin:synthetic.multiProtocol.icmp.roundTripTime
(previous Dynatrace)
numericmulti_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
Round-Trip Time for received packets
dt.synthetic.multi_protocol.icmp.request_execution_time
(latest Dynatrace)
builtin:synthetic.multiProtocol.icmp.requestExecutionTime
(previous Dynatrace)
numericmulti_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
Duration between start and end time of request handling (in milliseconds)
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

NameTypeDescriptionExample value
multi_protocol.request.tcp_port_numberstringTCP request port number, as provided in monitor configuration665

TCP monitor metrics

NameTypeDimensionsDescription
dt.synthetic.multi_protocol.tcp.connection_time
(latest Dynatrace)
builtin:synthetic.multiProtocol.tcp.connectionTime
(previous Dynatrace)
numericmulti_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
Duration between start time (socket creation and connection) and end time (when confection is successfully established) in milliseconds
Metric available only if request execution took place (with no exceptions or timeouts), with a well-defined end time

DNS monitor dimensions

NameTypeDescriptionExample value
multi_protocol.request.dns_record_typestringDNS record type to be queried by request, as provided in configurationA, AAAA, CNAME

DNS monitor metrics

NameTypeDimensionsDescription
dt.synthetic.multi_protocol.dns.resolution_time
(latest Dynatrace)
builtin:synthetic.multiProtocol.dns.resolutionTime
(previous Dynatrace)
numericmulti_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
Duration between start and end time of the request to the DNS server, in milliseconds
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"

Host entity status for ICMP requests

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"
)

ICMP packets sent and received

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) 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

Target status for TCP requests

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"

TCP connection time to target port

Execution statuses

All network availability monitors

Code / messageExampleDescription
0 HEALTHY-All is well.
-1 UNEXPECTED_ERRORResource saturationUnexpected problem that's usually related to monitor's execution components.
1401 CONSTRAINT_VIOLATED-Constraint conditions that were defined in monitor's configuration were not met.
1604 VALIDATION_ERROR-Improper monitor configuration detected.
12013 UNKNOWN_HOSTError in the hostnameIP address of the host cannot be determined. Possible causes:
- Invalid hostname
- DNS server unreachable
- DNS cache issues
- Firewall or proxy interference
12033 Execution timeoutServer operates slowly.Timeout of request execution. Possible causes:
- Network issues
- Slow or unresponsive server or service
- Connection blocked by firewall rules
- Timeout is too small.

TCP monitor execution statuses

Code / messageExampleDescription
22000 TCP socket connection errorService is not listening on a specified port.This status means that the host was identified and available but the TCP connection could not be established or was unexpectedly closed. Additional explanation for the exact exception is provided. The status is used if a 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.