Monitoring and Observability on Alibaba Cloud with CloudMonitor and ARMS

Every cloud provider ships a monitoring product, and every team's first version of it is the same mistake: alarms on CPU percentage that page at 2 a.m. for a batch job that's supposed to run hot. Alibaba Cloud's stack — CloudMonitor for infrastructure metrics, Application Real-Time Monitoring Service (ARMS) for application tracing — is capable of much better than that default. Here's the setup that actually holds up.

CloudMonitor: alert on symptoms, not resources

The instinct is to alarm on CPU, memory, and disk directly. The better pattern is alarming on what those resources being exhausted actually causes — request latency, error rate, queue depth:

aliyun cms PutMetricRuleTargets --RuleId rule-xxxxxxxxxxxx \
  --Targets.1.Id target-1 \
  --Targets.1.Arn "acs:mns:ap-southeast-1:xxxx:queue/alerts"

{
  "RuleName": "api-p99-latency",
  "Namespace": "acs_ecs_dashboard",
  "MetricName": "vm.TCPConnection",
  "Escalations": {
    "Critical": {
      "Statistics": "Average",
      "ComparisonOperator": "GreaterThanThreshold",
      "Threshold": "500",
      "Times": 3
    }
  }
}

The Times: 3 field matters more than the threshold — it requires three consecutive breaches before firing, which filters out the single-datapoint blips that make on-call rotations miserable without ever indicating a real problem.

Routing alarms somewhere useful

CloudMonitor supports webhook, SMS, and Message Service (MNS) queue targets. For anything beyond a solo project, route through a queue into whatever incident tool you already use rather than direct SMS:

aliyun cms PutMetricRuleTargets \
  --RuleId rule-xxxxxxxxxxxx \
  --Targets.1.Arn "acs:mns:ap-southeast-1:xxxx:queue/pagerduty-bridge"

A small consumer on that queue translating CloudMonitor's alarm payload into PagerDuty's or Opsgenie's incident API is a couple hours of work and saves the alternative — an SMS with no context, no runbook link, and no way to acknowledge without going straight to a terminal.

ARMS for application-level visibility

CloudMonitor stops at the infrastructure layer. Once you need to answer "why is this specific endpoint slow," ARMS's distributed tracing is what actually shows the picture:

# Kubernetes deployment annotation to auto-inject the ARMS agent
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    armsPilotAutoEnable: "on"
    armsPilotCreateAppName: "checkout-service"
spec:
  template:
    metadata:
      labels:
        armsPilotAutoEnable: "on"

For Java and Node.js services, the auto-injection above covers most of the setup — ARMS attaches an agent at pod startup with no code changes required. For other runtimes, the OpenTelemetry SDK exports directly to ARMS's collector endpoint, which means teams already instrumented with OpenTelemetry for a different backend can point the same instrumentation here without rewriting it.

A dashboard that's actually useful during an incident

The dashboards worth building aren't the ones with the most panels — they're the ones answering one question fast during an incident: is this us, or is this upstream? The layout I default to:

That last row — deploy markers on the same timeline as the metrics — is the single highest-value addition to any dashboard, and the one teams skip most often. CloudMonitor supports custom annotations via API; wire your CI/CD pipeline to post one on every production deploy.

The alerting discipline that actually reduces fatigue

Every alarm needs an owner and a runbook link before it ships, not after the third time it pages someone who doesn't know what it means. If an alarm has fired five times in a month and nobody has adjusted the threshold or fixed the underlying cause, that's a signal to either fix the root issue or delete the alarm — a noisy alarm that people learn to ignore is worse than no alarm at all.