View the abnormal interfaces and stacks of an application - Application Real-Time Monitoring Service

After you install an Application Real-Time Monitoring Service (ARMS) agent for a Java application, ARMS starts to monitor the application. You can query the number of exceptions by name, interface, or host on the Exceptions page to optimize the code that generates the exceptions.

Important

Application Monitoring provides a new application details page for users who have enabled the new billing mode.

If you have not enabled the new billing mode, click Switch to New Version on the Application List page to view the new application details page.

Scenarios

ARMS records exceptions only if they propagate outside try-catch blocks. Assume the ARMS agent has instrumented public void methodA and public void methodB, which call each other:

Scenario 1: Both methods catch exceptions.

    public int methodA() {
        try {
            return methodB();
        } catch (Throwable e) {
            e.printStackTrace();
            return 0;
        }
    }

    public int methodB() {
        try {
            return 1 / 0;
        } catch (Throwable e) {
            e.printStackTrace();
            return 0;
        }
    }

Result: ARMS records no exceptions because they are caught and handled within the try-catch blocks.

Scenario 2: methodA catches an exception, whereas methodB returns one.

    public int methodA() {
        try {
            return methodB();
        } catch (Throwable e) {
            e.printStackTrace();
            return 0;
        }
    }

    public int methodB() {
        return 1 / 0;
    }

Result: ARMS records one java.lang.ArithmeticException exception (uncaught in methodB).

Scenario 3: Both methods return exceptions.

    public int methodA() {    
        return methodB();
    }

    public int methodB() {
        return 1 / 0;
    }

Result: ARMS records two java.lang.ArithmeticException exceptions.

Scenario 4: methodA catches methodB’s exception and rethrows it as RuntimeException.

    public static int methodA() {
        try {
            return methodB();
        } catch (Throwable e) {
            throw new RuntimeException(e);
        }
    }

    public static int methodB() {
        return 1 / 0;
    }

Result: ARMS records one java.lang.ArithmeticException exception (uncaught in methodB) and one java.lang.RuntimeException exception (thrown by methodA).

Procedure

Log on to the ARMS console. In the left-side navigation pane, choose Application Monitoring > Application List.
Select a region in the top navigation bar and click an application.
Note
Icons in the Language column indicate the application's programming language:
- : Java
- : Go
- : Python
- - (Hyphen): an application monitored in Managed Service for OpenTelemetry
In the top navigation bar, choose Scenario-based Analysis > Exceptions.
- In the Quick Filter section (icon 1), you can query exceptions by Exception, Operation, or Host.
- In the trend charts section (icon 2), you can view the number of times that the application throws an exception within the specified time period. The columns with different exceptions are stacked on top of each other.
  Click the icon. In the dialog box that appears, you can view the metric data in a specific period of time or compare the metric data in the same time period across different dates. You can click the icon to display the data in a column chart or a trend chart.
- In the exception list section (icon 3), you can view the name, number of occurrences, percentage, and overview information of each exception.
  In the exception list, perform the following operations based on your needs:
  - Click Overview in the Actions column to view the trends in the number of exceptions, the distribution of interfaces and instances, and abnormal stacks in the panel that appears.
  - Click Traces in the Actions column to view the trace details of an interface. For more information, see Trace Explorer.

Reference

For information about Application Monitoring metrics, see Application Monitoring metrics.

FAQs

Why are the number of exceptions in interface calls greater than the number of interface requests?

The issue may occur due to one of the following reasons:

ARMS records an exception count when an instrumented method throws an exception. If multiple methods throw exceptions during a single interface call and these methods are automatically instrumented by the ARMS agent, ARMS will record multiple exceptions within that one call.
If the same exception propagates from a lower-level method to a top-level method, and multiple methods in the call stack are instrumented, this exception will be recorded multiple times.

Why did exceptions change after the ARMS agent was upgraded?

Each time the ARMS agent is upgraded, the instrumented methods may increase or decrease. Consequently, the number of exceptions thrown within these instrumented methods may also increase or decrease accordingly.

Why were no related exceptions caught by the business logic even though the exception count in the interface is not zero?

In most instrumented framework code, when certain exceptions are caught and handled within the framework layer and not thrown to the business code, the ARMS agent can capture these exceptions, but you may not perceive them.

For example, when using MongoTemplate to access MongoDB without encountering errors, you may still see MongoDB access errors in the ARMS console. This is because MongoTemplate encapsulates retry logic. During a single method call of MongoTemplate, if a timeout exception occurs, it will retry and only throw an exception to the caller after multiple retries fail. Therefore, when using MongoTemplate to access MongoDB with underlying retry behavior, the business logic may not see the exception, but exceptions are visible in the ARMS console.

Why does the exception stack not match the actual exceptions that occurred in the interface?

To improve data processing and reporting efficiency, the ARMS agent generates a string based on the exception class name, the first three lines of the exception method stack, and the last three lines of the exception method stack. It then encodes this string into a 32-bit string using CRC64. On the first report, both the encoded value and the original value are reported. Subsequent reports for the same exception only include the encoded value. In the following scenarios, the exception stack does not match the actual stack:

The complete method stacks of two exceptions are different, but their exception class names, the first three lines of the exception method stack, and the last three lines of the exception method stack are the same. In this case, the processing logic results in the same encoded value, causing a mismatch.
The exception class names, the first three lines of the exception method stack, and the last three lines of the exception method stack of two exceptions are different, but due to the non-uniqueness of CRC64 encoding, their encoded values may still be the same, causing a mismatch.

To fix the mismatch, you can increase the value of the Similar exception stack differentiation depth parameter in the Exception Advanced Filtering Configuration section of the Custom Configurations tab.

Why does the ARMS console show only one ID in exceptions after the application has been running for over 30 days?

To optimize the volume of data reported, when an exception occurs for the first time, the system encodes the exception and reports both the encoded value and the original value to the server. The server stores this encoded value along with the original value, with a storage duration of 30 days. After the application has been running for 30 days, it may no longer be possible to retrieve the original value of the exception using its encoded value.

Why are some exceptions not shown in the ARMS console?

The ARMS agent cannot capture all exceptions. Only exceptions thrown by instrumented methods can be collected by the agent.

If the ARMS agent is v4.1.12 or later, you can turn on the plug-in corresponding to the exception in the Probe switch settings section of the Custom Configurations tab. Then, ARMS will collect the exception data when each exception occurs.