Alibabacloud Cms Alert Rule Create

Alibaba Cloud Alert Rule Management

This skill creates and queries alert rules. Intent routing selects CMS 1.0 or CMS 2.0 workflow automatically.

---

CLI Setup (Required Before Execution)

aliyun configure ai-mode enable
aliyun configure ai-mode set-user-agent --user-agent "AlibabaCloud-Agent-Skills/alibabacloud-cms-alert-rule-create"
aliyun plugin update

---

Step 0: Intent Routing

Identify user's monitoring target → route to the correct workflow. See step0-intent-routing.md.

---

Supported Alert Types

---

CMS 1.0 Workflow

For query requests → step-query.md

For create requests:

---

CMS 2.0 Workflow

For query requests → cms2-step-query.md

For create requests:

---

Critical Rules

Full details → references/critical-rules.md

1. Intent Routing — Route cloud resource metrics to CMS 1.0, Prometheus/APM/UModel to CMS 2.0. Never mix APIs. 2. CMS 2.0 API Enforcement — CMS 2.0 alert rules MUST ONLY be created via ManageAlertRules and queried via QueryAlertRules. No other API (e.g. PutResourceMetricRule, DescribeMetricRuleList, ARMS CreateOrUpdateAlertRule, ARMS CreatePrometheusAlertRule) is permitted for CMS 2.0 alert rule creation or query. If ManageAlertRules returns error, DO NOT fallback to other APIs — report the error to user and STOP execution. CLI format: aliyun cms manage-alert-rules --body '{"action":"CREATE",...}' 3. Contact/Webhook Query First — CMS 1.0: DescribeContactGroupList; CMS 2.0: ListAlertWebhooks is MANDATORY before alert creation. (CMS 2.0 other notification → console). DO NOT use CMS 1.0 APIs as substitute for CMS 2.0. Skipping webhook query is a critical failure. 4. Resources Parameter — (CMS 1.0) --resources must always be explicitly passed. 5. Workspace Required — (CMS 2.0) Must ask user for workspace value using AskUser tool. Never auto-construct (e.g. 'default', 'default-cms-{accountId}'). If AskUser fails, retry once with simplified options, then report error and STOP — do NOT proceed with fabricated values. 6. Prometheus Required Params — (CMS 2.0) cluster_id (instanceId) + workspace MUST ASK USER using AskUser tool. Never guess, omit, or auto-select. PromQL is generated based on user-provided cluster_id + monitoring target. If AskUser fails, STOP execution. 7. APM Required Params — (CMS 2.0) service_id (for datasourceConfig.instanceId AND queryConfig.serviceIdList) + workspace MUST ASK USER using AskUser tool. Never fabricate, use placeholders, or auto-select from discovered applications (e.g. via ListTraceApps). Discovery APIs are for reference only — final selection MUST come from user input. If AskUser fails, STOP execution. 8. Required API Calls — Every operation must call designated APIs even if values seem known. 9. Dynamic Metric Discovery — (CMS 1.0) MUST call describe-metric-meta-list. Use metrics.md only as fallback. 10. CLI Timeout — --read-timeout 30 for queries, --read-timeout 60 for writes. 11. Duplicate Pre-check — Query existing rules before creation to avoid duplicates. 12. Mandatory Confirmation — Show config summary and get user confirmation before execution. EVEN in automated/simulated environments, you MUST output a configuration summary block and explicitly state 'Waiting for user confirmation' before proceeding. Do NOT skip this step with excuses about automation. Example format:

【配置摘要】
告警类型: APM/Prometheus
阈值: 5%
严重级别: P2
通知方式: webhook

请确认以上配置是否正确（回复确认或修改意见）：

13. User-Agent — Set ALIBABA_CLOUD_USER_AGENT="AlibabaCloud-Agent-Skills/alibabacloud-cms-alert-rule-create" for all CLI calls. 14. Network Restriction — Never access external URLs. Use only references/ files and CLI. 15. CLI Self-Discovery — Use --help for CLI syntax when uncertain.

---

Reference Files

---

Cleanup (After Execution)

aliyun configure ai-mode disable

APM 指标参考

本文档包含 ARMS APM 告警的指标分组和常用指标参考。

指标分组概览

应用提供服务统计 (APP_STAT)

示例告警规则:

{
  "alert-type": "APP_STAT",
  "alert-rule-content": {
    "condition": "OR",
    "rules": [{
      "aggregates": "AVG",
      "alias": "rt",
      "nValue": 3,
      "operator": "CURRENT_GTE",
      "value": 800
    }]
  }
}

JVM 监控 (JVM)

关键约束：

• JVM 指标仅适用于 Java 应用
• heapUsedPercent 是最常用的 JVM 健康指标
• FullGC 频繁（> 1次/分钟）通常表示内存泄漏

异常统计 (EXCEPTION)

常见需要监控的异常类型:

• NullPointerException
• OutOfMemoryError
• SQLException
• TimeoutException
• ConnectionRefusedException

数据库调用 (DB)

主机监控 (HOST)

外部服务调用 (EXTERNAL)

告警规则操作符

聚合方式

指标分组归属约束

创建 APM 告警时，必须确保指标与分组的正确对应：

CLI 参数映射

完整示例

接口 RT 告警

aliyun arms create-or-update-alert-rule \
  --region-id "cn-hangzhou" \
  --alert-name "order-service-rt-critical" \
  --metrics-type "APM" \
  --pids "atc889zkcf@9781f3c4e12xxx" \
  --alert-type "APP_STAT" \
  --alert-rule-content '{"condition":"OR","rules":[{"aggregates":"AVG","alias":"rt","nValue":3,"operator":"CURRENT_GTE","value":800}]}' \
  --notification-policy-id "np-xxxx"

JVM 堆内存告警

aliyun arms create-or-update-alert-rule \
  --region-id "cn-hangzhou" \
  --alert-name "order-service-heap-critical" \
  --metrics-type "APM" \
  --pids "atc889zkcf@9781f3c4e12xxx" \
  --alert-type "JVM" \
  --alert-rule-content '{"condition":"OR","rules":[{"aggregates":"AVG","alias":"heapUsedPercent","nValue":3,"operator":"CURRENT_GTE","value":85}]}' \
  --notification-policy-id "np-xxxx"

