All Products
Search
Document Center

Application Real-Time Monitoring Service:Monitor DingTalk mini programs

Last Updated:Dec 30, 2024

This topic describes how to use the frontend monitoring feature of Application Real-Time Monitoring Service (ARMS) to monitor DingTalk mini programs. This topic also describes the general configurations, methods, and advanced scenarios of the feature.

Procedure

To monitor a DingTalk mini program, import and initialize the npm package required for monitoring, instrument the mini program to report logs, and then configure the security domain.

  1. Import and initialize the npm package.

    1. Import the npm package named arms/js-sdk into the DingTalk mini program. This npm package can then be used to report logs.

      npm install @arms/js-sdk                      
    2. Add the following code to the monitor.js file in the /utils directory to initialize the npm package.

      Note

      You can customize the name and storage path of the JS file.

      import EAppLogger from 'arms/js-sdk/miniapp';
      const Monitor = EAppLogger.init({
          pid: 'xxx',
          region: "cn", // The region where the mini program is deployed. Set the region parameter to cn if the mini program is deployed in China. Set the region parameter to sg if the mini program is deployed in or near Singapore. Set the region parameter to us if the mini program is deployed in or near the United States. 
      });
      
      export default Monitor;            
      Note

      For more information about parameter settings, see Common SDK parameters.

  2. Set security domain names.

    • If the region parameter is set to cn, add arms-retcode.aliyuncs.com to the HTTP security domain.

    • If the region parameter is set to sg, add arms-retcode-sg.aliyuncs.com to the HTTP security domain.

    • If the region parameter is set to us, add arms-retcode-us.aliyuncs.com to the HTTP security domain.

Other API methods

Method

Syntax

Description

setCommonInfo

{[key: string]: string;}

Set basic log fields for scenarios such as canary release.

setConfig

{[key: string]: string;}

Set the config field. For more information, see SDK reference.

pageShow

{}

Instrument the PV logs.

pageHide

{}

Instrument health logs.

error

String/Object

Instrument error logs.

api

For more information, see SDK methods.

Report the API request logs.

sum/avg

String

Report the custom sum and average logs.

Advanced scenarios

You can refer to the following advanced scenarios if the basic methods cannot meet your requirements:

  • Manually report the API request logs. Automatic reporting is disabled.

    1. Set the disableHook parameter to true. The logs of the dd.httpRequest method are not automatically reported.

    2. Manually call the api method to report the API request logs.

  • Disable automatic reporting and enable manual instrumentation.

    1. The hookApp and hookPage methods are no longer used in the app.js and page.js files.

    2. To report the PV logs of the page, call the pageShow method in the onShow method.

      Note

      Do not call the pageShow method together with the hookPage method. Otherwise, the PV logs are repeatedly reported.

      import Monitor from '/util/monitor';
      Page({
          onShow: function() {
              Monitor.pageShow();
          }
      })                         
    3. To report the health logs that indicate the health level and browsing time on the page, call the pageHide method in the onHide and onUnload methods.

      Note

      Do not call the pageHide method together with the hookPage method. Otherwise, the health logs are repeatedly reported.

      import Monitor from '/util/monitor';
        Page({
      
            onHide: function() {
                Monitor.pageHide();
            },
            onUnload: function() {
                Monitor.pageHide();
            }
            ... 
        })                    

Common SDK parameters

The frontend monitoring feature of ARMS allows you to set a variety of SDK parameters to meet additional requirements. The following table describes the common parameters suitable for the scenarios described in this topic.

pid

String

The unique ID of the project. It is automatically generated by ARMS when it creates a site.

Yes

None

uid

String

The ID of the user. The value is an identifier of the user and can be used to search for the user. You can specify a custom value. If you do not specify this parameter, the SDK is automatically generated and updated every six months.

No

Automatically generated by the SDK

tag

String

The input tag. Each log carries a tag.

No

None

release

String

The version of the application. We recommend that you configure this parameter to view the report information of different versions.

No

undefined

environment

String

The environment field. Valid values: prod, gray, pre, daily, and local.

  • The value prod indicates an online environment.

  • The value gray indicates a phased-release environment.

  • The value pre indicates a staging environment.

  • The value daily indicates a daily environment.

  • The value local indicates a local environment.

No

prod

sample

Integer

The log sampling configuration. The value is an integer from 1 to 100. The performance logs and success API logs are sampled at the 1/sample ratio. For more information about the metrics of performance logs and success API logs, see Statistical metrics.

No

1

behavior

Boolean

Specifies whether to record the user behavior that reports errors for easy troubleshooting.

No

false

enableLinkTrace

Boolean

For more information about back-to-back Tracing Analysis, see Use the front-to-back tracing feature to diagnose API errors.

No

false

The ARMS frontend monitoring feature also provides other SDK parameters to meet your business requirements. For more information, see SDK reference.