华为云 AOM 应用运维管理实操：从指标采集、日志接入到告警规则与 hcloud CLI 运维

应用出问题时，最耗时间的往往不是修复本身，而是先回答三个问题：哪里出问题了、影响面有多大、是谁先发现的。华为云 AOM（应用运维管理）就是为这三个问题准备的统一入口：指标、日志、链路、事件四类数据汇到一处，在同一个地方配告警、看仪表盘、查问题。本文结合 AOM 2.0 的实际能力与 hcloud CLI（KooCLI 7.2.2）的一线用法，记录一条从采集接入到告警落地的完整链路。

一、AOM 是什么：可观测性的统一入口

AOM 是华为云的可观测平台，基于指标、链路、日志、事件全景数据监控，提供一体化监控解决方案。它本身不是单一工具，而是一组能力的统一入口，底层包含四块：

AOM 2.0 于 2024 年 3 月转商，是当前主推版本，全面基于 Prometheus 架构构建。理解这个定位很重要：之后所有的告警规则、仪表盘和 PromQL 查询，都是站在同一份数据底座上的，指标告警、日志告警和事件告警可以在同一套规则体系里表达，而不是三个系统各配一套。

二、Prometheus 指标采集：三种接入方式

AOM 的指标采集以全托管 Prometheus 为核心，接入方式按运行位置分三种。

1. CCE 容器场景。 AOM 与 CCE 无缝对接，自动注入 Prometheus 采集配置（基于 ServiceMonitor/PodMonitor），无需手动部署 exporter，采集端自动扩缩容。工作负载一上线，容器指标就开始进 AOM。

2. ECS 主机场景。 在 ECS 上安装 AOM 采集代理 ICAgent，自动采集 CPU、内存、磁盘、网络等基础指标。主机、进程、容器三个层面的指标都由同一代理上报。

3. Remote Write 接入。 自建 Prometheus 通过 remote_write 把指标推送到 AOM 的 Prometheus 实例，实现统一存储和查询。配置示例如下：

remote_write:
  - url: "https://<AOM-Prometheus实例地址>/api/v1/write"
    basic_auth:
      username: "<用户名>"
      password: "<密码或 AK/SK 派生的凭证>"

除此之外还可以通过 AddMetricData 接口上报自定义业务指标，命名空间为 CUSTOMMETRICS，例如订单量、下单成功率这类业务指标，都可以和基础设施指标放在同一个仪表盘里对照。

AOM 内置四层指标命名空间：PAAS.CONTAINER（组件、实例、进程、容器指标）、PAAS.NODE（主机、网络、磁盘、文件系统指标）、PAAS.SLA（SLA 指标）、PAAS.AGGR（集群聚合指标），再加上 CUSTOMMETRICS 自定义指标。排障时先确认指标在哪个命名空间，能少走很多弯路。

AOM 支持原生 PromQL 查询，即时查询对应 CLI 操作 ListInstantQueryAomPromGet：

hcloud AOM ListInstantQueryAomPromGet \
  --cli-region=cn-north-4 \
  --project_id=<项目ID> \
  --query='avg(rate(container_cpu_usage_seconds_total[5m]))'

这条命令查的是全部容器近 5 分钟 CPU 使用率的平均值。把 query 换成你自己的表达式，就能在终端里完成一次快速验证，不用先打开控制台。

三、日志接入：LTS 统一入口

AOM 的日志能力由 LTS（云日志服务）提供，但通过 AOM 控制台统一入口操作，接入方式有三种：ICAgent 采集——在 ECS/CCE 上安装 ICAgent，配置日志采集路径，自动收集日志文件；CCE 容器日志——容器 stdout/stderr 日志自动接入，按 Namespace/Deployment/Pod 分层查询；API 上报——通过 LTS SDK 或 API 主动上报日志。

日志真正的价值在联动：AOM 支持基于日志内容配置告警规则，当日志中出现特定关键词或匹配正则模式时触发告警。指标告警加日志告警加事件告警三合一，才是 AOM 所说的统一告警。举个例子，网关日志里 5 分钟内出现 10 次以上 “connection refused”，可以直接触发一条 Minor 告警推送给值班人，而不用等到 CPU 指标先报警。

四、告警规则配置

