Application Real-Time Monitoring Service:Exception analysis

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. Both exceptions are caught and handled within their respective try-catch blocks.

Scenario 2: methodA catches, methodB does not

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 -- the uncaught exception in methodB. The exception is caught in methodA, so methodA does not generate an additional record.

Scenario 3: Neither method catches the exception

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

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

Result: ARMS records two java.lang.ArithmeticException exceptions -- one in each instrumented method, because neither catches the exception.

Scenario 4: methodA catches and rethrows as a different type

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

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

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

Resolve mismatched exception stacks

Two situations can cause a mismatch between the displayed stack and the actual exception:

To resolve mismatches, increase the Similar exception stack differentiation depth parameter in the Exception Advanced Filtering Configuration section of the Custom Configurations tab.

Quick filters

Use the Quick Filter section to narrow results by Exception, Operation, or Host.

Trend charts

The trend chart displays exception counts over the selected time period. Each exception type appears as a stacked column.

• Click the icon to view metrics for a specific time range or compare the same period across different dates.

• Click the icon to switch between a column chart and a trend chart.

Exception list

The exception list shows each exception's name, occurrence count, percentage, and summary.

• View the overview: Click Overview in the Actions column to see exception count trends, interface and instance distribution, and exception stacks.

  

• Investigate traces: Click Traces in the Actions column to view trace details for a specific interface. For more information, see Trace Explorer.

Why is the exception count higher than the request count for an interface?

This typically happens for one of two reasons:

• A single request can trigger multiple instrumented methods. If several of these methods throw exceptions during one request, ARMS records each one separately.

• When the same exception propagates up the call stack through multiple instrumented methods, each method records the exception independently.

See Scenario 3 and Scenario 4 for examples of how a single error produces multiple exception records.

Why did exception counts change after an agent upgrade?

Each agent version instruments a different set of methods. When instrumented methods increase or decrease after an upgrade, the number of captured exceptions changes accordingly.

Why does ARMS show exceptions that the application code does not catch?

Some framework-level code catches and handles exceptions internally without propagating them to your business logic. The ARMS agent can still capture these exceptions at the framework layer.

For example, MongoTemplate in Spring Data includes built-in retry logic. If a timeout occurs during a MongoDB operation, MongoTemplate retries automatically and only throws an exception to the caller after all retries fail. During this process, ARMS captures the intermediate timeout exceptions even though your application code never sees them.

Why are some exceptions missing from the ARMS console?

ARMS can only capture exceptions thrown by instrumented methods. Exceptions in non-instrumented code are not collected.

If you use ARMS agent v4.1.12 or later, enable the corresponding plugin in the Probe switch settings section of the Custom Configurations tab. This allows ARMS to capture exception data for each occurrence.

Why does the console show only an encoded ID instead of exception details after 30 days?

To reduce data volume, the ARMS agent encodes exception stacks on first occurrence and reports only the encoded value for subsequent occurrences. The server stores the mapping between encoded values and original stacks for 30 days. After this period, the original exception details may no longer be available.

See How ARMS groups exceptions for details on the encoding mechanism.