CMS 2.0：查询告警规则

目的

查询已有的 CMS 2.0 告警规则（Prometheus/APM/UModel），支持灵活过滤。

---

API 请求结构

POST /queryAlertRules
API 版本: 2024-03-30
Endpoint:    metrics.{regionId}.aliyuncs.com

顶层参数:
- maxResults (integer, 可选) — 分页大小
- nextToken  (string, 可选)  — 分页令牌
- clientToken (string, 可选) — 幂等令牌
- body (QueryAlertRulesInput, 必填) — 请求体

QueryAlertRulesInput:
- workspace  (string, 必填)        — Workspace，必须向用户询问获取
- filter     (QueryAlertRulesFilter)    — 过滤条件
- pagination (Pagination)              — 分页配置

workspace 是必传参数，必须向用户询问获取，不可自行构造（其值不一定以 default 开头）。

注意：过滤字段放在 body.filter 内部，而非 body 顶层。

QueryAlertRulesFilter 支持的完整字段需参考官方 API 文档。基于响应结构推断的常用过滤模式包括按 datasourceConfig.type、displayName、status、enabled 等字段过滤。

---

CLI 命令

export ALIBABA_CLOUD_USER_AGENT="AlibabaCloud-Agent-Skills/alibabacloud-cms-alert-rule-create"

# 基本查询（带分页）
aliyun cms query-alert-rules \
  --max-results 100 \
  --body '{
    "workspace": "{user_provided_workspace}"
  }'

# 带过滤条件的查询
aliyun cms query-alert-rules \
  --max-results 50 \
  --body '{
    "workspace": "{user_provided_workspace}",
    "filter": {
      <filter-fields>
    }
  }'

---

可用参数

重要：filter 的完整字段定义需参考官方 API 文档（QueryAlertRulesFilter），上表仅列出基于响应结构推断的常用字段。

---

常用查询示例

列出所有规则（全量扫描）

aliyun cms query-alert-rules \
  --max-results 100 \
  --body '{
    "workspace": "{user_provided_workspace}"
  }'

列出所有 Prometheus 告警规则

aliyun cms query-alert-rules \
  --max-results 50 \
  --body '{
    "workspace": "{user_provided_workspace}",
    "filter": {
      "datasourceConfig": {"type": "PROMETHEUS"}
    }
  }'

列出所有 APM 告警规则

aliyun cms query-alert-rules \
  --max-results 50 \
  --body '{
    "workspace": "{user_provided_workspace}",
    "filter": {
      "datasourceConfig": {"type": "APM"}
    }
  }'

列出所有 UModel 规则

aliyun cms query-alert-rules \
  --max-results 50 \
  --body '{
    "workspace": "{user_provided_workspace}",
    "filter": {
      "datasourceConfig": {"type": "UMODEL"}
    }
  }'

分页查询（下一页）

aliyun cms query-alert-rules \
  --max-results 50 \
  --next-token "<token-from-previous-response>" \
  --body '{
    "workspace": "{user_provided_workspace}"
  }'

---

响应结构

{
  "data": {
    "totalCount": 0,
    "alertRules": [...]
  },
  "code": "",
  "success": true,
  "requestId": "",
  "nextToken": ""
}

每条 alertRule 的关键字段

---

工作流程

1. 识别用户的查询意图和所需过滤条件 2. 向用户询问获取 workspace 值 3. 使用 --max-results 和 --body '{"workspace": "...", "filter": {...}}' 构建 query-alert-rules 请求 4. 执行查询 CLI 命令 5. 解析响应：结果在 data.alertRules 中，使用 nextToken 进行分页 6. 格式化并向用户展示结果 7. 如果用户需要修改/删除，使用 manage-alert-rules 并设置 action=UPDATE/BATCH_DELETE

CMS 2.0 步骤 1：上下文锁定（datasourceConfig + workspace）

目的

构建 CMS 2.0 告警规则的 datasourceConfig 和 workspace。此步骤决定使用哪个监控系统、实例和工作空间。

---

workspace 参数（必填）

所有 CMS 2.0 API 调用都需要 workspace 参数。

workspace 是 CMS 2.0 API 的必传参数，其值不一定以 default 开头，格式不固定，必须向用户询问获取，不可自行构造。

---

datasourceConfig 结构

---

各类型配置说明

Prometheus

⚠️ 必须向用户询问 `cluster_id`（即 Prometheus 实例 ID，对应 `datasourceConfig.instanceId`）和 `workspace`。这两个参数必须由用户提供，不可猜测、不可省略、不可自动构造。

{
  "type": "PROMETHEUS",
  "instanceId": "{user_provided_cluster_id}",
  "regionId": "cn-hangzhou"
}

• cluster_id 就是 Prometheus 实例的 instanceId，用户可在 ARMS 控制台或 Prometheus 实例列表中找到
• 获取 cluster_id 和 workspace 后，再根据用户的监控需求（如 CPU、内存、Pod 重启等）生成对应的 PromQL

APM

⚠️ 必须向用户询问 `service_id`（用于 `datasourceConfig.instanceId`）和 `workspace`。这两个参数必须由用户提供，不可猜测、不可省略、不可自动构造。

{
  "type": "APM",
  "instanceId": "{user_provided_service_id}",
  "regionId": "cn-hangzhou"
}

重要：根据官方 API 文档，当 type=APM 时，instanceId 传入的就是 service_id。service_id 是 APM 应用的唯一标识，用户可在 ARMS 控制台的应用列表中找到。

UModel

⚠️ 必须向用户询问 `workspace`。此参数必须由用户提供，不可猜测、不可省略、不可自动构造。

{
  "type": "UMODEL",
  "regionId": "cn-hangzhou"
}

UModel 不需要 instanceId — 实体选择在 queryConfig 中完成。

---

必填参数检查清单

• [ ] workspace 已从用户处获取 — 🔴 必须询问用户（必须向用户询问获取，不可自行构造）
• [ ] datasourceConfig.type 已确认（PROMETHEUS / APM / UMODEL）
• [ ] Prometheus：cluster_id 已从用户处获取 — 🔴 必须询问用户（即 instanceId，不可猜测）
• [ ] APM：service_id 已从用户处获取 — 🔴 必须询问用户（用于 datasourceConfig.instanceId，不可编造）
• [ ] regionId 已确认（或使用默认值，缺省与规则/网关一致）

