You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
title: 2. Example of RUM enablement in your Website
3
-
linkTitle: 2. Using RUM on your Website
4
-
menuPost: " <i class='fa fa-user-ninja'></i>"
2
+
title: 2. RUM instrumentation in a browser app
3
+
linkTitle: 2. RUM instrumentation
5
4
weight: 2
6
5
---
7
6
8
-
* Check the original HEAD section of your Online-boutique webpage (or use the examples here) in your browser
9
-
* Find the Web address of your workshop hosts Online Boutique
10
-
* Compare the changes made to the hosts Online-Boutique and compare with the base one.
7
+
* Check the HEAD section of the Online-boutique webpage in your browser
8
+
* Find the code that instruments RUM
11
9
12
10
---
13
11
14
12
## 1. Browse to the Online Boutique
15
13
16
-
If you have access to an EC2 instance and have previously installed the Online Boutique as part of the APM session, you can view it on port 81 of the EC2 instance's IP address.
17
-
18
-
If you have not got access to an EC2 instance with the Online Boutique installed then your workshop instructor will provide you with the Online Boutique URL that does not have RUM installed so that you can complete the next steps.
14
+
Your workshop instructor will provide you with the Online Boutique URL that has RUM installed so that you can complete the next steps.
19
15
20
16
## 2. Inspecting the HTML source
21
17
22
18
The changes needed for RUM are placed in the `<head>` section of the hosts Web page. Below is the updated `<head>` section with the changes required to enable RUM:
The first three lines (marked in red) have been added to the `<head>` section of the host Web page to enable RUM Tracing, the last three (marked in blue) are optional and used to enable Custom RUM events.
22
+
This code enables RUM Tracing, [Session Replay](https://docs.splunk.com/observability/en/rum/rum-session-replay.html), and [Custom Events](https://docs.splunk.com/observability/en/rum/RUM-custom-events.html) to better understand performance in the context of user workflows:
27
23
28
24
* The first part is to indicate where to download the Splunk Open Telemetry Javascript file from: `https://cdn.signalfx.com/o11y-gdi-rum/latest/splunk-otel-web.js` (this can also be hosted locally if so required).
29
-
* The second line defines the location where to send the traces to in the beacon url: `{beaconUrl: "https://rum-ingest.eu0.signalfx.com/v1/rum"`
25
+
* The next section defines the location where to send the traces to in the beacon url: `{beaconUrl: "https://rum-ingest.eu0.signalfx.com/v1/rum"`
30
26
* The RUM Access Token: `rumAuth: "<redacted>"`.
31
-
* Identification tags `app` and `environment` to indentify in the SPLUNK RUM UI e.g. `app: "ksnq-store", environment: "ksnq-workshop"}`
27
+
* Identification tags `app` and `environment` to indentify in the SPLUNK RUM UI e.g. `app: "frontend-demo-us-store", environment: "frontend-demo-us"}` (these values will be different in your workshop)
32
28
33
-
{{% notice title="Info" style="info" %}}
34
-
In this example the app name is **ksnq-store**, this will be different in the Workshop. Check with your host what the app name and environment to use in the RUM session will be and make a note of it!
35
-
{{% /notice %}}
29
+
The above lines 21 and 23-30 are all that is required to enable RUM on your website!
36
30
37
-
The above two lines are all that is required to enable RUM on your website!
31
+
Lines 22 and 31-34 are optional if you want Session Replay instrumented.
38
32
39
-
The (blue) optional section that uses `var tracer=Provider.getTracer('appModuleLoader');` will add a custom event for every page change allowing you to better track your website conversions and usage.
33
+
Line 36-39 `var tracer=Provider.getTracer('appModuleLoader');` will add a Custom Event for every page change, allowing you to better track your website conversions and usage.
Copy file name to clipboardExpand all lines: content/en/scenarios/3-optimize-end-user-experiences/2-rum/3-rum-landing.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,7 +10,7 @@ weight: 3
10
10
11
11
## 1. Visit the RUM Landing Page
12
12
13
-
Login into your Splunk IM/APM/RUM Website. From the left side menu bar select **RUM**. This will bring you to your the RUM Landing Page.
13
+
Login into Splunk Observability. From the left side menu bar select **RUM**. This will bring you to your the RUM Landing Page.
14
14
15
15
The goal of this page is to give you in a single page, a clear indication of the health, performance and potential errors found in your application(s) and allow you to dive deeper into the information about your User Sessions collected from your web page/App. You will have a pane for each of your active RUM applications. (The view below is the default expanded view)
Copy file name to clipboardExpand all lines: content/en/scenarios/3-optimize-end-user-experiences/2-rum/4-browser-summary.md
+17-19Lines changed: 17 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,14 +5,14 @@ weight: 4
5
5
---
6
6
7
7
* Get familiar with the UI and options available from this landing page
8
-
* Identify Page Views/Errors and Request/Errors and Java Script Errors in a single view </br>
8
+
* Identify Page Views/JavaScript Errors and Request/Errors in a single view </br>
9
9
Check the Web Vitals metrics and any Detector that has fired for in relation to your Browser Application
10
10
11
11
---
12
12
13
-
## 1. Application Summary Dashboard Overview
13
+
## Application Summary Dashboard
14
14
15
-
### 1.1. Header Bar
15
+
### 1.Header Bar
16
16
17
17
As seen in the previous section the RUM Application Summary Dashboard consists of 5 major sections.</br>
18
18
The first section is the selection header, where you can collapse the Pane via the  Browser icon or the **>** in front of the application name, which is *jmcj-store* in the example below. It also provides access to the *Application Overview* page if you click the link with your application name which is *jmcj-store* in the example below.
@@ -21,17 +21,13 @@ Further, you can also open the *Application Overview* or *App Health Dashboard*
21
21
22
22
23
23
24
-
First use the *View Dashboard* link to open the Browser App Health Dashboard which should open in a new tab. Then switch back to original RUM tab, and then use the *Open Application Overview* link, or click on the name of the app to launch the Application Overview dashboard.
24
+
For now, let's look at the high level information we get on the application summary dashboard.
25
25
26
-
We will looking at the *Application Overview* and *Browser App Health* Dashboards in detail in the following sections.
26
+
The RUM Application Summary Dashboard is focused on providing you with *at a glance* highlights of the status of your application.
The first section shows *Page Views / Errors*, & *Network Requests and Errors* charts show the quantity and trend of these issues in your application. This could be Javascript errors, or failed network calls to back end services.
30
+
The first section shows *Page Views / JavaScript Errors*, & *Network Requests and Errors* charts show the quantity and trend of these issues in your application. This could be Javascript errors, or failed network calls to back end services.
35
31
36
32
37
33
@@ -41,7 +37,7 @@ You can see the count of the Page Views / Network Requests / Errors by hovering
With the second section of the RUM Application Summary Dashboard we are showing you an overview of the JavaScript errors occurring in your application, along with a count of each error.
47
43
@@ -51,23 +47,23 @@ In the example above you can see there are three JavaScript errors, one that app
51
47
52
48
If you click on one of the errors a pop-out opens that will show a summary (below) of the errors over time, along with a Stack Trace of the JavaScript error, giving you an indication of where the problems occurred. (We will see this in more detail in one of the following sections)
The third section of the RUM Application Summary Dashboard is showing you the crucial (google) Web Vitals, three metrics, that are used by Google in its ranking system, and give a very good indication of the speed of your site for your end users.
54
+
The next section of the RUM Application Summary Dashboard is showing you [Google's Core Web Vitals](https://web.dev/articles/vitals), three metrics that are not only used by Google in its search ranking system, but also quantify end user experience in terms of loading, interactivity, and visual stability.
59
55
60
56
61
57
62
58
As you can see our site is well behaved and scores *Good* for all three Metrics. These metrics can be used to identify the effect changes to your application have, and help you improve the performance of your site.
63
59
64
-
If you click on any of the Metrics shown in the Web Vitals pane you will be taken to the corresponding Tag Spotlight Dashboard. e.g. clicking on the **Largest Contentful Paint (LCP)** chartlet, you will be taken to a dashboard similar to the screen shot below, that gives you timeline and table views for how this metric has performed. This should allow you to spot trends and identify where the problem may be more common, such as an OS or browser version, .
60
+
If you click on any of the Metrics shown in the Web Vitals pane you will be taken to the corresponding Tag Spotlight Dashboard. e.g. clicking on the **Largest Contentful Paint (LCP)** chartlet, you will be taken to a dashboard similar to the screen shot below, that gives you timeline and table views for how this metric has performed. This should allow you to spot trends and identify where the problem may be more common, such as an operating system, geolocation, or browser version.
The fourth and final section of the RUM Application Summary Dashboard is focused on providing you an overview of any detector that has triggered for your application. We have created a detector for this screen shot but your pane will be empty for now, but we will add some detectors to your site and make sure they are triggered in one of the next sections.
66
+
The final section of the RUM Application Summary Dashboard is focused on providing you an overview of recent detectors that have triggered for your application. We have created a detector for this screen shot but your pane will be empty for now. We will add some detectors to your site and make sure they are triggered in one of the next sections.
71
67
72
68
73
69
@@ -76,5 +72,7 @@ In the screen shot you can see we have a critical alert for the *RUM Aggregated
Please take a few minutes to experiment with the RUM Application Summary Dashboard and the underlying chart and dashboards before going on to the next section.
Copy file name to clipboardExpand all lines: content/en/scenarios/3-optimize-end-user-experiences/2-rum/5-analyzing-metrics.md
+3-1Lines changed: 3 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -44,14 +44,16 @@ First, we see page load and route change information, which can help us understa
44
44
45
45
46
46
47
-
Google has defined Core Web Vitals to quantify the user experience as measured by loading, interactivity, and visual stability.
47
+
Next, Google has defined Core Web Vitals to quantify the user experience as measured by loading, interactivity, and visual stability. Splunk RUM builds in Google's thresholds into the UI, so you can easily see if your metrics are in an acceptable range.
48
48
49
49
50
50
51
51
***Largest Contentful Paint (LCP)**, measures loading performance. How long does it take for the largest block of content in the viewport to load? To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading.
52
52
***First Input Delay (FID)**, measures interactivity. How long does it take to be able to interact with the app? To provide a good user experience, pages should have a FID of 100 milliseconds or less.
53
53
***Cumulative Layout Shift (CLS)**, measures visual stability. How much does the content move around after the initial load? To provide a good user experience, pages should maintain a CLS of 0.1. or less.
54
54
55
+
Improving Web Vitals is a key component to optimizing your end user experience, so being able to quickly understand them and create detectors if they exceed a threshold is critical.
56
+
55
57
Google has some great resources if you want to learn more, for example [the business impact of Core Web Vitals](https://web.dev/case-studies/vitals-business-impact).
With RUM instrumented, you will be able to better understand your end users, what they are doing, and what issues they are encountering.
8
+
With [RUM](https://docs.splunk.com/observability/en/rum/intro-to-rum.html) instrumented, we will be able to better understand our end users, what they are doing, and what issues they are encountering.
9
9
10
-
This workshop walks through how our demo site is instrumented and how to interpret the data. If you already have a RUM license, this will still help you understand how RUM works and how you can use it to optimize your end user experience.
10
+
This workshop walks through how our demo site is instrumented and how to interpret the data. If you already have a RUM license, this will help you understand how RUM works and how you can use it to optimize your end user experience.
11
+
12
+
Our Docs also contain guidance such as [scenarios using Splunk RUM](https://docs.splunk.com/observability/en/rum/rum-scenario-library/scenario-landingpage.html) and demo applications to test out [RUM for mobile apps](https://docs.splunk.com/observability/en/rum/sample-app.html).
0 commit comments