9.1 Synthetic Monitors: HTTP, Single-Step Browser & Multi-Step Clickpaths

Digital Experience Monitoring (DEM) in Dynatrace encompasses two complementary observability paradigms: Real User Monitoring (RUM), which passively observes actual human interactions as they occur, and Synthetic Monitoring, which proactively simulates user traffic and API transactions on scheduled intervals. While RUM provides invaluable insight into real customer behavior and field experience, it suffers from a fundamental limitation: if no users are active on the application (such as during middle-of-the-night maintenance or off-peak hours), RUM cannot detect outages or performance regressions before real customers encounter them.

Dynatrace Synthetic Monitoring solves this problem by executing continuous, deterministic health checks against applications, APIs, and business workflows from globally distributed public locations or private data centers. This ensures that infrastructure changes, deployments, or third-party service degradations are detected, baselined, and alerted upon before impacting end users.

Understanding the distinct operational mechanics, execution engines, resource consumption models, and configuration capabilities of the three primary synthetic monitor types—HTTP Monitors, Single-Step Browser Monitors, and Multi-Step Browser Clickpaths—is essential for the Dynatrace Certified Associate examination.

---

1. HTTP Monitors: Protocol-Level API and Health Validation

HTTP Monitors are lightweight, protocol-level test runners designed to validate the availability, response time, and payload correctness of web servers, microservices, REST APIs, SOAP services, and GraphQL endpoints without the resource overhead of a graphical browser engine.

Execution Characteristics and Scheduling

• Engine Mechanics: Executes requests directly over TCP sockets using an optimized HTTP client library. It evaluates network handshakes, SSL/TLS negotiation, HTTP headers, status codes, and payload bytes without parsing HTML, executing JavaScript, or downloading secondary assets (images, fonts, stylesheets) unless explicitly scripted.
• Execution Frequencies: Can be configured to run at intervals of 1, 2, 5, 10, 15, 30, or 60 minutes. The ability to execute at 1-minute intervals makes HTTP monitors the premier choice for high-frequency API health probing and SLA verification.
• Supported Methods: Supports all standard HTTP verbs, including GET, POST, PUT, DELETE, PATCH, and HEAD.
• Licensing Cost: Consumes 0.1 DEM units per execution, making it the most cost-effective synthetic monitor type.

Request Chaining and Dynamic Variables

In modern API architectures, a single isolated request is rarely sufficient to validate transactional workflows. Dynatrace supports Multi-Request HTTP Monitors, allowing engineers to chain multiple sequential HTTP requests into a single synthetic test.

1. Pre-Execution Scripts: Custom JavaScript executed immediately prior to sending an HTTP request. Commonly used to compute dynamic timestamps, format signatures, or assemble payload parameters.
2. Post-Execution Scripts: Custom JavaScript executed upon receiving the response. Used to parse response headers or payload structures (via JSONPath or regular expressions) and store dynamic values into variables.
3. Variable Extraction and Re-Use: A frequent enterprise pattern involves submitting client credentials to an identity endpoint (e.g., POST /oauth/v2/token), using a post-execution script to extract an OAuth Bearer token or CSRF token, and dynamically injecting that token into the Authorization header of subsequent API calls within the same monitor.

Validation Rules and Assertions

To ensure an API is not merely returning a valid HTTP code while delivering error payloads, HTTP monitors support rigorous validation rules:

• Status Code Validation: Verifies that the HTTP response code matches expected status codes (e.g., 200, 201, or a regular expression such as 2xx|3xx). Any unexpected status code (such as 500 Internal Server Error or 404 Not Found) instantly fails the step.
• Response Body Content Matching: Inspects the response payload using exact literal text matching or regular expressions. Administrators can define positive matches (must contain "status": "SUCCESS") or negative matches (must not contain "error" or "exception").
• JSON / XML Payload Verification: Evaluates specific response attributes, schema formats, or element values.
• SSL/TLS Certificate Expiration: Automatically inspects the target server's certificate chain and triggers an alert if the certificate is invalid, untrusted, or set to expire within a configurable threshold (e.g., 30 days).

---

