Monitoring Web Activity

When you've defined your applications, you can easily view how they perform in several different widgets that take Application as an input.
You can monitor a web application as a standard application using the ordinary IP response time measurement. However, if you want to log the response time per URL requested from a web server, your PerformanceGuard administrator must set up Web Applications.

A transaction filter is a mechanism for collecting data about web requests and for extracting information from those requests so that you can monitor the performance of websites and web applications.

What does a transaction filter do?

A transaction filter is basically a definition of things to look out for in a web request—for example images so that you can measure how long it takes before all images on a website are available for viewing in a user's browser. Transaction filters are very flexible, so you can define more or less any element of a web request as a thing to look out for.

When are transaction filters useful?

Say that your organization's Human Resources team uses a web-based system for managing employees' career paths, appraisals, salaries, etc. By using transaction filters you can measure total response times for that system as experienced on the team members' computers. This can 1) help you match the Human Resources team's expectations with what the system is able to deliver, and 2) provide an indication of whether access to the system needs to be optimized.

How are transaction filters applied?

It's the PerformanceGuard agents installed on your organization's computers that look out for the things that the transaction filter specifies. When an agent detects one of those things, it generates a transaction tag—that is a small package of performance information about the web request—and sends it to PerformanceGuard so that you are able to select it when you want to generate a transactions graph , view periodical transaction trends or compare transactions .

Set Up Web Application

You can only do this if you're a PerformanceGuard administrator.

Select Administration > Network Application and click the Create Web Application button.
Select required Type of transaction filter:
- HTTP monitors directly on data packets collected on the monitored network interface (NIC) rather than in the browser. Response times for this type of transaction filter may thus often be slightly lower than for the IE type.
  The HTTP type of transaction filter is applied to requests sent to the specified host and port, but not to responses. As filtration is applied at the network layer, you can only apply HTTP transaction filters to clear-text requests. This means that you can't use this type of transaction filter to monitor requests made using SSL, other types of encryption, https, http/2, spdy/3 or web sockets.
- IE is aimed at Internet Explorer. It monitors web requests as they are experienced in that browser. An IE transaction filter uses specific features in Internet Explorer, and therefore it doesn't work with other browsers, such as Chrome, Edge or Firefox.
  For IE transaction filters to work, your agent configuration must support collection of Internet Explorer data. To verify this, select ADMINISTRATION > Agent Configuration > Configurations, click the Edit link next to the required agent configuration group, scroll down to the Network Report section and verify that Enable IE Reports is selected.
- Chromium is aimed at Cromium based web browsers such as the Chrome Web Browser. It monitors web requests as they are experienced in that browser.
  For Chromium transaction filters to work, your agent configuration must support collection of Chrome data. To verify this, select ADMINISTRATION > Agent Configuration > Configurations, click the Edit link next to the required agent configuration group, scroll down to the Network Report section and verify that Enable Chromium Reports is selected.

3. Specify a Name for the transaction filter. The name is used to identify the transaction filter when you view transaction data in the PerformanceGuard web interface, and the name must therefore be unique.

4. Type a short Description of the transaction filter

5. Specify the transaction filter's Configuration. You can read more about how to make a transaction filter configuration in the following sections.

6. When ready, click the Save Filter button. You are now ready to apply your transaction filter to agent configurations.

How Is a Transaction Filter Configuration Structured, and How Does it Work?

A transaction filter configuration consists of a host part and a tag part:

The host part identifies what host (server and, if required, port) to consider when filtering requests. A transaction filter configuration must contain only one host specification.
The tag part contains a tag identifier and a regular expression that's used to perform the actual filtering. A transaction filter configuration can contain one or more tags. Each tag must contain an ID and one to three regular expressions.

Example: A simple filter that'll generate tags like URL:page.htm for each URL visited on http://www.w3.org:
Host = www.w3.org
Tag 1 id = URL
Tag 1 RegExp = URL,{.*}

You can use the following tag parameters:

