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.execution_time (the latest Dynatrace)
Duration between the start and end the time of visit execution (in milliseconds)Metric available only if visit execution took place; both start time and end time must be available.
dt.synthetic.multi_protocol.executions (the latest Dynatrace)
Ratio of executed steps that didn't fail (successes and 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%.
Step metrics (all network availability monitors)
Name
Type
Dimensions
Description
dt.synthetic.multi_protocol.step.availability (the latest Dynatrace)
Duration between the start and the end time of step execution (in milliseconds). The metric is available only if the step execution took place, with a well-defined end time; therefore, it's not available for skipped steps.
dt.synthetic.multi_protocol.step.executions (the latest Dynatrace)
Ratio of executed requests that didn't fail to all executed requests. If a step doesn't have executed requests (because nothing matches its definition in a monitor configuration), we return the value 100%.
For example, with 2 successful requests and 1 failed request, the ratio is 2/3, or 66.67%.
dt.entity.host (only for monitors with filter defined)
dt.synthetic.monitored_entity_ids
primary_tags.__key__
dt.security_context
step.id
request.id
request.target.address
request.type
Duration between the start and the end time of request handling (in milliseconds). This metric is always provided, even if actual request execution didn't occur (for example, because of exceptions or timeouts).
Diagnostic metric—allows validation of the external ping process execution time.
dt.synthetic.multi_protocol.icmp.round_trip_time (the latest Dynatrace)
dt.entity.host (only for monitors with filter defined)
dt.synthetic.monitored_entity_ids
primary_tags.__key__
dt.security_context
step.id
request.id
request.target.address
request.type
request.tcp_port_number
Duration between the start time (socket creation and connection) and the end time (when connection is successfully established) in milliseconds. The metric is available only if the request execution completed without exceptions or timeouts and has a well-defined end time.
DNS monitor dimensions
Name
Type
Description
Example value
request.dns_record_type
string
DNS record type to be queried by request, as provided in configuration
A, AAAA, CNAME
DNS monitor metrics
Name
Type
Dimensions
Description
dt.synthetic.multi_protocol.dns.resolution_time (the latest Dynatrace)
dt.entity.host (only for monitors with filter defined)
dt.synthetic.monitored_entity_ids
primary_tags.__key__
dt.security_context
step.id
request.id
request.target.address
request.type
request.dns_record_type
Duration between the start and the end time of the request to the DNS server, in milliseconds.
The metric is available only if the request execution took place (with no exceptions or timeouts), with a well-defined end time.
DQL queries to extract data
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 result.status.message 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),
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 is mapped 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 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.
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 split it by the following dimensions:
request.target_address
request.tcp_port_number
result.status.message
In the following 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),
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 the following example, 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
request.target_address
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.
Unexpected problem that's usually related to monitor's execution components.
1401 CONSTRAINT_VIOLATED
-
Constraint conditions that were defined in monitor's configuration weren't met.
1604 VALIDATION_ERROR
-
Improper monitor configuration detected.
12013 UNKNOWN_HOST
Error in the hostname
IP address of the host cannot be determined. Possible causes:
Invalid hostname
DNS server unreachable
DNS cache issues
Firewall or proxy interference
12033 Execution timeout
Server 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 / message
Example
Description
22000 TCP socket connection error
Service is not listening on a specified port.
This status means that the host was identified and available, but the TCP connection couldn't be established or was unexpectedly closed. An additional explanation for the exact exception is provided. The status is used if a java.net.SocketException is returned 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.