使用AI CLI配置、查询和治理CCE AOM告警
应用场景
CCE集群上线后，运维团队通常需要尽快完成告警规则初始化，并在日常排障中持续关注当前活跃告警、历史告警、恢复记录和通知规则。通过AI CLI Agent对接alarm-correlation-engine Skill，您可以用自然语言完成CCE AOM告警规则配置、告警查询、告警聚合分析和严重告警根因追查。
相比只查看单条告警列表，本实践推荐客户按时间窗分析集群告警。AI CLI会自动归并同类告警，标记严重程度，区分常态告警、突发告警和持续未恢复告警，帮助客户快速判断“哪些告警最紧急、影响哪些资源、下一步应该查什么”。
通过AI CLI可以实现：
- 一键为指定CCE集群创建AOM告警中心推荐规则。
- 未指定通知规则时，自动创建集群级默认通知规则。
- 创建前预览规则数量、规则类型、通知方式和缺失参数，客户确认后再执行。
- 创建完成后自动查询告警规则列表，确认50个规则已成功创建。
- 按集群和时间窗查询当前活跃告警、历史告警和恢复记录。
- 对告警进行去重、分组、严重程度标记、突发/持续/常态识别和根因线索分析。
本实践以北京四test-ai-diagnoses集群批量配置CCE AOM告警规则，并分析最近4小时告警态势为例，演示如何通过自然语言完成告警配置、告警查询和聚合分析。
约束与限制
- 可不指定已有通知规则，未指定时AI CLI将自动调用集群级默认通知规则。
- 自动创建通知规则时，必须提供可用的SMN主题名称或主题URN。
- 指标告警依赖目标集群已绑定AOM CCE Prometheus实例。
- 事件告警依赖CCE事件上报链路，建议同步确认日志采集与节点故障检测插件状态正常。
- 创建告警规则须经客户明确确认后方可执行。
- 严重程度标记仅作排障辅助，不可替代生产变更审批与人工确认机制。
- 分析告警时建议显式指定时间窗，如最近30分钟、最近4小时或特定起止时间段。
- 严禁将AK/SK、Token、证书及真实项目ID写入文档、代码或对话输出。
前提条件
- 已在AI CLI中注册alarm-correlation-engine Skill。
- 已配置华为云访问凭证，建议通过环境变量或安全凭据文件注入，不在对话或文档中暴露AK/SK。
- 目标CCE集群已绑定AOM CCE Prometheus实例。
- 已准备可用的SMN主题，例如主题名test。如果已有AOM通知规则，也可以直接复用。
- 执行账号已具备AOM告警规则查询、创建、通知规则查询和通知规则创建权限。
- 创建告警规则已经过客户二次确认。
涉及的Skill
| Skill名称 | 功能说明 |
|---|---|
| alarm-correlation-engine | AOM告警查询、活跃告警查询、告警归并分析、告警规则创建和通知规则查询。 |
| huawei-cloud-cce-cluster-management | 查询CCE集群列表，确认集群名称、集群ID和集群状态。 |
| observability-context-builder | 在告警分析后继续汇聚指标、日志和Kubernetes事件上下文。 |
操作流程
步骤一：一键创建CCE集群告警规则
您可以按照CCE集群告警最佳实践，让AI CLI为目标集群智能配置默认AOM告警规则。您只需要说明区域、集群名称和通知主题，AI CLI会自动理解配置意图，补齐集群信息，生成创建计划，并在客户确认后完成规则创建和结果校验。
在OpenClaw对话中输入：
帮我给北京四集群test-ai-diagnoses批量创建CCE AOM告警规则，订阅主题使用test。
AI CLI会先生成告警规则配置计划，帮助确认创建范围和通知方式。
| 智能处理项 | 说明 |
|---|---|
| 识别集群 | 根据区域和集群名称查询CCE集群，确认集群ID、集群状态和可配置性。 |
| 补齐通知配置 | 优先复用已有AOM通知规则；未指定通知规则时，基于SMN主题创建集群级默认通知规则。 |
| 生成规则计划 | 按CCE集群推荐实践生成50个默认告警规则，区分指标告警和事件告警。 |
| 预览影响范围 | 展示规则数量、规则类型、通知规则和缺失参数，不会直接创建。 |
| 等待客户确认 | 只有客户明确回复确认后，AI CLI才执行创建动作。 |
| 自动创建规则 | 批量创建默认告警规则；如发现同名规则已存在，则自动跳过避免重复创建。 |
| 自动验收结果 | 创建完成后立即查询告警规则列表，确认规则数量、类型和失败数量。 |
默认创建的50个规则包括。
| 类型 | 数量 | 示例 |
|---|---|---|
| Prometheus指标告警 | 38 | Pod状态异常、Pod频繁重启、节点CPU使用率、节点磁盘可用率、节点Kubelet异常。 |
| CCE事件告警 | 12 | Pod内存不足OOM、节点磁盘空间不足、节点状态异常、扩容节点超时、集群状态不可用。 |
AI CLI展示预览后，用户确认规则数量、通知方式和目标集群无误，再明确回复：
确认创建。
执行完成后，AI CLI会返回创建结果，并自动查询确认规则已创建成功。客户重点查看以下验收项：
| 校验项 | 期望结果 |
|---|---|
| test-ai-diagnoses相关规则总数 | 50 |
| 指标告警 | 38 |
| 事件告警 | 12 |
| 创建失败 | 0 |
如果部分规则已存在，AI CLI会跳过同名规则，避免重复创建。您也可以随时输入以下内容复查：
查询北京四test-ai-diagnoses集群的告警规则。
步骤二：按时间窗聚合分析告警并追查根
当需要了解集群当前是否存在风险时，建议指定时间窗，让AI CLI同时查询活跃告警、历史告警和恢复记录，并按严重程度聚合分析。
分析北京四test-ai-diagnoses集群最近4小时的AOM告警，按严重程度聚合，标记常态告警和突发告警，并告诉我最需要先处理的三个问题。
您也可以指定精确时间段，用于分析变更窗口、故障窗口或值班交接窗口。
帮我分析北京四test-ai-diagnoses集群今天09:00到12:00之间的AOM告警，按严重程度聚合，输出突发告警首次出现时间和处置优先级。
AI CLI会先返回本时间窗的告警态势摘要，重点查看以下信息：
| 输出项 | 示例 |
|---|---|
| 告警总量 | 最近4小时共发现42条告警，当前未恢复7条 |
| 严重程度分布 | Critical: 1，High: 3，Medium: 9，Low: 29 |
| 告警类型分布 | 突发告警3组，持续未恢复告警2组，常态高频告警5组 |
| 首次出现时间 | 最早突发告警出现在09:17，集中爆发时间为09:20-09:35 |
| 主要影响对象 | kube-system、default/nginx-demo、节点192.168.0.12 |
| 优先处理建议 | 当前风险集中在节点资源压力和业务Pod重启，建议优先分析节点磁盘和Pod最近变更 |
随后，AI CLI会将多条原始告警聚合成告警组，并按严重程度排序。客户可以按以下顺序处理：
| 优先级 | 严重程度 | 告警组 | 告警特征 | 首次出现时间 | 判断 | 处理建议 |
|---|---|---|---|---|---|---|
| P0 | Critical | 集群状态不可用或核心组件异常 | 突发告警，当前未恢复 | 09:17 | 可能影响集群控制面或业务调度能力 | 立即进行根因分析，检查CCE事件、核心组件Pod和AOM指标 |
| P1 | High | 节点磁盘空间不足，关联多个Pod驱逐事件 | 持续告警，当前未恢复 | 09:24 | 节点资源压力可能造成业务副本不稳定 | 关联节点上的Pod、驱逐事件和磁盘指标 |
| P2 | Medium | Pod频繁重启，集中在 default/nginx-demo | 突发告警，部分已恢复 | 10:06 | 可能与近期发布、探针配置或资源限制有关 | 查询Pod日志、事件和Deployment版本历史 |
| P3 | Low | 短时CPU阈值告警 | 常态告警，频繁自动恢复 | 过去7天多次出现 | 暂无持续影响，可能是短时流量波动 | 观察趋势，必要时调整阈值或HPA策略 |
对于Critical、High或用户关注的告警组，可以继续让AI CLI在同一时间窗内分析相关根因：
继续分析P1节点磁盘空间不足告警，时间窗保持最近4小时，帮我关联这个节点上的Pod、最近事件、相关指标和可能根因。
AI CLI会围绕该告警组继续查询上下文，并给出根因线索：
| 根因分析项 | 客户可获得的信息 |
|---|---|
| 相关资源 | 告警节点、受影响Pod、命名空间、工作负载和Service |
| 相关事件 | 驱逐、调度失败、探针失败、镜像拉取失败、节点异常等事件 |
| 相关指标 | CPU、内存、磁盘、网络等资源趋势，以及告警触发前后的变化 |
| 时间线 | 告警首次出现时间、集中爆发时间、恢复时间和相关事件发生时间 |
| 初步根因 | 例如节点磁盘压力、工作负载发布异常、核心组件异常或容量不足 |
| 下一步建议 | 继续排障、清理资源、扩容、调整阈值、回滚发布或保持观察 |
用户也可以要求AI CLI只输出严重且未恢复的告警组：
只看最近4小时仍未恢复的High和Critical告警，按影响资源分组，并给出每组首次出现时间和根因分析建议。
如果告警与业务不可用相关，可以继续要求AI CLI输出完整根因分析和恢复建议：
基于这些严重告警继续做根因分析，时间窗保持09:00到12:00，并给出恢复建议。
如果需要查看原始明细，可以继续输入：
展开最近4小时告警明细，显示告警名称、状态、级别、资源、首次触发时间和描述。
预期结果
完成本实践后，AI CLI能够帮助您完成以下闭环：
- 按CCE集群告警最佳实践，一键为目标集群创建50个AOM告警规则。
- 自动识别集群、准备通知规则、预览创建计划，并在用户确认后执行创建。
- 创建完成后自动查询告警规则列表，确认指标告警38个、事件告警12个、创建失败0个。
- 按指定时间窗查询当前活跃告警、历史告警和恢复记录。
- 对告警进行自动聚合、去重和严重程度标记，区分常态告警、突发告警和持续未恢复告警。
- 输出突发告警首次出现时间、集中爆发时间、影响资源和按优先级排序的处置队列。
- 针对Critical和High严重告警，在同一时间窗内关联事件、日志、指标和资源状态，输出可能根因和下一步诊断路径。
常见问题
提示找不到Prometheus实例
- 处理建议
- 查询AOM Prometheus实例，确认目标集群是否绑定CCE类型实例。
- 查询CCE插件，确认云原生监控相关组件是否已安装。
- 若控制台刚开启监控，等待实例绑定信息同步后重试。
为什么查询到的通知规则数量和控制台不一致
建议通过AI CLI重新查询当前区域的AOM通知规则；若仍不一致，请核实当前凭证、所属项目及区域是否与控制台环境完全匹配。
为什么自动创建通知规则失效
请优先确认SMN主题是否存在，以及当前账号是否具备AOM通知规则和SMN主题访问权限，确认无误后重新发起创建即可。
告警数量很多但不知道先处理什么
建议通过AI CLI按时间窗重新聚合分析，并要求输出严重程度和处置优先级，例如：
把最近4小时test-ai-diagnoses集群的AOM告警按资源和严重程度聚合，输出最需要优先处理的5个告警组。
如果聚合后仍存在大量High或Critical告警，应继续缩小范围，优先分析未恢复、影响核心命名空间、关联多个资源或集中爆发的告警组。
后续建议
- 规则创建完成后，建议立即查询目标集群的告警规则，确认规则数量、通知方式及启用状态符合预期。
- 新集群上线初期建议每日核查活跃告警与高频历史告警，观察是否存在阈值过严、重复通知或长期未恢复的告警。
- 值班排障时建议固定使用时间窗进行分析。例如，“最近30分钟”“最近4小时”“变更后到现在”，避免无关历史告警干扰。
- 针对Critical和High告警组，建议继续关联日志、事件、指标及工作负载版本，形成根因分析链路。
- 对于确认无业务影响的高频告警，建议先分析触发对象与时段，再评估阈值或通知范围的优化方案。
- 生产集群建议定期导出告警规则清单，将其作为变更审计与故障复盘的重要材料。
- 告警触发后，建议先查看告警聚合和严重程度标记结果，再继续查询相关日志、事件和指标，避免只根据单条告警做恢复动作。
相关文档
- 通过AOM配置自定义告警：了解CCE告警中心中如何通过AOM配置自定义告警，以及Prometheus实例等关键配置项。
- 配置AOM告警规则：了解AOM告警规则的配置方式、规则参数和告警触发逻辑。
- 监控云容器引擎CCE的指标：了解如何使用AOM监控CCE指标，以及指标、事件和告警通知之间的关系。
- 创建主题：自动创建或绑定通知规则前，了解如何在SMN中创建主题。
- 云容器引擎CCE文档：查询CCE集群、插件、云原生观测和工作负载相关产品说明。
