Private Synthetic Location Not Available for TCP (NAM) Monitors

[HannahM]

Summary

This article focuses on Dynatrace Synthetic Monitoring, specifically Network Availability Monitors (NAM) using TCP, and explains why a private Synthetic location may not be selectable when creating TCP monitors.

It helps you understand the platform prerequisites and system‑level dependencies that determine whether TCP monitoring is available from a private location, and how to validate TCP connectivity using ActiveGate diagnostics and host-level testing.

• Summary
• Problem
• In the Dynatrace UI
• Evidence in ActiveGate logs
• Troubleshooting steps
• 1. Review ActiveGate diagnostic results
• 2. Understand how TCP availability is validated
• 3. Verify TCP connectivity from the ActiveGate host
• 4. Check firewall and network restrictions
• 5. Validate service availability on the target
• Resolution
• After resolving the cause of the failure
• What’s next
• Related reading

Problem

After deploying Synthetic‑enabled ActiveGates and assigning them to a new private Synthetic location, the location appears as Not supported when attempting to create a TCP Network Availability Monitor.

In the Dynatrace UI

You may observe one or more of the following:

• In Synthetic → Private locations, the private location shows a Compatibility health alert
• Network Availability (TCP) is missing from the available monitor types under:
  Classic Settings → Web and mobile monitoring → Private Synthetic locations → Edit location
• The private location is marked as Not supported, with a message indicating that the location is not configured to execute this type of monitor

Evidence in ActiveGate logs

The ActiveGate diagnostic logs (vuc-status.log) indicate that TCP capability is unavailable, even though other protocols may still be operational.

Example:

MULTIPROTOCOL = {
  MULTIPROTOCOL_TCP = DiagnosticCaseDetail[isAvailable=false],
  MULTIPROTOCOL_DNS = DiagnosticCaseDetail[isAvailable=true],
  MULTIPROTOCOL_ICMP = DiagnosticCaseDetail[isAvailable=true]
}

When MULTIPROTOCOL_TCP is reported as isAvailable=false,
TCP NAM monitors are automatically disabled for the private location.

This behavior is consistent with how Dynatrace enables NAM monitor types only when the required protocol capability is validated on the ActiveGate host.

For information on finding the log see Useful Synthetic ActiveGate logs

Troubleshooting steps

Use the following steps to determine whether the limitation is due to Dynatrace configuration or host/network constraints.

1. Review ActiveGate diagnostic results

• Check vuc-status.log for multi-protocol diagnostics
• Confirm whether:

  MULTIPROTOCOL_TCP = isAvailable=false
  

• If false, the issue originates from the ActiveGate environment rather than Dynatrace configuration

2. Understand how TCP availability is validated

A TCP NAM monitor works by establishing a TCP connection to a specific port on a target host.

The ActiveGate must be able to:

• Open an outbound TCP connection
• Reach the target host over the network
• Successfully complete a TCP handshake on the specified port

If this fails during diagnostics, TCP monitoring will be disabled.

3. Verify TCP connectivity from the ActiveGate host

Run connectivity tests directly from the ActiveGate host to the target endpoint.

Examples:

nc -vz <hostname> <port>

or

telnet <hostname> <port>

Expected outcome:

• Successful connection → TCP should be available
• Connection refused / timeout → indicates network or service issue

4. Check firewall and network restrictions

Ensure that:

• Outbound traffic to the target port is allowed
• Intermediate firewalls are not blocking TCP handshake traffic
• Network routing between ActiveGate and target is correctly configured

Common issues:

• Denied outbound rules
• Missing return route
• Segmented networks without proper allowlisting

5. Validate service availability on the target

Confirm that:

• The target host is reachable
• The specified port is open and listening
• The service supports TCP connections

Example checks:

ss -tuln | grep <port>

If the service is not listening, the TCP diagnostic will fail.

Resolution

Once the issue is identified and resolved:

• Ensure TCP connectivity from the ActiveGate host is successful
• Restart the ActiveGate service (if required to refresh diagnostics)
• Re-check Synthetic → Private locations

Expected result:

• The private location no longer shows compatibility errors
• Network Availability (TCP) becomes selectable
• TCP NAM monitors can be created successfully

After resolving the cause of the failure

• Re-run diagnostics via ActiveGate logs to confirm:

  MULTIPROTOCOL_TCP = isAvailable=true
  

• Trigger an on-demand execution to validate monitor success
• Confirm results in the Synthetic app

What’s next

• Consider creating multiple TCP requests within a single NAM monitor to validate multiple endpoints efficiently
• Define appropriate thresholds for connection success or failure
• Combine TCP NAM monitoring with ICMP or DNS checks for deeper network visibility

Related reading

📖  Create a NAM monitor (Dynatrace Docs)

📖  Network availability monitoring overview

📖  Synthetic Monitoring Troubleshooting Map

📖  Manage Private locations  

📖  Useful Synthetic ActiveGate logs