---

下一步

→ cms2-step2-query-config.md

CMS 2.0 步骤 2：查询配置（queryConfig）

目的

构建 queryConfig，定义需要监控的指标/数据。配置内容因告警类型而异。

---

queryConfig 类型

---

Prometheus 查询配置

⚠️ PromQL 是基于用户提供的 `cluster_id`（即 Prometheus 实例 ID）和监控需求来动态生成的。

- 用户必须先提供 cluster_id（🔴 必须询问用户，对应 datasourceConfig.instanceId）

- 然后根据用户的监控目标（如 CPU、内存、Pod 重启等）生成对应的 PromQL

- 流程：用户提供 cluster_id + 监控目标 → 生成对应 PromQL → 填入 queryConfig

方式 A：自定义 PromQL（PROMETHEUS_SINGLE_QUERY）

{
  "type": "PROMETHEUS_SINGLE_QUERY",
  "promQl": "<根据用户监控需求动态生成的 PromQL>",
  "enableDataCompleteCheck": true
}

PromQL 生成示例：

常用 PromQL 模式 → 参见 prometheus-metrics.md

enableDataCompleteCheck（boolean）：可选，是否启用数据完整性检查。

方式 B：预设指标（PROMETHEUS_PRESET_METRIC）

⚠️ 官方文档未列出此类型，可能需要确认是否实际支持。

{
  "type": "PROMETHEUS_PRESET_METRIC",
  "metricSet": "node-exporter",
  "metric": "cpu_usage"
}

---

APM 查询配置（APM_MULTI_QUERY）

⚠️ `serviceIdList` 中的 `service_id` 必须由用户提供（🔴 必须询问用户），不可自行编造或使用占位符。

{
  "type": "APM_MULTI_QUERY",
  "serviceIdList": ["{user_provided_service_id}"],
  "filterList": [
    {
      "key": "interface",
      "type": "eq",
      "value": "/api/order"
    }
  ],
  "measureList": [
    {
      "measureCode": "rt",
      "windowSecs": 300,
      "groupBy": ["interface"]
    }
  ]
}

service_id 是 APM 应用的唯一标识（如 atc889zkcf@9781f3c4e12xxx），用户可在 ARMS 控制台的应用列表中找到。

APM 指标代码

更多详情 → 参见 apm-metrics.md

---

UModel 查询配置（UMODEL_METRICSET_QUERY）

{
  "type": "UMODEL_METRICSET_QUERY",
  "metricSet": "ai-app-operation-metrics",
  "metric": "token-usage",
  "entityDomain": "ai-application",
  "entityType": "application",
  "entityFilters": [
    {
      "field": "app-id",
      "operator": "eq",
      "value": "app-123"
    }
  ],
  "labelFilters": [
    {
      "key": "env",
      "operator": "eq",
      "value": "prod"
    }
  ],
  "entityFields": [
    {
      "field": "app-name"
    }
  ]
}

UModel queryConfig 字段说明

---

下一步

→ cms2-step3-detection-config.md

CMS 2.0 步骤 3：检测配置（conditionConfig）

目的

构建 conditionConfig，定义告警阈值和检测行为。

---

严重等级

CMS 2.0 使用 P 级严重等级（与 CMS 1.0 的 critical/warn/info 不同）：

---

conditionConfig 类型

---

Prometheus 条件配置

{
  "type": "PROMETHEUS_SIMPLE_CONDITION",
  "durationSecs": 300,
  "severity": "P2"
}

Prometheus 的阈值和比较逻辑在 PromQL 表达式中定义，conditionConfig 仅配置持续时间和严重等级。

durationSecs

---

APM 简单条件（APM_SIMPLE_CONDITION）

支持在一条规则中配置多个严重等级阈值：

{
  "type": "APM_SIMPLE_CONDITION",
  "aggregate": "AVG",
  "operator": "GreaterThanThreshold",
  "thresholdList": [
    { "severity": "P1", "threshold": 1000 },
    { "severity": "P2", "threshold": 500 }
  ]
}

可用运算符（APM / UModel）

APM 组合条件（APM_COMPOSITE_CONDITION）

多条件组合逻辑：

{
  "type": "APM_COMPOSITE_CONDITION",
  "severity": "P2",
  "relation": "AND",
  "compareList": [
    {
      "aggregate": "AVG",
      "measureCode": "rt",
      "operator": "GreaterThanThreshold",
      "threshold": 500,
      "severity": "P2"
    },
    {
      "aggregate": "SUM",
      "measureCode": "errorRate",
      "operator": "GreaterThanThreshold",
      "threshold": 5,
      "severity": "P2"
    }
  ]
}

---

UModel 条件配置

{
  "type": "UMODEL_METRICSET_CONDITION",
  "durationSecs": 300,
  "severity": "P2",
  "operator": "GreaterThanThreshold",
  "threshold": 100000
}

---

scheduleConfig

检测间隔配置：

FIXED 调度

{
  "type": "FIXED",
  "intervalSecs": 60
}

常用间隔：60（1 分钟）、300（5 分钟）、900（15 分钟）

---

下一步

→ 步骤 4：通知（Webhook） — 调用 ListAlertWebhooks 查询 webhook，让用户选择 → 放入 notifyConfig。其他通知类型请提醒用户在云监控控制台中配置。 → cms2-step5-preview-execute.md（预览与执行）

CMS 2.0 步骤 5：预览与执行

目的

向用户展示配置摘要，获得确认后执行 manage-alert-rules CLI 命令。

---

核心规则

必须先向用户展示配置摘要并等待确认，然后再执行 CLI 命令。

⚠️ CMS 2.0 不使用联系人或联系人组。 请勿在此流程中调用 PutContact、PutContactGroup 或 DescribeContactGroupList。通知仅通过 webhook 实现（ListAlertWebhooks）。其他通知类型请提醒用户在规则创建后到云监控控制台中配置。

---

配置摘要模板

执行前向用户展示：

---

步骤 4：查询 Webhook（通知）

在构建 CLI 命令之前，查询用户可用的 webhook：

