Use the front-to-back tracing feature to diagnose causes of API errors

Configure ARMS browser monitoring

The API and the domain name of the application have the same origin.

1. Check whether the frontend connects to the backend.
2. Do not select the Disable Automatic API Reporting option. Enable the automatic API reporting.
3. Set enableLinkTrace to true to enable the front-to-back tracing feature. The following sample code shows how to enable the front-to-back tracing feature:

   <script>
   !( function(c,b,d,a){c[a]||(c[a]={});c[a].config={pid:"xxx",imgUrl:"https://arms-retcode.aliyuncs.com/r.png?", enableLinkTrace: true};
   with(b)with(body)with(insertBefore(createElement("script"),firstChild))setAttribute("crossorigin","",src=d)
   })(window,document,"https://retcode.alicdn.com/retcode/bl.js","__bl");
   </script>                         

The API and the domain name of the application do not have the same origin.

1. Check whether the frontend connects to the backend.
2. Set enableLinkTrace and enableApiCors to true.

   <script>
   !( function(c,b,d,a){c[a]||(c[a]={});c[a].config={pid:"xxx",imgUrl:"https://arms-retcode.aliyuncs.com/r.png?", 
   enableLinkTrace: true, enableApiCors: true};
   with(b)with(body)with(insertBefore(createElement("script"),firstChild))setAttribute("crossorigin","",src=d)
   })(window,document,"https://retcode.alicdn.com/retcode/bl.js","__bl");
   </script>

   Notice If enableApiCors is set to true, the backend service must also support cross-domain requests and custom header values. Make sure that all requests can be called in combinations as expected. Otherwise, these requests may fail. The following sample code shows how to configure NGINX:

   upstream test {
           server 192.168.220.123:9099;
           server 192.168.220.123:58080;
       }
       server {
           listen    5800;
           server_name  192.168.220.123;
           root         /usr/share/nginx/html;
           include /etc/nginx/default.d/*.conf;
           location / {
               proxy_pass http://test;
               proxy_set_header Host $host:$server_port;
               proxy_set_header X-Real-IP $remote_addr;
               proxy_set_header X-Real-PORT $remote_port;
               proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
               proxy_set_header   EagleEye-TraceID $eagleeye_traceid;
               proxy_set_header   EagleEye-SessionID $eagleEye_sessionid;
               proxy_set_header   EagleEye-pAppName $eagleeye_pappname;
           }

3. Configure the Ignore method. For more information, see . The following sample code shows how to configure the Ignore method:

   let whitelist = ['api.xxx','source3']; // The whitelist.
   let blacklist = ['source2','source6']; // The blacklist.
   // You can select a blacklist and whitelist based on your business requirements. The whitelist and blacklist are controlled by the returned true and false values of the method.
   ignore: {
               ignoreApis: [
                   function(str) {   // The method.
                       if (whitelist.includes(str)) {
                           return false;
                       }
                       return true; // Ignore if true is returned.
                   }]
            }

   Note The Ignore method is similar to blacklists and whitelists. This method prevents header modifications against unauthorized third-party resource requests and errors of resource requests.

Principle

• If automatic API reporting is enabled and the API and the domain name of the application have the same origin, the EagleEye-TraceID and EagleEye-SessionID custom headers are added to the API request headers. EagleEye-TraceID is the identifier of the trace that connects the frontend and backend.
• If the API and the domain name of the application do not have the same origin, no custom headers are added to the API request headers. This ensures that the application can send requests as expected.
• To check whether the front-to-back tracing configurations have taken effect, go to the console and view the API request headers. If the EagleEye-TraceID and EagleEye-SessionID headers are included in the API request headers, the configurations have taken effect.
  Warning The values of EagleEye-TraceID and EagleEye-SessionID are automatically generated. We recommend that you do not manually set the values.

  

Scenarios and cases

If a request takes a longer time than expected, you can determine whether the cause is network transmission or backend call process based on the call timeline. You can also click thread profiling of the backend application to view the complete backend trace of the request. In this case, you can identify the cause of an API error based on the business.

• Locate the error if the API returns an error code or a business logic error occurs.

  1. Log on to the ARMS console.
  2. In the left-side navigation pane, click Browser Monitoring. On the Browser Monitoring page, click the name of the application. In the left-side navigation pane, click API Request.

  3. On the API Failure List tab of the API Link Trace(Top20) section, find the API or trace ID, and click Link Trace. You can then view the overall response time of browser monitoring and the call sequence chart of the backend application.

     

  4. Determine whether the network transmission or backend call process takes a longer time based on the call timeline.

  5. Click the Magnifier icon in the Method Stack column of the backend application to view the overall backend trace of the request. You can then locate the cause of the API error based on the business.

     

• Locate the error if the response time of the API is longer than expected.

  1. Log on to the ARMS console.
  2. In the left-side navigation pane, click Browser Monitoring. On the Browser Monitoring page, click the name of the application. In the left-side navigation pane, click API Request.

  3. In the API Link Trace(Top20) section, the APIs are sorted in descending order by response time. or trace ID. You can find the API or trace ID whose response time is longer than expected,

  4. and click Link Trace. You can then view the overall response time of browser monitoring and the call sequence chart of the backend application.

     • If the processing time of the backend application is short but the overall response time is long, the network transmission takes a longer time. Click View Details. On the details page, view the network, region, browser, device, and operating system of the access request.
     • If the backend application takes a long time to process the access request, the backend processing performance is poor. Click the Magnifier icon in the Method Stack column. In the dialog box that appears, check which part of backend tracing is time-consuming to locate the problem.