How to Leverage ARMS Configuration Templates for Flexible Java Monitoring

Overview

Traditional Application Performance Monitoring (APM) relies on framework‑level instrumentation and backend services to collect full‑stack trace, metric, log, and profiling data. While this ensures comprehensive fault diagnosis, cost‑sensitive, resource‑constrained, or high‑performance scenarios require lighter‑weight solutions.

Monitoring Demand Levels

Basic monitoring : For testing, pre‑release, or non‑core applications, simple JVM metrics (heap, GC) combined with lightweight diagnostics (memory dump, continuous profiling, Arthas) are sufficient.

Custom monitoring : Mature applications often need user‑defined logs, metrics, and spans defined inside the application.

ARMS Configuration Templates

ARMS provides L1‑L3 observability through configuration templates. Each template represents a monitoring scenario and can be selected globally or per application.

Built‑in Templates

JVM JMX template : Collects over 20 key JMX metrics (heap, threads, class loading) with <1% performance overhead and roughly 1 GB of data per node per day.

Full APM template : Captures trace, exception stack, RED metrics, JVM metrics, and profiling data, covering most error, latency, and performance issues; overhead is typically below 10% with about 15 GB of data per node per day.

Custom Templates

Users can clone a built‑in template and adjust specific monitoring configurations to create a custom template that matches their needs.

Applying Templates

In the ARMS console, open the Cloud Monitoring 2.0 workspace, navigate to the configuration‑template management page, and view all templates (name, description, type, source, language, global flag).

Assign a template to an application either by setting it as the global template for the workspace or by adding the label apsara.apm/armsConfigTemplate with the template name in the application’s YAML (this method has higher priority).

Example Java SDK code to create an application with a specific template:

public static CreateServiceResponse createApp(String workspace, String appName, String configTemplateName, String regionId) {
    try {
        Config config = new Config();
        config.setAccessKeyId("your ak");
        config.setAccessKeySecret("your sk");
        config.setEndpoint(String.format("cms.%s.aliyuncs.com", regionId));
        Client client = new Client(config);
        CreateServiceRequest request = new CreateServiceRequest();
        request.setServiceName(appName);
        request.setServiceType("TRACE");
        request.setAttributes(String.format("{\"armsConfigTemplate\":\"%s\", \"language\":\"JAVA\"}", configTemplateName));
        return client.createService("default-cms-1672753017899339-cn-hangzhou", request);
    } catch (Exception e) {
        e.printStackTrace();
        return null;
    }
}

Advanced Extensions

1. Deep Framework Observation

Scenario: monitor web services (Tomcat/Spring MVC), RPC frameworks (Dubbo/gRPC), or databases (MySQL/Redis). Steps: (1) Enable the corresponding plugin module in the application configuration page; (2) Restart the application instance to activate the updated collector.

2. Performance Bottleneck Diagnosis

Enable Continuous Profiling.

Use flame‑graph visualizations to analyze hot‑spot method call trees.

3. Business‑Level Observability Customization

Define business‑critical metrics (e.g., order processing rate, API P99 latency SLO) using the OpenTelemetry SDK (Counter, Gauge, Histogram) and register custom collection rules in the monitoring configuration center.

Governance and Best Practices

When a monitoring configuration achieves an optimal balance of coverage, performance overhead, and storage cost, adopt the following practice:

Save the current application configuration as a custom template.

(Optional) Set this template as the global configuration template for the workspace.

New applications can choose to apply the saved template during onboarding.

This mechanism ensures versioned management of monitoring policies and facilitates enterprise‑wide best‑practice reuse.

Conclusion

A mature monitoring solution balances functionality, performance, and cost. By using ARMS configuration templates to manage and reuse monitoring configurations, enterprises can achieve stable, scalable observability for Java applications in cloud‑native environments.