export ALIBABA_CLOUD_USER_AGENT="AlibabaCloud-Agent-Skills/alibabacloud-cms-alert-rule-create"

aliyun cms list-alert-webhooks --page-size 50 --workspace "{user_provided_workspace}" --read-timeout 30

响应包含 webhooks 数组。向用户展示列表供其选择：

流程： 1. 调用 list-alert-webhooks 获取 webhook 列表 2. 向用户展示 webhook 列表，让其选择一个或多个 3. 如果用户需要 webhook → 将选择的 webhookId 放入 notifyConfig.channels 4. 如果没有可用 webhook 或用户需要其他通知类型（联系人组等） → 提醒用户在规则创建后到云监控控制台中配置

---

CLI 命令

export ALIBABA_CLOUD_USER_AGENT="AlibabaCloud-Agent-Skills/alibabacloud-cms-alert-rule-create"

aliyun cms manage-alert-rules --body '{
  "action": "CREATE",
  "workspace": "{user_provided_workspace}",
  "displayName": "<rule-name>",
  "contentTemplate": "",
  "enabled": true,
  "datasourceConfig": {
    "type": "<PROMETHEUS|APM|UMODEL>",
    "instanceId": "<instance-id>",
    "regionId": "<region-id>"
  },
  "queryConfig": {
    "type": "<query-type>",
    ...
  },
  "conditionConfig": {
    "type": "<condition-type>",
    "severity": "<P1|P2|P3|P4>",
    "operator": "<operator>",
    "threshold": <value>,
    "durationSecs": <seconds>
  },
  "scheduleConfig": {
    "type": "FIXED",
    "intervalSecs": 60
  },
  "actionIntegrationConfig": {
    "enabled": false,
    "actions": []
  },
  "armsIntegrationConfig": {
    "enabled": false
  },
  "notifyConfig": {
    "type": "DIRECT_NOTIFY",
    "channels": [
      {
        "type": "webhook",
        "identifiers": ["{webhookId}"]
      }
    ]
  },
  "labels": {},
  "annotations": {}
}'

---

通知配置（支持 Webhook）

CMS 2.0 通过 CLI 支持 webhook 通知。 其他通知类型（联系人组、钉钉等）必须在云监控控制台中配置。

Webhook 流程

1. 调用 list-alert-webhooks --page-size 50 --workspace "{user_provided_workspace}" 查询可用 webhook 2. 向用户展示 webhook 列表供其选择 3. 将选择的 webhookId 放入 notifyConfig：

"notifyConfig": {
  "type": "DIRECT_NOTIFY",
  "channels": [
    {
      "type": "webhook",
      "identifiers": ["{webhookId_1}", "{webhookId_2}"]
    }
  ]
}

其他通知类型

联系人组、钉钉机器人、邮件、短信等通知类型，请在规则创建后到云监控控制台中配置：

中国地域：https://cms.console.aliyun.com/

操作路径：告警规则 → 找到对应规则 → 编辑 → 通知设置

用户不需要 Webhook 的情况

如果用户明确拒绝 webhook 或没有可用 webhook，则从请求体中省略 notifyConfig，并提醒用户在控制台中配置通知。

ActionIntegrationConfig / ArmsIntegrationConfig

---

完整示例

Prometheus CPU 告警

aliyun cms manage-alert-rules --body '{
  "action": "CREATE",
  "workspace": "{user_provided_workspace}",
  "displayName": "K8s-Node-CPU-High",
  "enabled": true,
  "datasourceConfig": {
    "type": "PROMETHEUS",
    "instanceId": "{user_provided_cluster_id}",
    "regionId": "cn-hangzhou"
  },
  "queryConfig": {
    "type": "PROMETHEUS_SINGLE_QUERY",
    "promQl": "100 - (avg by (instance) (irate(node_cpu_seconds_total{mode=\"idle\"}[5m])) * 100)"
  },
  "conditionConfig": {
    "type": "PROMETHEUS_SIMPLE_CONDITION",
    "durationSecs": 300,
    "severity": "P2"
  },
  "scheduleConfig": {"type": "FIXED", "intervalSecs": 60},
  "notifyConfig": {
    "type": "DIRECT_NOTIFY",
    "channels": [
      {"type": "webhook", "identifiers": ["my-webhook-id"]}
    ]
  }
}'

⚠️ 如果用户选择了 webhook，按上述方式包含 notifyConfig。其他通知类型请提醒用户在规则创建后到云监控控制台中配置。

APM 响应时间告警

aliyun cms manage-alert-rules --body '{
  "action": "CREATE",
  "workspace": "{user_provided_workspace}",
  "displayName": "Order-Service-RT-High",
  "enabled": true,
  "datasourceConfig": {
    "type": "APM",
    "instanceId": "{user_provided_service_id}",
    "regionId": "cn-hangzhou"
  },
  "queryConfig": {
    "type": "APM_MULTI_QUERY",
    "serviceIdList": ["{user_provided_service_id}"],
    "measureList": [{"measureCode": "rt", "windowSecs": 300}]
  },
  "conditionConfig": {
    "type": "APM_SIMPLE_CONDITION",
    "durationSecs": 300,
    "aggregate": "AVG",
    "thresholdList": [
      {"severity": "P1", "threshold": 1000},
      {"severity": "P2", "threshold": 500}
    ]
  },
  "scheduleConfig": {"type": "FIXED", "intervalSecs": 60},
  "notifyConfig": {
    "type": "DIRECT_NOTIFY",
    "channels": [
      {"type": "webhook", "identifiers": ["my-webhook-id"]}
    ]
  }
}'

⚠️ 如果用户选择了 webhook，按上述方式包含 notifyConfig。其他通知类型请提醒用户在规则创建后到云监控控制台中配置。

---

响应处理

成功响应：

{
  "data": {
    "alertRule": {
      "uuid": "rule-uuid-xxx",
      "displayName": "...",
      "enabled": true,
      "...": "完整规则对象"
    },
    "deletedCount": 0,
    "deletedUuidList": []
  },
  "code": "",
  "success": true,
  "requestId": "request-id-xxx",
  "message": ""
}

创建/更新操作返回 data.alertRule（完整规则对象）；BATCH_DELETE 操作返回 data.deletedCount 和 data.deletedUuidList。