Property	Description	Examples
Host	Packets to and from the specified host and port will be routed to the transaction filter.	Host = www.w3.org Host = www.w3.org:8080 Host = 10.10.0.1
InitialTimeout	This is only for Chromium. InitialTimeout is the maximum time (in milliseconds) the filter will wait between requests, but only for the first time the web page is loaded. The performance of the site is measured when this time has past and there is no more requests.	InitialTimeout = 1100 InitialTimeout= 750
Timeout	This is only for Chromium. Timout is the same as InitialTimeout, but used after the first loading of the webpage. This is used when browsing on a SPA (single page application) like PerformanceGuard.	InitialTimeout = 750 InitialTimeout= 500
Tag Specification
Id	Defines a name prefix for the tag. Like the name of the transaction filter itself, the name that you can specify after the = part of the Tag.Id will be selectable as a transaction tag when you later view transaction data in the PerformanceGuard web interface.	Id = Image Id =
RegExp	This is the actual regular expression string that's used to check if a particular request is relevant for the transaction filter. It's also used to extract any variable part of the tag. The value consists of an expression source and the regular expression itself. The two parts are separated by a comma. The expression source may be: IE/HTTP URL: the URL of the request (with parameters removed) Host: the host that the request was sent to Method: the HTTP method invoked (POST or GET) The name of a HTTP meta tag The name of a HTTP parameter The name of a URL rewritten parameter Chromium Is only based on the host. The RegExp is matched on the path (everything after the first / ).	RegExp = URL, .\.{.} The URI file extension, for example html RegExp = ETag, .* The ETag meta tag must be present RegExp = login, {.*} Pick up the login name and add it to the tag RegExp = Method, GET Process only requests of the HTTP method GET

The regular expressions match the specified data source, and may extract parts of the matched expressions. The extracted parts are then concatenated with the Tag Id to form the tag.

Examples:
IE/HTTP:
Tag 1 RegExp 1 = URL,{.*}
Tag 1 RegExp 2 = Method,GET
Tag 2 RegExp 1 = URL,{.*}\.jpg
Tag 3 RegExp 1 = doShow,true

Chromium:
Tag 1 RegExp 1 = .*
Tag 2 RegExp 1 = (.*)\.jpg

The regular expression source defines which part of the request should be used when matching the regular expression. The regular expression thus defines two things:

The criteria for a match
Which part of the regular expression source should be extracted

The part that should be extracted are enclosed in {curly brackets} for IE/HTTP and (parentheses) for Chromium

(This part only works with HTTP and IE).

Regular Expression Source	Description
URL	The regular expression is run on the HTTP URI, excluding any parameters.
Method	The expression source is the HTTP method, which is always either GET or POST.
<Parameter>	If the specified name is recognized as the name of a supplied HTTP parameter—either supplied as part of the URL (using '?') for a GET request or supplied as the body of a POST request—the value is extracted. Example: Tag 1 RegExp 1 = doDisplay,{.} will extract the value of the doDisplay* parameter and include the value in the tag name.

When a request fulfills the regular expressions in a transaction filter, a transaction name is constructed by concatenating the tag identifier (for example Tag1.Id) with the information extracted by the regular expressions.

Example:

Tag 1 Id = URI:
Tag 1 RegExp 1 = Method,{.*}
Tag 1 RegExp 2 = URL,{.*}

If we look at the example, the first regular expression, Tag1.RegExp1, will extract the value of the HTTP method meta tag, that is GET or POST. The second regular expression, Tag1.RegExp2, will extract the entire URL of the request. The tag identifier and the extracted parts are then concatenated, and that generates the transaction name:

Examples:

URI:GET/images/logo.png
URI:GET/index.html

Regular Expression Syntax for Transaction Filter Configurations

