Route Agent Communication with Dynatrace Network Zones (2026)

Route Agent communication with Dynatrace Network Zones is a surprisingly complex dance where network topology dictates how your agents report data, and missteps here can lead to a silent, unmonitored environment.

Let’s see it in action. Imagine you have two distinct network segments: one for your production servers (Zone A) and another for your staging environment (Zone B). Your Dynatrace ActiveGate is deployed in Zone A.

[Production Servers (Zone A)] <--- (Internal Network) ---> [ActiveGate (Zone A)]
                                       |
                                       | (Internet/VPN)
                                       |
                                       v
                                [Staging Servers (Zone B)]

Normally, an agent on a staging server (Zone B) would try to connect directly to the Dynatrace SaaS endpoint or an on-premise ActiveGate. But if Zone B can’t reach the internet or your primary ActiveGate directly, you need Network Zones.

Here’s how it works:

Agent Configuration: On a staging server, the OneAgent is configured to report to a local ActiveGate that’s also in Zone B.
- File: oneagent.conf (location varies by OS, e.g., /var/lib/dynatrace/oneagent/agent/config/oneagent.conf on Linux)
- Key: --set-server-address=<local_activegate_ip>:9999
- Example: --set-server-address=10.10.20.10:9999
This tells the agent to send its data to the ActiveGate at 10.10.20.10.
Local ActiveGate Configuration: This ActiveGate in Zone B is configured to forward data to the primary ActiveGate in Zone A.
- File: communication.properties (location: /var/lib/dynatrace/gateway/communication.properties on Linux)
- Key: dynatrace.communication.forwarding.targets
- Example: dynatrace.communication.forwarding.targets=192.168.1.50:9999
This directs all data received by the Zone B ActiveGate to the primary ActiveGate at 192.168.1.50.
Network Routing: The crucial part is ensuring that:
- Agents in Zone B can reach the local ActiveGate in Zone B on port 9999.
- The ActiveGate in Zone B can reach the primary ActiveGate in Zone A on port 9999.
- The primary ActiveGate in Zone A can reach the Dynatrace SaaS endpoint or your on-premise cluster on port 443 (or 9999 for on-prem).
This is where the "Network Zones" concept in Dynatrace comes in. You define these zones within the Dynatrace UI under Settings > Deployment > ActiveGate > Network zones.

When you configure your ActiveGates, you assign them to a network zone. If an ActiveGate is configured with dynatrace.communication.forwarding.targets, Dynatrace knows that this ActiveGate is acting as a proxy for its network zone.

The mental model is: Agents report to their local ActiveGate. If that local ActiveGate is in a different network zone than the primary endpoint, it forwards the data. Dynatrace uses this to understand your network’s segmentation and route data efficiently.

The core problem Network Zones solve: Agents often reside in network segments that don’t have direct internet access or cannot reach your main Dynatrace cluster endpoint. Instead of requiring complex firewall rules for every agent, you deploy a local ActiveGate within that segment. This local ActiveGate then acts as a single point of contact, forwarding data to the main ActiveGate or Dynatrace SaaS. Dynatrace uses the Network Zone configuration to ensure it knows which ActiveGate belongs to which logical network segment, enabling it to correlate data correctly and understand your network topology.

The most surprising implication is that an agent’s server-address configuration doesn’t have to be the Dynatrace SaaS endpoint. It can be any ActiveGate’s IP address that is configured to forward data. This allows for a highly distributed and segmented data collection architecture where agents only need to reach their nearest ActiveGate, and the ActiveGates handle the upstream routing.

The next concept to grapple with is how ActiveGate updates are managed in such a segmented environment.