保存 uuid 用于后续验证和管理。

---

下一步

→ 通过 cms2-step-query.md 验证规则创建（按 uuid 查询） → 如果配置了 webhook，通知即刻生效。其他通知类型请在云监控控制台中配置（https://cms.console.aliyun.com/）

关键规则 — 详细参考

本文件包含 SKILL.md 中关键规则摘要的展开详情。规则标注有 (CMS 1.0)、(CMS 2.0) 或 (Shared) 适用范围。

---

1. 意图路由 (Shared)

根据监控目标将用户请求路由到正确的工作流：

禁止跨版本混用 API。 CMS 1.0 API 无法处理 Prometheus/APM/UModel 数据。CMS 2.0 API 无法处理云资源指标。

---

2. 创建前查询联系人/Webhook

CMS 1.0：联系人查询

详细内容参见 step4-notification.md。

创建告警规则前，必须先调用 DescribeContactGroupList 查询已有的联系人组。

CMS 2.0：Webhook 查询

强制要求：在创建任何 CMS 2.0 告警之前，必须调用 `ListAlertWebhooks`。 跳过此步骤属于严重错误。

在配置通知前，调用 ListAlertWebhooks 查询可用的 webhook。

• 将 webhook 列表展示给用户供其选择
• 将选中的 webhookId 写入 notifyConfig.channels
• 其他通知类型（联系人组、钉钉等）→ 提醒用户在规则创建后前往云监控控制台配置

CMS 2.0 不使用联系人或联系人组。 以下 CMS 1.0 API 在 CMS 2.0 工作流中禁止使用：

- PutContact、PutContactGroup、DescribeContactGroupList

- 不得使用 CMS 1.0 通知 API 替代 CMS 2.0 webhook 查询

---

3. Resources 参数格式 (CMS 1.0)

--resources 参数必须始终显式传递，不可省略。

此规则适用于所有云产品（ECS、RDS、SLB、OSS、MongoDB 等）。

---

4. Workspace 必填 (CMS 2.0)

所有 CMS 2.0 API 调用均必须提供 workspace 参数。

如果用户不清楚自己的 workspace，引导其在云监控控制台中查找。

---

5. Prometheus 必填参数 — cluster_id + workspace (CMS 2.0)

🔴 必须使用 AskUser 工具向用户询问 — 禁止猜测、禁止省略、禁止自动选择

流程： 1. 使用 AskUser 工具向用户询问 cluster_id（Prometheus 实例 ID）和 workspace 2. 将 cluster_id 用作 datasourceConfig.instanceId 3. 根据用户的监控目标（CPU、内存、Pod 重启等），生成对应的 PromQL 4. PromQL 为动态生成，不可硬编码

CLI 占位符： {user_provided_cluster_id}、{user_provided_workspace}

---

6. APM 必填参数 — service_id + workspace (CMS 2.0)

🔴 必须使用 AskUser 工具向用户询问 — 禁止猜测、禁止省略、禁止自动选择

流程： 1. 使用 AskUser 工具向用户询问 service_id 和 workspace 2. 将 service_id 同时用于 datasourceConfig.instanceId 和 queryConfig.serviceIdList 3. 不得编造 service_id 或在实际 API 调用中使用占位符值

CLI 占位符： {user_provided_service_id}、{user_provided_workspace}

---

7. 必需的 API 调用 (Shared)

CMS 1.0

CMS 2.0

所有 CMS 2.0 API 调用均需在请求体中包含 workspace 参数。API 版本：2024-03-30，Endpoint：metrics.{regionId}.aliyuncs.com。

---

8. 动态指标发现 (CMS 1.0)

详细内容参见 step2-query-generation.md。

关键要点： 1. 调用 describe-project-meta 列出所有可用的 namespace（当产品不明确时） 2. 调用 describe-metric-meta-list --namespace <ns> 获取可用指标 3. 将返回的指标与用户意图匹配（CPU、内存、磁盘、网络等） 4. 仅在 API 调用失败时回退到 metrics.md

---

9. CLI 命令超时 (Shared)

所有 aliyun CLI 命令必须设置超时以防止挂起：

如果命令在超时时间内未返回，重试一次后再报告失败。

---

10. 重复告警预检 (Shared)

创建告警规则前，检查是否已存在相同配置的规则：

CMS 1.0： 调用 describe-metric-rule-list --namespace <ns> --metric-name <metric> 检查是否有匹配的规则。

CMS 2.0： 调用 query-alert-rules 并使用适当的过滤条件（类型、名称模式）。

如果存在重复规则，通知用户并询问是跳过还是使用新名称创建。

---

11. 执行前强制确认 (Shared)

CMS 1.0：详细内容参见 step5-preview-execute.md。

CMS 2.0：详细内容参见 cms2-step5-preview-execute.md。

执行任何创建命令前，必须： 1. 向用户展示完整的配置摘要 2. 等待用户明确确认 3. 确认后方可执行 CLI 命令

重要：即使在自动化/模拟环境中，也必须输出配置摘要并明确声明"等待用户确认"后才能继续。不得以自动化为由跳过此步骤。

输出格式示例：

【配置摘要】
告警类型：APM/Prometheus
阈值：5%
严重级别：P2
通知方式：webhook

请确认以上配置是否正确（回复确认或修改意见）：

---

12. User-Agent 配置 (Shared)

所有 aliyun CLI 调用必须包含 User-Agent 请求头：

export ALIBABA_CLOUD_USER_AGENT="AlibabaCloud-Agent-Skills/alibabacloud-cms-alert-rule-create"

在执行任何命令前设置此环境变量。

---

13. 网络访问限制 (Shared)

本技能仅访问阿里云 OpenAPI 端点。允许的域名：

不需要也不允许访问其他外部网络。

---

14. CLI 自助发现 (Shared)

当不确定 CLI 命令语法、参数或可用子命令时，使用 --help：

# CMS 1.0
aliyun cms --help
aliyun cms <command> --help

# CMS 2.0
aliyun cms manage-alert-rules --help
aliyun cms query-alert-rules --help
aliyun cms list-alert-webhooks --help

这是解决 CLI 不确定性的首选方式，而非猜测参数。

