Integration of Dynatrace Application Monitoring with NAM FAQ

How to troubleshoot the most frequent problems when integrating NAM with Dynatrace Application Monitoring.

There is no drilldown from an individual page load in the NAM report to the Dynatrace Application Monitoring data

Response to the Client has been returned by the Web Server/proxy/gateway, not by the application Server instrumented with Dynatrace Application Monitoring agent.

Example: Web Server returns Gateway Timeout before it receives full data from the application Server.

Figure 1. Web Server Returns Gateway Timeout before it Receives Full Data from the Application Server

dt FAQ 1
dt FAQ 1

There is no drill down from a Server in the NAM report to the Dynatrace Application Monitoring data

The server may be not instrumented by Dynatrace Application Monitoring agent. Dynatrace Application Monitoring may be not configured to receive mappings from the NAM Probe that monitors the Server. For more information, see Configuring Dynatrace Application Monitoring to Receive Performance Data from NAM. NAM is not configured to recognize Dynatrace Application Monitoring tags in the HTTP headers.

Drill down is supported only for Servers monitored by the NAM Web analyzer. SOAP and XML analyzers will not produce data for drilldowns.

Figure 2. Drilldowns available in NAM - Dynatrace Application Monitoring Integration.

dt FAQ 2
dt FAQ 2

Server Time value differs between NAM and Dynatrace Application Monitoring

NAM measures time between network packets received and returned by Server, but Dynatrace Application Monitoring measures time between events within the application. There's a space between these different measurement points, where TCP and SSL may add its overhead not visible to Dynatrace Application Monitoring.

Figure 3. Differences in Server Time Measurements between NAM and Dynatrace Application Monitoring.

dT FAQ 3
dT FAQ 3

NAM performs two Server Time measurements for HTTP/HTTPS: HTTP Server Response Time and the Server Time. The former is up to the moment when first response packet is returned, the latter is calculated until the constant stream of response starts to flow out (no waiting gaps in response stream). Dynatrace Application Monitoring does not account for these events, as it has no visibility into how the TCP stack is used by the application Server (flushes, caches, etc.).

Figure 4. Differences in Server Time Measurements between NAM and Dynatrace Application Monitoring.

dt FAQ 4
dt FAQ 4

Stepchart in NAM shows ten objects belong to a page, Dynatrace Application Monitoring shows only five PurePaths for this page load.

Dynatrace Application Monitoring shows PurePaths only if object generation involved Server activity measured by the agent. Objects served directly from disk as files may not be visible to the Web Server agent and will not be visible to the App Server agent.

Figure 5. Load Sequence Differences between NAM and Dynatrace Application Monitoring.

dT FAQ 5
dT FAQ 5

Dynatrace Application Monitoring drill-through to UEM shows different, richer page load sequence than NAM

Dynatrace Application Monitoring UEM monitors from within the browser and sees all page elements including those loaded from local cache, from CDN and from Servers that NAM does not monitor. The NAM stepchart contains only those elements that have been served from the datacenter through the network link that NAM monitors.

Figure 6. Load Sequence Differences between NAM and Dynatrace Application Monitoring.

dT QA 6
dT QA 6

Changing the default value of Visit Timeout property (UEM_VISIT_TIMEOUT) in the CAS ATSCON Control Panel does not affect the analogous property in the Dynatrace Application Monitoring UEM configurator.

The visit timeout property is set to 30 minutes by default. It determines when an idle visit is closed. The property is set both on the CAS and on the Dynatrace Application Monitoring Server and is not automatically synchronized between the two. Changing the value in either of them, requires manual update on the other device.