AOM 2.0 的告警体系支持三种规则类型：指标告警（metric），基于 PromQL 表达式的阈值告警；事件告警（event），基于 CCE、RDS、EVS、LTS、AOM 等事件源；日志告警，基于 LTS 日志关键词或正则匹配。

告警级别分四档：Critical（紧急）> Major（重要）> Minor（次要）> Info（提示）。级别不是随便填的，它决定通知渠道和响应时效：Critical 建议电话加短信，Minor 走群消息就够了。

通知机制有两种模式：直接告警（direct），触发即通知，可配置通知频率（只告一次、每 5 分钟、每小时、每天）；告警降噪（alarm_policy），通过告警行动规则进行分组、抑制、收敛，避免告警风暴。规则状态分 OK（正常，未触发）、alarm（已超限触发）、Effective（生效中）、Invalid（已停用）四种。

对接 CCE 时，AOM 提供 48 个以上内置底线告警规则和 10 个以上开箱即用仪表盘，覆盖常见运维场景。新环境接入后先启用内置规则，再按业务补自定义规则，比从零手写要稳妥。

五、hcloud CLI 常用运维操作速查

当前环境中 hcloud 版本为 7.2.2，AOM 服务下有 80 多个操作。按场景分类，常用的有：

查询 AOM 告警的示例命令如下：

# 查询 AOM 2.0 全部指标告警规则
hcloud AOM ListMetricOrEventAlarmRule \
  --cli-region=cn-north-4 \
  --project_id=<项目ID> \
  --alarm_rule_type=metric

# 查询 AOM 1.0 阈值规则列表
hcloud AOM ListAlarmRule \
  --cli-region=cn-north-4 \
  --project_id=<项目ID> \
  --limit=50

# 查询 Prometheus 实例，确认采集接入状态
hcloud AOM ListPromInstance \
  --cli-region=cn-north-4 \
  --project_id=<项目ID>

指标查询命令的参数较多，写脚本前先看帮助输出，以实际版本为准：

hcloud AOM ShowMetricsData --help
hcloud AOM ListMetricOrEventAlarmRule --help

把每天的巡检写成一个脚本，定时跑一次，结果重定向到日志文件，就是一份最简单的无人值守巡检：

#!/bin/bash
# AOM 每日巡检：列出指标告警规则与 Prometheus 实例
REGION=cn-north-4
PROJECT_ID=<项目ID>

hcloud AOM ListMetricOrEventAlarmRule \
  --cli-region=$REGION --project_id=$PROJECT_ID --alarm_rule_type=metric

hcloud AOM ListPromInstance \
  --cli-region=$REGION --project_id=$PROJECT_ID

六、告警降噪与值班实践

告警配好只是开始，真正考验人的是告警风暴。一个节点抖动可能同时触发主机、容器、业务三层告警，值班手机一分钟响十次，第二天就没有人认真看告警了。AOM 的降噪手段有三件：告警行动规则做分组、抑制和收敛；静默规则在变更窗口内压住已知告警；通知模板统一文案，让每条告警都带上服务名、指标、当前值和处理入口。

建议的落地顺序是：先接内置底线规则跑一周，统计每条规则的触发次数和误报率；再把高频误报的阈值放宽或加静默；最后才补业务自定义规则。告警规则也要像代码一样做版本管理：谁改的、为什么改、改完触发情况如何，都要有记录。

七、落地检查清单

1. 采集是否全：CCE 工作负载、ECS 主机、自建 Prometheus 是否都进了同一个 AOM 实例；
2. 仪表盘是否有人看：核心服务的黄金指标（流量、错误率、延迟、饱和度）是否都在一个仪表盘上；
3. 告警是否分级：Critical 是否真的紧急，Info 是否不该进电话渠道；
4. 通知是否闭环：被告警触达的人能不能在告警里直接找到处理入口；
5. 定期演练：每月做一次告警演练，确认规则、通知和值班表都没有过期。

结语

AOM 的核心设计思想只有一句话：数据多源接入，观测统一出口。无论指标来自 Prometheus 采集、日志来自 LTS、链路来自 APM，还是云服务指标来自 CES，都可以在 AOM 统一配置告警规则、统一在仪表盘展示、统一通过 PromQL 查询。把采集、告警、降噪、值班这四件事按上面的顺序落下来，应用出问题时，回答开头那三个问题就不再需要翻三个系统。