9.2 Private Synthetic Locations, ActiveGate Engines & Credential Vault
Key Takeaways
- Private Synthetic Locations allow organizations to execute HTTP and browser monitors from within on-premises data centers, private cloud VPCs, and staging environments inaccessible from public networks.
- The Synthetic Engine runs on Environment ActiveGates, leveraging dedicated containerized or native Chromium browser processes to execute tests locally.
- Private ActiveGates require strictly outbound HTTPS communication (port 443) to the Dynatrace Cluster, eliminating the need for inbound firewall pinholes.
- High availability and zero-downtime execution in private locations require clustering multiple ActiveGates into a single location pool to balance execution queues and handle failover.
- The Dynatrace Credential Vault securely stores passwords, tokens, and client certificates with role-based access control, automatically masking sensitive inputs across synthetic scripts, waterfalls, and screenshots.
Modern enterprise applications operate across hybrid cloud environments comprising public-facing cloud portals, internal enterprise resource planning (ERP) platforms, intranet HR systems, and pre-production staging environments. While Dynatrace provides a vast global network of managed public synthetic locations, these public nodes cannot test applications sequestered behind corporate firewalls or inside isolated virtual private clouds (VPCs).
To bridge this boundary, Dynatrace provides Private Synthetic Locations. By deploying customer-managed ActiveGates equipped with the Synthetic execution engine directly within internal networks, organizations achieve full synthetic observability across private endpoints without opening inbound security perimeter holes.
Mastering the architecture of Private Synthetic Locations, ActiveGate engine requirements, high-availability clustering, and the Dynatrace Credential Vault is a core domain of the Dynatrace Certified Associate exam.
1. Public vs. Private Synthetic Locations
When planning a synthetic monitoring strategy, architects must determine whether to utilize public locations, private locations, or a hybrid combination:
Public Synthetic Locations
- Hosting & Management: Fully managed by Dynatrace across tier-1 cloud providers (Amazon Web Services, Microsoft Azure, Google Cloud Platform, and Alibaba Cloud) distributed across dozens of global metropolitan areas.
- Use Cases: Measuring edge performance, CDN cache hit efficiency, regional DNS resolution latencies, and end-user availability for public internet-facing websites and mobile application backends.
- Maintenance: Zero customer maintenance; browser versions, OS patches, and engine binaries are automatically updated by Dynatrace.
Private Synthetic Locations
- Hosting & Management: Installed and operated by the customer on dedicated physical or virtual servers (or Kubernetes clusters) located within internal corporate data centers, private VPCs/VNets, or branch offices.
- Use Cases:
- Monitoring internal intranet applications (HR systems, payroll, CRM) inaccessible from the public internet.
- Testing pre-production, staging, and quality assurance (QA) environments prior to release.
- Validating internal API gateways and microservices that enforce strict IP whitelisting or mutual TLS (mTLS).
- Compliance and regulatory requirements mandating that test traffic and synthetic credentials never leave the corporate boundary.
2. ActiveGate Synthetic Engine Architecture & Sizing
Private Synthetic Locations are powered by an Environment ActiveGate configured with the synthetic monitoring capability. The ActiveGate serves as the local orchestration host and execution runner.
+---------------------------------------------------------------------------------------------------+
| ACTIVEGATE SYNTHETIC ENGINE ARCHITECTURE |
+---------------------------------------------------------------------------------------------------+
| ENVIRONMENT ACTIVEGATE HOST (Linux / Container) |
| ├── ActiveGate Core Service (Outbound HTTPS TLS port 443 to Dynatrace Cluster) |
| ├── Synthetic HTTP Engine (High-throughput, multi-threaded protocol executor) |
| └── Synthetic Web Engine (Chromium Browser Manager) |
| ├── Sandboxed Chromium Instance 1 (Executing Clickpath: HR Portal) |
| ├── Sandboxed Chromium Instance 2 (Executing Single-Step: ERP Billing) |
| └── Dedicated VNC Diagnostic Server (Visualizing headless browser execution) |
| │ |
| ▼ |
| TARGET INTRANET WORKLOADS (Internal Core Network / Corporate Data Center) |
| ├── https://intranet-hr.internal.corp (REST / React SPA) |
| └── https://api-gateway.internal.corp:8443 (Internal Microservices) |
+---------------------------------------------------------------------------------------------------+
Engine Components
An ActiveGate equipped for synthetic monitoring runs two distinct internal execution engines:
- Synthetic HTTP Engine: A multi-threaded, low-footprint engine designed to execute single-request and multi-request HTTP monitors at high volume with negligible CPU and memory consumption.
- Synthetic Web Engine (Chromium): A sophisticated browser orchestration engine that dynamically spawns, manages, and terminates sandboxed Chromium browser instances to execute single-step browser tests and multi-step clickpaths. Between every test run, the engine completely purges the browser profile, clearing cached cookies, indexedDB records, local storage, and temporary files to ensure absolute test isolation.
- VNC Diagnostic Server: ActiveGates include an embedded VNC server allowing administrators to securely connect and view the live, real-time graphical rendering of headless Chromium sessions for troubleshooting complex clickpath failures.
Operating System and Hardware Sizing
Browser execution requires dedicated CPU and memory resources to manage headless rendering, layout calculations, and JavaScript execution. Dynatrace enforces strict operating system and hardware requirements for private synthetic engines:
- Supported Operating Systems: Linux distributions (Red Hat Enterprise Linux, CentOS, Ubuntu LTS, SUSE Linux Enterprise Server, and Amazon Linux 2). Native browser synthetic monitoring on Windows ActiveGates is deprecated/unsupported; Linux-based ActiveGates (or containerized ActiveGates on Kubernetes) are the enterprise standard.
- Memory & CPU Sizing Formula: While HTTP monitors require minimal hardware, browser monitors require dedicated capacity slots. A general enterprise sizing guideline is 1 CPU core and 2.5 GB to 3 GB of RAM per concurrent browser execution slot.
- Capacity Calculation: The required number of concurrent execution slots is calculated using the formula: If a private location hosts 20 browser monitors that each take 1 minute to run and execute every 5 minutes, the location requires $20 \times (1/5) = 4$ concurrent browser slots at all times. If peak test scheduling exceeds available slots, tests are placed in an execution queue, resulting in delayed runs and skewed timing metrics.
Communication Architecture: Zero Inbound Firewall Holes
A critical security feature of Dynatrace Private Synthetic Locations is that ActiveGates require zero inbound network ports.
- The ActiveGate establishes an outbound HTTPS connection over port 443 (TLS) to the Dynatrace SaaS environment or Dynatrace Managed cluster.
- Over this persistent outbound connection, the ActiveGate regularly polls the cluster for scheduled synthetic jobs assigned to its location.
- The ActiveGate retrieves the test configuration, executes the synthetic steps locally against the target internal servers, processes the results, and pushes performance metrics, filmstrips, waterfalls, and error logs back to the Dynatrace cluster over port 443.
- Network security teams do not need to open inbound firewall pinholes into the internal corporate network.
3. High Availability (HA) and Location Clustering
In enterprise production environments, hosting a Private Synthetic Location on a single ActiveGate introduces a dangerous Single Point of Failure (SPOF). If that virtual machine reboots for operating system kernel updates or experiences a hardware fault, all assigned synthetic monitors fail to run, creating blind spots and potentially generating false-positive outage alerts.
Private Location Pools
To eliminate this risk, Dynatrace supports clustering multiple ActiveGates into a single Private Synthetic Location Pool:
- Shared Location Identity: Multiple ActiveGates (e.g.,
AG-East-01andAG-East-02) are registered under a single logical Private Location name (e.g.,"DataCenter-East-Private"). - Automated Queue Balancing: Dynatrace automatically load-balances scheduled synthetic executions across all healthy ActiveGates in the pool.
- Seamless Failover & Rolling Maintenance: If one ActiveGate goes offline or is stopped for patching, the Dynatrace cluster instantly routes pending synthetic executions to the remaining active nodes in the location pool without test interruption, queue starvation, or synthetic failure alerts.
- Best Practice Recommendation: For mission-critical private monitoring, always assign a minimum of two ActiveGates to each Private Synthetic Location.
4. The Dynatrace Credential Vault
Automated synthetic monitors must frequently authenticate against protected systems, requiring usernames, passwords, API tokens, client secrets, and SSL/TLS client certificates. Storing plaintext credentials inside test scripts, URL parameters, or JSON payloads creates severe security vulnerabilities, exposing sensitive data to monitor authors, operators, and audit logs. Dynatrace eliminates this vulnerability through the Credential Vault.
+---------------------------------------------------------------------------------------------------+
| DYNATRACE CREDENTIAL VAULT WORKFLOW |
+---------------------------------------------------------------------------------------------------+
| 1. CREDENTIAL STORAGE & ENCRYPTION |
| • Admin stores secret in Credential Vault (AES-256 encrypted at rest). |
| • Configures RBAC: Grants 'Use' permission to SRE team without granting 'View Secret' rights. |
| │ |
| ▼ |
| 2. SCRIPT REFERENCING VIA VAULT PARAMETER |
| • Synthetic Script references parameter: {{vault:Corporate_Admin_Account}} |
| • No plaintext username or password exists in the clickpath or HTTP configuration. |
| │ |
| ▼ |
| 3. SECURE EXECUTION & AUTOMATIC MASKING |
| • ActiveGate injects secret directly into HTTP header or Chromium input element during run. |
| • Dynatrace automatically masks value in logs, waterfalls, filmstrips, and screenshots. |
+---------------------------------------------------------------------------------------------------+
Supported Credential Types
The Dynatrace Credential Vault securely stores multiple credential formats:
- Username / Password Pairs: Standard credentials used for HTTP Basic/Digest authentication or web form login fields.
- API Tokens and Secret Keys: Arbitrary string tokens used for Bearer token headers, custom API keys, or dynamic signatures.
- OAuth 2.0 Credentials: Client ID and Client Secret configurations for automated token negotiation.
- Client Certificates: Public/private key pairs (PKCS#12 or PEM format) used for Mutual TLS (mTLS) authentication in zero-trust architectures.
Scoping and Role-Based Access Control (RBAC)
The Credential Vault enforces strict separation of duties:
- Environment-Wide vs. Management Zone Scoping: Credentials can be scoped to the entire Dynatrace environment or strictly partitioned to specific Management Zones. This ensures that an e-commerce development team cannot access or utilize credentials belonging to the human resources or financial services teams.
- Granular Permissions: Administrators can grant users the permission to use a credential within a synthetic monitor without granting them permission to view the plaintext secret. A junior engineer can construct a clickpath that logs in using
{{vault:Production_Service_User}}while remaining completely blind to the actual password string.
Referencing Syntax and Automatic Masking
- Parameter Syntax: Credentials stored in the vault are referenced in synthetic monitor configurations using the standard syntax
{{vault:credential_id}}(or selecting the credential directly from the UI dropdown in browser clickpath keystroke actions). - Automatic Visual Masking: To comply with global privacy standards (such as PCI-DSS, GDPR, and HIPAA), Dynatrace automatically detects and masks sensitive credential inputs:
- Any text input into a password field (
<input type="password">) is automatically obscured and blacked out in synthetic error screenshots and filmstrip views. - Secrets retrieved from the Credential Vault are automatically sanitized and redacted from HTTP request/response headers, script logs, and waterfall inspection tabs.
- Any text input into a password field (
A healthcare enterprise must execute automated synthetic browser clickpaths against an internal clinical records portal hosted within an on-premises data center. Due to strict HIPAA and network security policies, the data center network has zero inbound internet connectivity and cannot be accessed from public cloud IP ranges. Outbound network traffic is permitted through a corporate proxy over HTTPS (port 443). How should the enterprise deploy Dynatrace Synthetic monitoring to validate this internal portal?
During a security audit, an enterprise security architect discovers that synthetic clickpath scripts for a retail application contain plaintext administrative credentials within the script's keystroke events. What platform mechanism does Dynatrace provide to eliminate plaintext credential exposure while allowing synthetic monitors to authenticate seamlessly?
An operations team notices that synthetic browser monitors running on a private synthetic location are frequently delayed and executing several minutes after their scheduled intervals. An inspection of the Private Location status reveals that the execution queue length is continuously growing, while the ActiveGate host has 85% CPU and 90% memory utilization. What is the root cause of this operational issue and the correct architectural resolution?