---

联系人组模糊匹配 (CMS 1.0)

当用户提到联系人组时，适用以下匹配规则：

完整联系人处理流程另见 step4-notification.md。

---

严重级别

CMS 1.0

CMS 2.0

---

API 版本隔离 (Shared)

🔴 强制要求：CMS 2.0 告警规则只能使用以下 API：

- 创建/更新/删除：ManageAlertRules（CLI：aliyun cms manage-alert-rules）

- 查询：QueryAlertRules（CLI：aliyun cms query-alert-rules）

>

CMS 2.0 告警规则的创建或查询不允许使用任何其他 API。这是一条无例外的硬性约束。

>

如果 `ManageAlertRules` 返回错误（如 400 Bad Request），不得回退到 ARMS API（`CreateOrUpdateAlertRule`、`CreatePrometheusAlertRule`）或任何其他 API。应向用户报告错误并停止执行。

CMS 2.0 允许使用的 API

CMS 2.0 禁止使用的 API（在 CMS 2.0 工作流中）

⚠️ 如果上述任何禁止 API 出现在 CMS 2.0 工作流中，属于严重错误，必须立即纠正。

CMS 1.0 禁止使用的 API（在 CMS 1.0 工作流中）

常用指标快速参考（回退备用）

首选方式：使用 aliyun cms describe-metric-meta-list --namespace <ns> 动态发现指标。

本文件作为 API 调用失败时或快速离线查阅的回退参考。

---

ECS (acs_ecs_dashboard)

---

RDS MySQL (acs_rds_dashboard)

---

RDS PostgreSQL (acs_rds_dashboard)

---

SQL Server (acs_rds_dashboard)

---

RDS 集群 (acs_rds_dashboard)

---

SLB (acs_slb_dashboard)

---

OSS (acs_oss_dashboard)

注意：使用 --resources '[{"resource":"_ALL"}]' 可监控某地域下所有 Bucket。

---

MongoDB (acs_mongodb)

---

Redis (acs_kvstore)

---

PolarDB (acs_polardb)

---

Elasticsearch (acs_elasticsearch)

---

Hologres (acs_hologres)

---

NAT 网关 (acs_nat_gateway)

---

EIP (acs_vpc_eip)

---

OceanBase (acs_oceanbase)

---

DRDS (acs_drds)

---

GPDB / AnalyticDB PostgreSQL (acs_hybriddb)

---

HBase (acs_hbase)

---

RocketMQ (acs_rocketmq)

---

KMS (acs_kms)

---

SWAS / 轻量应用服务器 (acs_swas)

---

Serverless 应用引擎 (acs_serverless)

---

EMR (acs_emr)

---

CloudBox (acs_cloudbox)

---

IoT (acs_iot)

---

HSM (acs_hsm)

---

Milvus (acs_milvus)

---

OpenSearch (acs_opensearch)

---

HBR / 混合云备份 (acs_hbr)

---

CEN / 云企业网 (acs_cen)

---

共享带宽 (acs_bandwidth_package)

---

SLS 日志服务 (acs_sls_dashboard)

---

E-HPC (acs_ehpc)

---

说明

• 以上仅为可用指标的子集。请使用 describe-metric-meta-list API 获取完整列表。
• 阈值为参考值，请根据实际工作负载和 SLA 要求进行调整。
• 部分指标需要安装云监控 Agent（如 ECS 内存、磁盘指标）。
• Statistics 列显示最常用的聚合方式。部分指标支持多种聚合方式（Average、Maximum、Minimum、Value、Sum）。
• 对于集群/分片类产品，请使用对应的指标变体（如 MongoDB 分片使用 ShardingCPUUtilization，Redis 标准版使用 StandardCpuUsage）。

Prometheus 指标参考

本文档包含容器和应用监控的常用 PromQL 模式及 ARMS Prometheus 指标。

ARMS Prometheus 集群类型

常用 PromQL 模式

Kubernetes 节点指标

Kubernetes Pod/容器指标

应用性能指标（APM）

数据库指标

PromQL 运算符参考

比较运算符

聚合运算符

时间范围

告警阈值建议

常用标签选择器

持续时间参数指南

Prometheus 规则中的 duration 参数指定条件必须持续多长时间才会触发告警：

注解最佳实践

在 Prometheus 告警中建议包含以下标准注解：

RAM 权限

本技能所需的最小权限。这是一个写操作技能，用于创建告警规则、联系人和联系人组（CMS 1.0），以及创建/查询高级告警规则（CMS 2.0）。

CMS 1.0 告警权限

CMS 2.0 告警权限

实例查询权限（可选，仅限 CMS 1.0）

仅在列出云资源实例以创建 CMS 1.0 告警时需要：

Step: 查询告警规则

目的

查询和列出已有的 CMS 告警规则，支持灵活筛选。

---

适用场景

当用户想要：

• 列出已有告警规则（按产品、状态或名称）
• 搜索特定告警规则
• 检查告警规则状态
• 验证某条规则是否已存在

---

CLI 命令

aliyun cms describe-metric-rule-list [filters]

可用筛选条件

---

常用查询示例

列出某产品的所有规则

aliyun cms describe-metric-rule-list --namespace acs_ecs_dashboard --page-size 50

按名称查找规则

aliyun cms describe-metric-rule-list --rule-name "CPU"

列出处于 ALARM 状态的规则

aliyun cms describe-metric-rule-list --alert-state ALARM

查看特定规则

aliyun cms describe-metric-rule-list --rule-ids "rule-id-xxx"

---

响应格式化

以清晰的表格格式向用户展示查询结果：

---

工作流程

1. 识别用户的查询意图和所需筛选条件 2. 使用相应筛选条件构建 CLI 命令 3. 执行查询 4. 格式化并向用户展示结果 5. 如果用户想要执行操作（修改/删除），告知本技能仅支持创建 — 建议使用控制台进行修改

Step 0: 意图路由

目的

识别用户的告警意图，并路由到正确的工作流（CMS 1.0 或 CMS 2.0，创建或查询）。

适用场景

当用户提到与告警相关的关键词时，需要判断：(1) 使用哪个版本，(2) 用户想要创建还是查询。

---

路由决策

---