2. Single-Step Browser Monitors: Full Page Rendering Analysis

While HTTP monitors excel at raw API validation, they cannot detect client-side rendering bottlenecks, unhandled JavaScript exceptions, CSS layout rendering delays, or missing third-party CDN assets. A web server might return an HTTP 200 OK status with a valid HTML skeleton, yet the end user sees a blank white screen because an external JavaScript bundle failed to load or threw an unhandled exception. Resolving this visibility gap requires a Single-Step Browser Monitor.

Chromium Execution Engine

A Single-Step Browser Monitor launches a dedicated, isolated instance of a modern headless Chromium browser. The engine navigates to the target URL and executes the complete client-side lifecycle:

1. Resolves DNS, establishes TCP sockets, and completes TLS handshakes.
2. Requests the primary HTML document and parses the Document Object Model (DOM).
3. Discovers and downloads all secondary resources in parallel (JavaScript files, CSS stylesheets, images, web fonts, tracking beacons).
4. Executes all inline and external JavaScript code, initializes single-page application (SPA) frameworks (React, Angular, Vue), and issues subsequent AJAX/fetch requests.
5. Renders the final visual layout in a virtual viewport.

Performance Metrics and Diagnostics

Single-Step Browser Monitors capture the complete spectrum of synthetic frontend metrics:

• W3C Navigation Timings: Granular breakdown of the page load waterfall, including DNS Lookup, Initial Connection, SSL Handshake, Time to First Byte (TTFB), DOM Interactive, DOM Content Loaded, and Load Event.
• Google Core Web Vitals: Measures user-centric experience metrics, including Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and First Input metrics.
• Visually Complete & Speed Index: Measures the visual progression of the viewport over time, determining the exact millisecond when the visible area of the page stopped visually changing.
• Visual Filmstrip: High-resolution screenshots captured across the page load timeline, allowing operators to visually inspect how the page rendered second-by-second.
• Error Screenshots: If an HTTP error, broken asset, or visual failure occurs, Dynatrace automatically captures and stores a full-page screenshot of the browser state at the moment of failure.

Operational Parameters

• Frequencies: Executed every 5, 10, 15, or 30 minutes, or every 1, 2, or 4 hours — browser monitors cannot run at the 1-minute and 2-minute intervals that HTTP monitors support, because a full Chromium render is far more expensive than a socket request.
• Licensing Cost: Consumes 1 DEM unit per execution from either public or private synthetic locations.

---

3. Multi-Step Browser Clickpaths: Complex User Journey Simulation

Modern web applications are interactive workflows rather than static page views. Critical business transactions—such as logging into a banking portal, searching an inventory catalog, placing items in a shopping cart, and executing a credit card checkout—involve multiple interconnected steps. Multi-Step Browser Clickpaths simulate these end-to-end customer journeys.

+---------------------------------------------------------------------------------------------------+
|                             MULTI-STEP SYNTHETIC CLICKPATH LIFECYCLE                              |
+---------------------------------------------------------------------------------------------------+
| Step 1: Navigate to Storefront (Page Load Action)                                                 |
|   └── Capture W3C Timings -> Validate DOM Title -> Verify HTTP 200                               |
| Step 2: Search for Product (XHR Action)                                                           |
|   └── Click Search Input -> Enter 'Laptop' -> Submit Form -> Wait for Network Idle                |
| Step 3: Add to Shopping Cart (XHR / Fetch Action)                                                 |
|   └── Click 'Add to Cart' -> Wait for AJAX Cart Drawer -> Validate Element Visibility             |
| Step 4: Secure Checkout (Page Load & Form Submit Action)                                          |
|   └── Navigate to /checkout -> Populate Credential Vault Fields -> Click 'Complete Order'         |
| Step 5: Order Confirmation (Validation Action)                                                    |
|   └── Wait for Confirmation Banner -> Assert 'Order # placed successfully' -> Capture Screenshot  |
+---------------------------------------------------------------------------------------------------+

The Dynatrace Synthetic Web Recorder

Clickpaths are authored using the Dynatrace Synthetic Web Recorder, a Google Chrome browser extension. An administrator navigates through the target web application while the recorder captures:

