Integration with web load testing and monitoring tools

AppMon integrates well with load testing and monitoring products, especially on the transactional / request level. AppMon automatically starts a PurePath on a servlet, ASP.NET or web service when the AppMon HTTP trace tag is present.

The Dynatrace Community Webinars show how to use AppMon in load testing and also show how it uses tagged web requests to integrate with any HTTP-based load testing solution.

Request header

To use other load testing and monitoring tools for diagnosing web services in AppMon, add the following information to the HTTP headers generated by the load testing tool:

x-dynaTrace: VU=1;PC=.1;ID=4;NA=SearchPage

Below is a sample HTTP header. The final line of the example shows the added code.

POST /onca/soap?Service=AWSECommerceService HTTP/1.1
Content-Type: text/xml; charset=utf-8
Content-Length: 2566
Connection: Keep-Alive
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT)
x-dynaTrace: VU=1;PC=.1;ID=4;NA=ListResults

The following table describes the HTTP header string for AppMon diagnostics.

Key Description APMaaS Name Usage
ID The unique request ID (serial number). This string should be unique for one web request or a set of web requests that together make up a step/transaction execution.
Transaction GUID optional
PC The Page Context contains information about what document in the currently processed page is loaded. The following syntax is recommended, though not required:
  • If it is a named frame, then the value starts with the frame name.
  • The document number, unique for the page, is appended after a period. If embedded documents are cached, this number need not be progressive.
VU The unique number of the Virtual User that sends the request.
Virtual User ID optional
NA The timer NAme of the request. This can be the timer or transaction name used in the load test script to identify the response time measure, or the document/page title, or any other human-readable URL encoded identifier for that document.
Transaction Name (SYM),
Step Name (SaaS)
SI The Source ID can be used to identify the product that triggered the request: For example WLT (Web Load Testing), SYM  (Dynatrace Synthetic Monitoring), BB (Backbone), or LM (Last Mile). Source ID optional
GR Geographic Region: Useful only for the Synthetic Monitoring solution. This contains arbitrary text. Location optional
AN Agent Name: the logical name of the Agent from which the request originated. This information is used by Synthetic Monitoring. Agent Name optional
SN Script Name: This groups a set of requests that make up a multi-step transaction, for example making an online purchase. Script Name optional
TE Test Name: The name of the entire load test. It uniquely identifies a test run. Test Name Optional

Response header

HTTP/1.1 200 OK
x-dynaTrace: RS=session20060620091846;PT=31;PA=1;PS=76562898
Content-Type: text/html
Transfer-Encoding: chunked
Date: Tue, 20 Jun 2006 07:19:16 GMT
Server: Apache-Coyote/1.1

All the attributes together uniquely define a single object request, which is a single PurePath.

Key Description Usage
RS Name of the AppMon Recorded Session that is currently being recorded. Only set when session recording is active
PT PurePath identifier: The Trace number. required
PA PurePath identifier: The entry point Agent number. required
PS PurePath Server identifier: The AppMon Server that captured this PurePath. required
SP System Profile: Set to the active System Profile if manual session recording is not active; that is, if either live session recording or no session recording is active. available

Viewing Tagged Web Requests in AppMon

AppMon groups the resulting web page requests specifically for load tests. See Tagged Web Requests dashlet for details.

Tagged Web Requests
Tagged Web Requests

Synchronizing session recording with load test runs

AppMon Server offers both a web service and RESTful service API that can be used to record an AppMon session for the time of the load test run. In earlier versions of AppMon, the command line interface could be used, by using the dtcmd utility. You can still use this command line utility, but using the web-based APIs is recommended.

To get a list of all web-based APIs, browse to the AppMon Server web frontend, which by default is https://<server>:8021.