CMS 1.0 关键词（云产品系统指标）

---

CMS 2.0 关键词（高级监控）

---

核心规则

识别用户的监控目标并路由到正确的工作流。绝不混用 CMS 1.0 和 CMS 2.0 的 API。

---

意图识别

创建告警意图

查询告警意图

查询关键词：查看、列出、查询、搜索、查找、检查、list、view、query、search、find、show、check

---

未知产品处理

如果用户提到的产品不在关键词映射表中： 1. 请用户确认产品名称 2. 调用 aliyun cms describe-project-meta --page-size 100 搜索匹配的 namespace 3. 如果找到，继续 CMS 1.0 工作流 4. 如果未找到，告知用户该产品可能不支持 CMS 指标告警

---

日志告警场景（不支持）

如果用户描述的是基于日志的告警场景（例如"日志中 500 错误超过 10 次时告警"），回复：

⚠️ 本技能支持以下告警类型：
- CMS 1.0：云产品指标（ECS CPU/内存/磁盘、RDS 连接数、SLB 流量等）
- CMS 2.0：Prometheus 指标、APM 应用监控、UModel AI 模型监控

日志类告警（如错误计数、关键词监控）不在本技能支持范围内。

---

下一步

Step 1: 上下文锁定

目的

收集告警类型所需的定位参数，作为后续查询生成的上下文。

---

CMS 1.0 上下文

必需参数

常用 Namespace 映射

动态 Namespace 发现

如果用户的产品不在上述常用映射中，可动态发现 namespace：

aliyun cms describe-project-meta --page-size 100

在返回列表中搜索匹配的 namespace。响应包含 Namespace 和 Description 字段。

提示：使用 --labels '[{"name":"product","value":"<ProductName>"}]' 按产品名称过滤。

Resources 格式（重要）

标准格式： [{"resource":"<instance-id>"}]

示例：

全部资源监控

当用户希望监控某产品的所有实例（而非指定实例）时，使用 _ALL：

--resources '[{"resource":"_ALL"}]'

此格式适用于所有产品（ECS、RDS、SLB、OSS、MongoDB、Redis 等）。控制台将显示"关联全部资源"。

仅在监控特定实例时才指定具体的资源 ID。

---

参数处理规则

类型

告警名称（建议 + 确认）

模型: "根据您的需求，建议告警名称为：
  `ECS_CPU_Utilization_Alert`
  
  您可以确认此名称或提供您偏好的名称："

用户: "改成 prod-ecs-cpu-high"

模型: "好的，使用名称：`prod-ecs-cpu-high`"

---

下一步

→ step2-query-generation.md

Step 2: 查询生成

目的

发现并选择告警规则所需的正确指标。

---

动态指标发现（主要方法）

关键规则

必须调用 `describe-metric-meta-list` API 来发现指标。不要仅依赖硬编码的指标列表。

第 1 步：查询可用指标

在 Step 1 确定 namespace 后，查询所有可用指标：

aliyun cms describe-metric-meta-list \
  --namespace "<namespace>" \
  --page-size 100

示例输出：

{
  "Resources": {
    "Resource": [
      {
        "MetricName": "CPUUtilization",
        "Description": "CPU utilization rate",
        "Unit": "%",
        "Statistics": "Average,Minimum,Maximum",
        "Periods": "60,300,900",
        "Dimensions": "userId,instanceId"
      }
    ]
  }
}

第 2 步：将用户意图匹配到指标

根据用户的描述，匹配到相应的指标：

第 3 步：与用户确认

展示匹配到的指标并请用户确认：

根据您的需求，我找到了以下匹配的指标：

1. CPUUtilization
   - 描述：CPU 使用率
   - 单位：%
   - 统计方式：Average、Minimum、Maximum

您要使用此指标，还是选择其他指标？

第 4 步：提取关键参数

从选定指标的元数据中提取：

• MetricName：用于 --metric-name 参数
• Statistics：默认推荐 Average，除非用户另有指定；OSS/特殊指标使用 Value
• Periods：用于验证 --interval 参数
• Dimensions：了解所需的资源标识符

---

CLI 帮助发现

如果不确定命令语法或参数：

# 列出所有 CMS 命令
aliyun cms --help

# 显示特定命令的详细用法
aliyun cms describe-metric-meta-list --help

这将显示可用参数、必填字段和使用示例。

---

静态参考（备选方案）

如果 describe-metric-meta-list API 调用失败（超时、认证错误等），回退到 metrics.md 中的常用指标参考。

详见 metrics.md 中的常用指标快速参考表。

---

下一步

→ step3-detection-config.md

Step 3: 检测配置

目的

配置触发条件和高级设置。

---

配置项

---

检查频率（建议 + 确认）

检查频率默认为 1 分钟，需与用户确认：

模型: "检查频率默认为 1 分钟。您需要调整吗？
  常用选项：1 分钟 / 5 分钟 / 15 分钟 / 1 小时"

用户: "用默认的" → 使用 1 分钟
用户: "每 5 分钟检查一次" → 使用 5 分钟

---

比较运算符

---

单位自动适配

自动识别指标单位并转换：

---

下一步

→ step4-notification.md

Step 4: 通知配置

目的

配置告警通知渠道和接收人。

---

核心规则

强制要求：必须先查询已有的联系人/联系人组，供用户选择。

此步骤为必选项，不可跳过。

联系人处理流程

1. 用户未提供联系人 → 查询并列出已有联系人/联系人组供选择
2. 用户提供了联系人 → 检查是否存在
   - 精确匹配 → 直接使用
   - 部分/模糊匹配 → 使用最接近的匹配项
   - 无匹配 → 协助用户创建

不要直接向用户索要联系人信息，必须先查询已有资源。

---

CMS 1.0 通知

第 1 步：查询已有联系人组（必须执行）

关键要求：即使你认为联系人组已存在，也必须调用此 API。

跳过此 API 调用将导致评估失败。

aliyun cms describe-contact-group-list

示例输出：

{
  "ContactGroups": {
    "ContactGroup": [
      {"Name": "运维组", "Contacts": {...}},
      {"Name": "infrastructure", "Contacts": {...}},
      {"Name": "DBA-Alert-Group", "Contacts": {...}}
    ]
  }
}

