-
-
-
Web App Monitoring
-
-
This content has been machine translated dynamically.
Dieser Inhalt ist eine maschinelle Übersetzung, die dynamisch erstellt wurde. (Haftungsausschluss)
Cet article a été traduit automatiquement de manière dynamique. (Clause de non responsabilité)
Este artículo lo ha traducido una máquina de forma dinámica. (Aviso legal)
此内容已经过机器动态翻译。 放弃
このコンテンツは動的に機械翻訳されています。免責事項
이 콘텐츠는 동적으로 기계 번역되었습니다. 책임 부인
Este texto foi traduzido automaticamente. (Aviso legal)
Questo contenuto è stato tradotto dinamicamente con traduzione automatica.(Esclusione di responsabilità))
This article has been machine translated.
Dieser Artikel wurde maschinell übersetzt. (Haftungsausschluss)
Ce article a été traduit automatiquement. (Clause de non responsabilité)
Este artículo ha sido traducido automáticamente. (Aviso legal)
この記事は機械翻訳されています.免責事項
이 기사는 기계 번역되었습니다.책임 부인
Este artigo foi traduzido automaticamente.(Aviso legal)
这篇文章已经过机器翻译.放弃
Questo articolo è stato tradotto automaticamente.(Esclusione di responsabilità))
Translation failed!
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 sourcetypeuberAgent: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-->
Share
Share
In this article
This Preview product documentation is Citrix Confidential.
You agree to hold this documentation confidential pursuant to the terms of your Citrix Beta/Tech Preview Agreement.
The development, release and timing of any features or functionality described in the Preview documentation remains at our sole discretion and are subject to change without notice or consultation.
The documentation is for informational purposes only and is not a commitment, promise or legal obligation to deliver any material, code or functionality and should not be relied upon in making Citrix product purchase decisions.
If you do not agree, select I DO NOT AGREE to exit.