• Mouse clicks, button presses, and link selections.
• Keystrokes, text entries, and form field completions.
• Drop-down menu options and radio button selections.
• JavaScript client-side events.

Events vs. User Actions

A fundamental concept tested on the certification exam is the architectural distinction between an Event and a User Action:

• Synthetic Event: A granular physical browser interaction recorded by the engine (e.g., mousedown, focus, typing text, click).
• Synthetic User Action: A high-level logical transaction that causes a visual change, network request, or navigation. Dynatrace automatically aggregates raw synthetic events into discrete User Actions:
  • Page Load Action: Involves full document navigation, page teardown, and complete browser window reload.
  • XHR / Fetch Action: Asynchronous background HTTP requests initiated by JavaScript without reloading the surrounding page layout.
  • Custom Action: Client-side JavaScript DOM manipulation or layout transitions that do not trigger network traffic.

Exam Key Point: Licensing for multi-step browser clickpaths is calculated based on the number of synthetic user actions executed: 1 DEM unit per synthetic user action step per execution.

Synchronization and Wait Conditions

Because modern Single Page Applications (SPAs) execute complex asynchronous rendering, a naive synthetic script that immediately attempts to click a button after navigating to a page will frequently fail because the button has not yet rendered in the DOM. Dynatrace provides two layers of synchronization:

1. Automatic DOM Stability: By default, Dynatrace monitors the browser engine and automatically waits for the DOM tree to stabilize and all active XHR/Fetch network requests to complete before executing the subsequent step.
2. Explicit Wait Conditions: When client-side animations, delayed micro-frontends, or third-party web components delay rendering, authors can configure explicit wait conditions on any step:
   • Wait for element to be present in DOM.
   • Wait for element to be visible and interactable.
   • Wait for specific text content to appear inside an element.
   • Wait for a custom client-side JavaScript condition to return true.

Resilient Dynamic Locators

Modern frontend frameworks (such as React or Angular) frequently generate dynamic, randomized HTML attributes (e.g., <button id="btn-submit_x99a21b">). If a synthetic engine relied solely on that static ID, the test would break on the next application deployment. The Dynatrace Synthetic Web Recorder automatically captures a prioritized hierarchy of locators for every target element:

• Element ID (if stable)
• CSS Selectors
• Hierarchical XPath expressions
• Visible inner text matching
• Node tree relative positioning During execution, if the primary selector fails to match, Dynatrace applies its fallback locator matrix to dynamically identify the intended element, preventing false-positive test breaks.

---

Synthetic Monitor Architectural Comparison

---

Backend PurePath Distributed Tracing Integration

A paramount capability of the Dynatrace platform is the seamless integration between front-end Synthetic Monitoring and backend PurePath distributed tracing. Synthetic monitors do not operate as isolated black-box probes; they are actively instrumented into the Dynatrace observability fabric.

The x-dynatrace-test and W3C Trace Context Headers

Whenever a synthetic monitor (HTTP or Browser) executes a request against an application infrastructure monitored by Dynatrace OneAgent, the synthetic engine automatically injects two critical HTTP request headers:

1. x-dynatrace-test: A specialized proprietary header carrying synthetic execution context, including the Synthetic Monitor ID, Step ID, Location ID, Execution Timestamp, and Test Run Sequence.
2. traceparent & tracestate: Standard W3C Trace Context headers establishing the root trace context of the transaction.

The PurePath Connection in Action

When the application server (such as an NGINX reverse proxy, Apache web server, or Java/NodeJS microservice) receives the synthetic request, OneAgent intercepts these headers:

• OneAgent tags the resulting backend PurePath trace with the exact synthetic monitor name and step identifier.
• Davis AI links the synthetic client-side experience directly to server-side code execution, database queries, message queues, and infrastructure bottlenecks.
• If a synthetic step experiences an anomalous slowdown or failure, an SRE can click directly from the synthetic waterfall interface into the corresponding server-side PurePath, inspecting the exact line of application code, unhandled database lock, or third-party service exception that caused the synthetic test to fail.