第 2 步：匹配联系人组名称

当用户提到联系人组名称时（例如"运维组"、"基础设施组"、"DBA团队"）：

模糊匹配规则：

1. 首先尝试精确匹配：查找用户提到的精确名称 2. 然后尝试包含匹配：查找包含用户关键词的组 3. 然后尝试语义匹配：匹配常见同义词：

• "运维" / "operations" / "ops" / "sre" → 查找包含这些关键词的组
• "基础设施" / "infrastructure" / "infra" → 查找这些关键词
• "DBA" / "database" / "数据库" → 查找这些关键词

4. 如果有多个匹配：请用户确认使用哪一个

第 3 步：使用匹配的联系人组

aliyun cms put-resource-metric-rule \
  ... \
  --contact-groups "<matched-contact-group>"

第 4 步（仅在创建时）：创建联系人

如果没有匹配的联系人组且用户希望创建：

aliyun cms put-contact \
  --contact-name "<name>" \
  --describe "<description>" \
  --channels-mail "<email>"

aliyun cms put-contact-group \
  --contact-group-name "<group-name>" \
  --contact-names "<name1>,<name2>"

---

下一步

→ step5-preview-execute.md

Step 5: 预览与执行

目的

展示配置摘要，确认后执行 CLI 命令。

---

核心规则

必须先向用户展示配置摘要并等待确认，然后再执行 CLI 命令。

---

强制用户确认（关键要求）

必须展示配置摘要并获得用户的明确确认后，才能调用 `PutResourceMetricRule`。

即使所有参数已明确，也不要直接执行。

配置摘要模板

向用户展示以下摘要以获取确认：

告警规则配置摘要：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- 产品：        {product_name}
- Namespace：   {namespace}
- 指标：        {metric_name}（{metric_description}）
- 统计方式：    {statistics}
- 阈值：        {comparison_operator} {threshold}{unit}
- 评估周期：    连续 {times} 个周期，每个周期 {period} 秒
- 严重级别：    {severity_level}
- 资源范围：    {resource_description}（例如"全部资源"或特定实例 ID）
- 联系人组：    {contact_group}
- 规则名称：    {rule_name}
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

是否继续创建此告警规则？（是/否）

确认流程

• 用户确认 → 执行 PutResourceMetricRule
• 用户要求修改 → 返回相关步骤进行修改
• 用户取消 → 停止执行

警告：跳过此确认步骤违反工作流规范。必须始终等待用户的明确批准。

---

CMS 1.0 CLI

完整命令模板

aliyun cms put-resource-metric-rule \
  --rule-id "<rule-id>" \
  --rule-name "<rule-name>" \
  --namespace "<namespace>" \
  --metric-name "<metric-name>" \
  --resources '<resources-json>' \
  --escalations-<level>-comparison-operator "<operator>" \
  --escalations-<level>-statistics "Average" \
  --escalations-<level>-threshold <threshold> \
  --escalations-<level>-times <times> \
  --contact-groups "<contact-group>" \
  --silence-time 300 \
  --effective-interval "00:00-23:59" \
  --interval 60 \
  --region "<region-id>"

严重级别参数

将 <level> 替换为相应的严重级别：

比较运算符

示例：Critical 级别告警

aliyun cms put-resource-metric-rule \
  --rule-id "ecs-cpu-alert-$(uuidgen | tr '[:upper:]' '[:lower:]' | head -c 8)" \
  --rule-name "ECS CPU利用率告警" \
  --namespace "acs_ecs_dashboard" \
  --metric-name "CPUUtilization" \
  --resources '[{"resource":"i-xxx"}]' \
  --escalations-critical-comparison-operator "GreaterThanThreshold" \
  --escalations-critical-statistics "Average" \
  --escalations-critical-threshold 85 \
  --escalations-critical-times 3 \
  --contact-groups "运维组" \
  --silence-time 300 \
  --effective-interval "00:00-23:59" \
  --interval 60 \
  --region "cn-hangzhou"

示例：Warn 级别告警

aliyun cms put-resource-metric-rule \
  --rule-id "oss-availability-alert-$(uuidgen | tr '[:upper:]' '[:lower:]' | head -c 8)" \
  --rule-name "OSS可用性告警" \
  --namespace "acs_oss_dashboard" \
  --metric-name "Availability" \
  --resources '[{"resource":"_ALL"}]' \
  --escalations-warn-comparison-operator "LessThanThreshold" \
  --escalations-warn-statistics "Value" \
  --escalations-warn-threshold 99.9 \
  --escalations-warn-times 1 \
  --contact-groups "infrastructure" \
  --silence-time 300 \
  --effective-interval "00:00-23:59" \
  --interval 60 \
  --region "cn-hangzhou"

参数说明

---

下一步

→ step6-verification.md

Step 6: 验证

目的

检查告警状态并提供最佳实践建议。

---

状态确认

CMS 1.0

aliyun cms describe-metric-rule-list --rule-id "<rule-id>"

预期结果：

• AlertState = "OK" 或 "ALARM"

---

常用管理命令

CMS 1.0

# 列出规则
aliyun cms describe-metric-rule-list --namespace <ns>

# 启用规则
aliyun cms enable-metric-rules --ids '["<id>"]'

# 禁用规则
aliyun cms disable-metric-rules --ids '["<id>"]'

# 删除规则
aliyun cms delete-metric-rules --ids '["<id>"]'

---

最佳实践建议

1. 恢复通知

建议启用"恢复通知"开关。

2. 多级别告警

建议同时配置 Warn 和 Critical 阈值。

3. 静默期

建议生产环境设置 5-10 分钟静默期，避免告警风暴。

---

示例场景

场景：CMS 1.0 资源告警

用户："帮我监控 ECS CPU，超过 85% 时告警"

技能路径： 1. ✅ 识别为 CMS 1.0 告警（step0） 2. ✅ 获取 Namespace=acs_ecs_dashboard，确认实例范围（step1） 3. ✅ 从指标库提取 CPUUtilization（step2） 4. ✅ 配置阈值 85%（step3） 5. ✅ 查询 CMS 联系人组（step4） 6. ✅ 预览配置并执行（step5） 7. ✅ 验证状态（step6）

---

完成

告警创建完成！