.	Match any single character.
[ ]	Defines a character class. Matches any character inside the brackets. Example: [abc] matches a , b and c .
^	If this meta character occurs at the start of a character class, it negates the character class. A negated character class matches any character except those inside the brackets. Example: [^abc] matches all characters except a , b and c . If ^ is at the beginning of the regular expression, it matches the beginning of the input. Example: ^[abc] will only match input that begins with a, b or c .
-	Indicates a range of characters in a character class. Example: [0-9] matches any of the digits 0 through 9 .
?	Indicates that the preceding expression is optional. It matches once or not at all. Example: [0-9][0-9]? matches 2 and 12.
+	Indicates that the preceding expression matches one or more times. Example: [0-9]+ matches 1 , 13 , 666 and so on.
*	Indicates that the preceding expression matches zero or more times.
*??, +?, ?**	Non-greedy versions of ?, +, and . These match as little as possible, unlike the greedy versions that match as much as possible. Example:* Given the input <abc><def> , <.?>* matches <abc> while <.>* matches <abc><def> .
( )	Grouping operator. Example: (\d+,)\d+* matches a list of numbers separated by commas (such as 1 or 1,23,456).
{ }	Indicates a match group.
\	Escape character: interpret the next character literally. Example: [0-9]+ matches one or more digits, but [0-9]\+ matches a digit followed by a plus character. Also used for abbreviations (such as \a for any alphanumeric character; see \a in the following ). If \ is followed by a number n, it matches the nth match group (starting from 0). Example: <{.?}>.?</\0> matches <head>Contents</head> .
$	At the end of a regular expression this character matches the end of the input. Example: [0-9]$ matches a digit at the end of the input.
\|	Alternation operator. Separates two expressions, exactly one of which matches. Example: T\|the matches The or the).
!	Negation operator. The expression following ! doesn't match the input. Example: a!b matches a not followed by b.
\a	Any aplhanumeric character. Shortcut for ([a-zA-Z0-9])
\b	White space (blank). Shortcut for ([ \t]).
\c	Any alphabetic character. Shortcut for ([a-zA-Z]).
\d	Any decimal digit. Shortcut for ([0-9]).
\h	Any hexadecimal digit. Shortcut for ([0-9a-fA-F]).
\n	Newline. Shortcut for (\r\|(\r?\n)).
\q	A quoted string. Shortcut for (\"[^\"]\")\|(\'[^\']\').
\w	A simple word. Shortcut for ([a-zA-Z]+).
\z	An unsigned integer. Shortcut for ([0-9]+).

Apply Transaction Filter to Agent Configuration

You can only do this if you're a PerformanceGuard administrator.

When you have created and saved a transaction filter, you can apply it to agent configurations. You do this by editing required agent configuration groups :

Select ADMINISTRATION > Agent Configuration > Configurations.
Click the Edit link next to the required agent configuration group.
On the Agent configuration tab, scroll down until you see the Network Report section.
Enable IE Reports and Enable Chrome Reports
Click the Save Configuration button.

How Do Agents Handle Transaction Filters?

When the PerformanceGuard agent examines a web request to determine if the request is relevant for a transaction filter, the agent will go through the tags in the transaction filter one by one:

For each tag the agent tests if the regular expressions match.
If all regular expressions match the criteria, the agent constructs a tag ID and assigns that tag ID to the connection.
If a regular expression for a tag doesn't match, the agent considers the next tag in the transaction filter until it finds a match or there are no more tags left to examine.

View Transaction Data

To view transaction data in the PerformanceGuard web interface, select:

ANALYZE > Graphs > Time View > Transactions to view transaction response times, availability, etc. in a graph
ANALYZE > Graphs > Trend View > Transactions to view periodical trends in transaction response times, availability, etc.
ANALYZE > Graphs > Combined Bar Charts > Compare Transactions to compare transactions
Add Application Chart or Application Sunburst Widget to your dashboard

When is something considered to be available?

To answer this we need to look at response times: If response times are so long that use of a service, website, transaction or similar becomes impossible, PerformanceGuard considers the service, etc. to be unavailable.

By default, PerformanceGuard loses its patience with a service, etc. if it hasn't responded within 500,000 milliseconds (that's a little more than eight minutes).

Everything that's not unavailable, is considered by PerformanceGuard to be available. So, if you see that a service has been 100% available during the last week, it means that it has not exceeded the acceptable response time limit during the last week.

Do you measure availability of application pings (HTTP requests, ICMP ping and/or traceroutes)?

For application pings , PerformanceGuard looks not only at acceptable response times, but also at whether a response is expected or not: If the response is unexpected, for example if the response has a response code of 404 Not Found, PerformanceGuard considers the service to be unavailable, even if the response was received within acceptable time.

Do Your Transaction Filters Not Work?

See the troubleshooting topic Transaction Filters Don't Work.

Search this documentation

On this page

In this section