All Products
Search
Document Center

Application Real-Time Monitoring Service:Monitor DingTalk mini programs

Last Updated:Sep 03, 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.

Background information

For more information about DingTalk mini programs, see Documentation of DingTalk mini programs.

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 alife-logger into the DingTalk mini program. This npm package can then be used to report logs.
      npm install alife-logger                      
    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 'alife-logger/eapp';
      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. Use the following methods to automatically collect and report the logs about page views (PVs), errors, API requests, performance, and health.
    1. In the app.js file, call the Monitor.hookApp(options) method to automatically capture error logs. The options parameter is an app-specific object.
      import Monitor from '/util/monitor';
      
      App(Monitor.hookApp({
        onError(err) {
            console.log('Trigger onError:', err);
        },
        onLaunch() {
          console.log('Trigger onLaunch');
        },
      
        onShow(options) {
        },
        onHide() {
        }
      }));                         
    2. In the page.js file, call the Monitor.hookPage(options) method to automatically report the logs about API requests, PVs, and health.
      import Monitor from '/util/monitor';
      // After you call the hookPage method, the lifecycle-based API automatically starts instrumentation. 
      Page(Monitor.hookPage({
         data: {},
          onLoad(query) {
          },
          onReady() {
          // The page is loaded. 
          },
          onShow() {
      
          },
          onLoad(query) {
      
          },
          onHide() {
      
          },
          onUnload() {
      
          }     
      }));                        
  3. Configure the security domain.
    • 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.

Basic methods for automatic instrumentation

MethodSyntaxDescriptionScenario
hookApp{}Enter the source app parameters. Perform automatic instrumentation during the lifecycle of the app.
hookPage{}Enter the source page parameters. Perform automatic instrumentation during the lifecycle of the page.
Note If you want to call the hookApp or hookPage method to track and monitor mini programs, the code of the mini programs must conform to the app and page conventions for standard mini programs. The onError method must be included in the code of the application. The onShow, onHide, and onUnload methods must be included in the code of the page. For information about the examples of the methods, see Procedure.

Methods for other settings

MethodSyntaxDescription
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{}Report the PV logs.
pageHide{}Report the health logs.
errorString/ObjectReport the error logs.
apiFor more information, see SDK methods.Report the API request logs.
sum/avgStringReport 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.