uberAgent

Web App Monitoring

What Is Web App Monitoring

uberAgent web app monitoring records page loads and XmlHttpRequests. For every such event, uberAgent collects the duration, the user, and the HTTP status code (plus some additional information). Web app monitoring works on every website and in all major browsers.

In the default configuration, uberAgent does not send full URLs to the backend. Instead, events are summarized per webserver (the host displayed in the browser’s address bar). Full URL monitoring can optionally be enabled for specific domains or sites of interest.

Use Cases for Web App Monitoring

By providing insights into browser and website usage, uberAgent web app monitoring enables the following use cases:

  • Measuring web page load performance
  • Calculating web app usage
  • Collecting an inventory of web apps
  • Tracking the user journey on a website

Which Data is Collected by Web App Monitoring

The data collected as part of uberAgent web app monitoring is sent to the backend via the sourcetypes listed in the browser metrics documentation.

Additionally, some fields in the SessionDetail sourcetype (docs) are populated through web app metrics.

Requirements & Installation

Web App monitoring requires the uberAgent browser extensions to be installed in the end user’s web browser. Please see the installation instructions for details on how to install the browser extensions.

Enabling or Disabling Web App Monitoring

uberAgent web app monitoring is enabled or disabled via the BrowserPerformance* timer metrics in the configuration. In the default configuration, web app monitoring is enabled for all supported browsers.

Full URL Monitoring

What Is Full URL Monitoring

Full URL monitoring optionally includes additional URL components in the following browser web app events or fields:

  • the sourcetype uberAgent:Application:BrowserWebRequests2 (docs)
  • the field SessionFgBrowserActiveTabHost of the sourcetype uberAgent:Session:SessionDetail (docs)

By default, full URL monitoring is disabled. The path and query components are stripped from URLs sent to the backend, i.e., uberAgent only records the scheme (e.g., https), the host (e.g., www.domain.com) and the port (unless it’s a standard port, e.g., 443 for https).

Example of the default behavior:

  • Full URL in the browser: https://splunk1.domain.com:8000/en-US/app/uberAgent/session_user_detail?earliest=-1h&latest=now
  • Shortened URL in uberAgent event: https://splunk1.domain.com:8000

Configuring Full URL Monitoring

The default level of URL component detail can be changed by adding items in the [BrowserWebAppURL_ComponentDetail] stanza of the configuration.

Please note that URL allowlists and denylists ([BrowserWebAppURL_Filter] stanza) have precedence over [BrowserWebAppURL_ComponentDetail]. In other words, the level of detail configuration only applies to URLs that are not filtered by a deny or allow list.

BrowserWebAppURL_ComponentDetail

Format of entries in the [BrowserWebAppURL_ComponentDetail] stanza:

URL_REGEX = COMPONENT_DETAIL_SPEC
or:
URL_REGEX = COMPONENT_DETAIL_SPEC_TAB;COMPONENT_DETAIL_SPEC_REQUEST
<!--NeedCopy-->

Note: see the definition of URL_REGEX.

Tab URLs are matched against the regular expressions (URL_REGEX) of the items in the [BrowserWebAppURL_ComponentDetail] stanza. For matching URLs, COMPONENT_DETAIL_SPEC specifies which level of detail is recorded of the tab and request URLs.

Note:

  • Tab URLs are URLs in the browser’s address bar
  • Request URLs are URLs the browser communicates with

Optionally, the detail level of the request URL can be set independently of the detail level of the tab URL by using the second format shown above.

Multiple URL component detail specs can be specified in a single [BrowserWebAppURL_ComponentDetail] stanza. Matching is performed in the order in which items are listed. The first matching item wins.

COMPONENT_DETAIL_SPEC

Format of the URL component detail specification (COMPONENT_DETAIL_SPEC):

host[:path[(DEPTH)]] [:query[(PARAMS)]]

with:

  • DEPTH: the number of path elements to include. Without DEPTH, the entire path is included.
  • PARAMS: comma-separated list of regular expressions specifying query parameters to include. Without PARAMS, all query parameters are included. Details:

    • Query parameters to be included are specified as regular expressions.
    • Matching is case-sensitive.

Examples: Same Level of Detail for Tab URL and Request URL

The following examples show the effect of different configurations in a scenario where the tab URL and the request URL are identical:

  • Tab URL: https://splunk1.domain.com:8000/en-US/app/uberAgent/session_user_detail?earliest=-1h&latest=now
  • Request URL: https://splunk1.domain.com:8000/en-US/app/uberAgent/session_user_detail?earliest=-1h&latest=now

Host and Path

Capture URLs on splunk1.domain.com including the path, but excluding the query:

.*\.?splunk1\.domain\.com/.*$ = host:path

Result:

https://splunk1.domain.com:8000/en-US/app/uberAgent/session_user_detail

Host and 2 Path Elements

Capture URLs on splunk1.domain.com including the path, but only the first two elements:

.*\.?splunk1\.domain\.com/.*$ = host:path(2)

Result:

https://splunk1.domain.com:8000/en-US/app

Host, Path, and Query

Capture URLs on splunk1.domain.com including the path and all query parameters:

.*\.?splunk1\.domain\.com/.*$ = host:path:query

Result:

https://splunk1.domain.com:8000/en-US/app/uberAgent/session_user_detail?earliest=-1h&latest=now

Host, 1 Path Element, and 1 Query Parameter

Capture URLs on splunk1.domain.com including the first path element and the query parameter earliest:

.*\.?splunk1\.domain\.com/.*$ = host:path(1):query(earliest)

Result:

https://splunk1.domain.com:8000/en-US?earliest=-1h

Host, 1 Path Element, and 1 Query Parameter Regex

Capture URLs on splunk1.domain.com including the first path element and all query parameters that match the regular expression .+est:

.*\.?splunk1\.domain\.com/.*$ = host:path(1):query(.+est)

Result:

https://splunk1.domain.com:8000/en-US?earliest=-1h&latest=now

Examples: Different Level of Detail for Tab URL and Request URL

The following examples show the effect of different configurations in a scenario where the tab URL and the request URL are different:

  • Tab URL: https://splunk1.domain.com:8000/en-US/app/uberAgent/session_user_detail?earliest=-1h&latest=now
  • Request URL: https://www.example.org/images/uberAgent

Tab URL: Host Only, Request URL: Host and Path

Capture only the host of the tab URL, but the host and the path of the request URL:

.*\.?splunk1\.domain\.com/.*$ = host;host:path

Result:

Tab URL:     https://splunk1.domain.com:8000/
Request URL: https://www.example.org/images/uberAgent
<!--NeedCopy-->

Tab URL: Host and Path, Request URL: Host Only

Capture the host and the path of the tab URL, but only the host of the request URL:

.*\.?splunk1\.domain\.com/.*$ = host:path;host

Result:

Tab URL:     https://splunk1.domain.com:8000/en-US/app/uberAgent/session_user_detail
Request URL: https://www.example.org
<!--NeedCopy-->
Web App Monitoring