To use the browser monitoring feature of Application Real-Time Monitoring Service (ARMS) to monitor web applications, you must install the probe by using content delivery network (CDN) or Node Package Manager (NPM). This topic describes how to install the ARMS browser monitoring probe on web applications by using CDN.

Install the browser monitoring probe

  1. Log on to the ARMS console.
  2. In the left-side navigation pane, click Browser Monitoring. On the Browser Monitoring page, click Create Application Site in the upper-right corner.
  3. In the Create Application Site dialog box, select web as the monitoring type, enter the application name, and then click OK.
    Dialog Box Create New Site
  4. Find the monitored application and click Settings in the Actions column.
  5. In the SDK Extension Configuration section of the settings page, select the required options. The code of the BI probe to be pasted into the page is then generated based on the selected options.
    • Disable Automatic API Reporting: If you select this option, you must manually call the __bl.api() method to report the API success rate.
    • Enable Automatic SPA Parsing: If you select this option, ARMS monitors the hashchange event of the page and automatically reports page views (PVs). This option is applied to single-page applications (SPAs).
    • Enable Data Collection of First Meaningful Paint: If you select this option, AMRS collects data of First Meaningful Paint (FMP).
    • Enable Page Resources Reporting: If you select this option, static resources loaded on the page are reported when the onload event is triggered.
    • Associate with Application Monitoring: If you select this option, API requests are in end-to-end association with application monitoring.
    • Enable User Behavior Trace: If you select this option, you can view user behavior trace in JS Error Diagnosis.
    • Enable Console Tracing: If you select this option, user behavior is traced in the console. The behavior can be error, warn, log, or info.
      Notice This feature affects the path of the Console panel.
  6. Install the probe by using one of the following methods:
    • Asynchronous loading: copy the provided code, paste it to the first line of the <body> element of the HTML page, and then restart the application.tab_bm_async_load
    • Synchronous loading: copy the provided code, paste it to the first line of the <body> element of the HTML page, and then restart the application.tab_bm_sync_load
    • npm package:
      1. Run the following command to install the npm package:
        npm install alife-logger --save
      2. Copy and run the following command from the console to initialize the npm package:
        const BrowserLogger = require('alife-logger');
        const __bl = BrowserLogger.singleton({pid:"b590lhguqs@8cc3f63543d****",appType:"web",imgUrl:"",sendResource:true,behavior:true,enableLinkTrace:true,enableConsole:true});

Differences between asynchronous loading and synchronous loading

  • Asynchronous loading: It is also known as non-blocking loading. In asynchronous loading, the browser does continue to process subsequent pages after the JS loading is complete. We recommend that you use this method if you require high page performance.
    Notice If you use asynchronous loading, ARMS cannot capture JS errors or resource loading errors before the monitoring SDK completes the initialization.
  • Synchronous loading: It is also known as blocking loading. In synchronous loading, the browser does not continue to process subsequent pages until the JS loading is complete. We recommend that you use synchronous loading if you need to capture JS errors and resource loading errors during the whole process.

Custom UID

When the ARMS browser monitoring probe is installed by using synchronous or asynchronous loading, the web SDK automatically generates a user ID (UID) to collect information such as the number of unique visitors (UVs). The UID can be used to identify a user but does not have service attributes. If you want to customize a UID, add the following content to config in the code:

uid: 'xxx', // The UID is used to identify a user. You can specify the UID based on your business requirements.

Sample code:

!( function(c,b,d,a){c[a]||(c[a]={});c[a].config={pid:"xxx",appType:undefined,imgUrl:"", uid: "xxxx"};
Notice If you modify options in the SDK Extension Configuration section, the code changes. Copy and paste the code again.

Common SDK parameters

The browser monitoring feature of ARMS allows you to configure a variety of SDK parameters to meet your business requirements. The following table lists the common parameters that you can specify in the scenarios described in this topic.

Parameter Type Description Required Default Value
pid String The unique ID of the project, which is automatically generated when ARMS creates the site. Yes No default value
uid String The user ID, which is used to identify the user. You can manually configure the ID to search for the user based on the user ID. If this parameter is not configured, the updates are automatically generated by the SDK and updated every six months. No Generated by the SDK
tag String The input tag. Each log carries a tag. No No default value
release String The version of the application. We recommend that you configure to view the reports of different versions. No undefined
environment String The production environment. Valid values: prod, gray, pre, daily, and local.
  • prod indicates the online environment.
  • gray indicates the grayscale environment.
  • pre: the staging environment.
  • daily indicates the daily environment.
  • local indicates the local environment.
No prod
sample Integer The sampling configuration of the log. The value ranges from 1 to 100. Sample Performance logs and successful API logs in accordance with the 1/sample ratio. For more information about the metrics of performance logs and successful API logs, see Statistical metrics. No 1
behavior Boolean Whether to record the user behavior to facilitate troubleshooting. No true
enableSPA Boolean Specifies whether to monitor the hashchange event on the page and report page view (PV) again. It is applicable to spa scenarios. No false
enableLinkTrace Boolean For more information about front-to-back tracing, see Use the front-to-back tracing feature to diagnose causes of API errors. No false

The browser monitoring feature of ARMS also provides more SDK configuration items to further meet your requirements. For more information, see SDK reference.