How can I Differentiate ASM Web Traffic from Normal Web Traffic Incoming to an Application?

Products

• CA App Synthetic Monitor
• NIMSOFT CLOUD USER EXPERIENCE MONITOR

Issue/Introduction

Transactions generated by ASM are synthetic and users may wish to exclude these transactions from live end user monitoring.

How can I differentiate ASM web traffic from normal web traffic incoming to an application?

 

Environment

This solution applies to Full Page, Real Browser Monitors, HTTP/ HTTPS, and Script Monitors.

Resolution

To differentiate ASM traffic from other network sources, Full Page, Real Browser Monitors, HTTP/ HTTPS, and Script Monitors each have a "Transaction Tag Header" field located towards the bottom of the Advanced monitor options. This field allows for custom values as HTTP headers to be sent to the tested service and can be used to track each test or for any other logging purposes. This property accepts name: value pairs. For example:
     Header-Name:Value
     Header-Name:key=value
     Header-Name:key-value&key2-value2...

With the following list of predefined placeholders available by default in ASM: 

•     {checkpoint_name} = The hostname of the checkpoint (monitoring station) performing the test; i.e. usnyc01 (1)
•     {agent_name} = The name of the agent performing the test; i.e. http, https etc
•     {agent_version} = The version of the agent
•     {user_id} = The id of the account owner
•     {monitor_id} = The id of the monitor
•     {check_id} = The id of the log of the check being made as it is stored in our system
•     {thread_id} =The id of the launched thread. This is for agents that support many threads, i.e. Script (JMeter)
•     {thread_name} = The name of the launched thread. This is for agents that support many threads, i.e. Script (JMeter)
•     {step_num} = The number of the step being taken by the test. Applies to multi step tests only, for example Script (JMeter) 
•     {step_name} = The name of the step being taken by the test. Applies to multi step tests only, for example Script (JMeter)
•     {req_num} = The incremental number of each request of a single web document. For example at FPM monitors, all asset calls will have a different (increasing) req(uest)_num(mber)

Optionally, you can use the following preset headers:

•      Mobile Apps Analytics Monitors: x-apm-bt:t={user_id};d={checkpoint_name}$bs={monitor_id};bt={step_name};p={agent_name};pv={agent_version} 
•      Single-step Monitors: Wtg:agent_name={agent_name}&agent_version={agent_version}&account_id={user_id}&monitor_id={monitor_id}&check_id={check_id}
•     Multi-step Monitors: (includes all thread related placeholders): Wtg:agent_name={agent_name}&agent_version={agent_version}&account_id={user_id}&monitor_id={monitor_id}&check_id={check_id}&thread_id={thread_id}&thread_name={thread_name}&step_number={step_num}&step_name={step_name}&request_number={request_num} 

 

Note: When tracking custom headers, custom headers with all capital letter header names will be converted to only the first letter capital, for example: WPM-TAGS will be converted to Wpm-tags

Additional Information

While less commonly used, the "User Agent" field can also be used to differentiate traffic. Monitor types such as HTTP/ HTTPS, Full Page, and Real Browser Monitors all have a "User Agent" field which can specific specific browsers types or identifiable user agents such as "Watch Mouse", "CA Technologies", and "Nimsoft".

For Script Monitors, the ASM UI does not allow a user to specify the user agent. However, Jmeter allows for custom http headers to be defined, including user agent, and so this can be accomplished in the script. See Jmeter's documentation on this site below:

http://jmeter.apache.org/usermanual/component_reference.html#HTTP_Header_Manager

(1) The {checkpoint_name} value was determined as not being functional and will be implemented from ASM 10.1 onwards. Where OPMS stations are used, they will need to be updated to 10.1 to take advantage of this property