From there, you have the option to obtain the SOAP/HTTP web service WSDL (https://<server>:8021/wsdl/ManagementServerService.wsdl) or interact with the RESTful interface from an HTML interface (https://<server>:8021/rest/html/management/server) or from an XML-based interface (https://<server>:8021/rest/management/server).

The HTML interface enables you to explore all options the RESTful interface offers. Clicking the XML link on each HTML page shows you the links to the RESTful service that should be used when accessing the service from an external tool. The response of the XML-based interface is also XML, which is easier to parse and analyze.

The RESTful interface makes it easy to interact with the AppMon Server. For synchronizing session recording with load test runs, you can use the RESTful calls to start and stop session recording for a specific System Profile. If your load testing tool offers a way to execute web requests at the beginning and at the end of the load test run, you can add the necessary web request calls to the AppMon Server.

See Start Session Recording and Stop Session Recording for details on how to start and stop session recording using the REST Interfaces.

WebAPI tests


Although you can monitor WebAPI load tests produced by JMeter, it is recommend not to do so.

Load tests usually produce huge amount of data in a short period of time. That may lead to significant Performance Warehouse size increase, as well as longer processing time or some data loss.

If you want to use JMeter as a load testing tool, pass only NA X-dynaTrace header parameter, without passing TR parameter (see description here), and analyze results using the Load tests feature. Doing this omits Test Automation feature processing, but generates PurePaths for all WebAPI calls produced by JMeter.

Web APIs are interfaces provided by a web server that can be used by a variety of clients like smartphone apps, rich-client applications, or other web applications. It is crucial to continuously ensure API performance, and with the Web API test category it is now possible to continuously monitor performance metrics for HTTP-based web service APIs.


Perform the following steps to execute a Web API test.

  1. Register a new test run through the REST interface using the webapi category.
  2. Send one or more HTTP requests to the URI page you want to test. These requests have to include the X-dynaTrace header where the test run ID returned by the AppMon Server REST Interface is specified to let AppMon know that these requests belong to a test. See below for a description of fields in the X-dynaTrace header.
  3. Analyze the test results in the Test Automation dashlet, or retrieve them using REST API.

In case you don't want to provide specific test metadata, you only need to provide the test name using the TN field in X-dynaTrace header (see below). That way the test run registers automatically.

X-Dynatrace header possible key-value pairs

The table lists possible key-value pairs. They can be provided in any order, separated with a semicolon.


The TN field should be used to provide test name. The TR and RC fields can still be used if you want to provide test run id or the expected response code.

Key Description Usage
TN Test Name (TN) should be provided using this field. Metrics for requests with the same name are aggregated. You can execute as many tests as desired within the same test run, but give them different names if they are not testing the same thing. Required.
You can still use NA and TR fields instead.
NA Old way of passing Test Na me. Deprecated
Requires TR field to be provided
TR TestRunId (TR), from a registered test run. See REST API POST testruns for more information. Optional when TN field us used. If not provided, a test registers automatically.
Required with NA field.
RC Expected Response Code (RC). If the test results in any other response code, the test is marked as failed. Optional. The default is 200.

X-Dynatrace header sample

Using test run id registered using Test Automation REST API, expecting 200 response code:

X-dynaTrace: TN=SampleTestName;TR=7a0520fc-eda9-4f78-a8fa-4cb7d04ac8b8;RC=200

Relying on automatic test run metadata registration (no test metadata provided), expecting default response code (200):

X-dynaTrace: TN=SampleTestName


Category Metric Name Notes
Web Requests Bytes Sent Request size capturing needs to be enabled in sensor's configuration. See Java Web Service sensor, Servlet sensor or Web Server sensor for more information.
Web Requests Bytes Received Request size capturing needs to be enabled in sensor's configuration. See Java Web Service sensor, Servlet sensor or Web Server sensor for more information.
PurePaths PurePath Duration
PurePaths PurePath Response Time
Methods Invocation All custom Method Invocation Measures that return a measure for a PurePath will be included
Logging Count
Exceptions Count
Database Execution Count

All the measures captured by the Test Automation feature must have agent and application splittings enabled.

To do this:

  1. Open the System Profile Preferences dialog box, and select the Measures item.
  2. Double-click the required measure to edit it.
  3. In the Details tab, expand the Measure splitting list and select the Create measure for each application and Create measure for each agent check boxes.
  4. Save your changes.


See Integrate Web API Performance Monitoring in JMeter for more information how to use the Web API test category.