华为云 AOM：如何构建 AI 推理服务的可观测性方案

摘要

AI 推理服务上线后，单纯监控接口是否返回成功，往往无法解释响应变慢、模型加载失败、实例资源不足或异常请求增加等问题。华为云应用运维管理 AOM 可用于统一采集和分析应用运行状态，帮助团队从指标、日志、调用链和告警等维度观察 AI 服务。本文以在线推理接口为例，介绍如何设计监控指标、关联日志与调用链、配置异常告警，并说明 AOM 原生能力与业务侧自行开发逻辑之间的边界。文中内容属于应用设计示例，具体支持范围和配置方式应以目标区域的官方文档为准。

一、场景引入：接口成功不等于推理服务正常

假设一个图像识别服务通过 API 接收图片，完成预处理、模型推理和结果返回。服务上线初期，团队只设置了一个“HTTP 状态码不是 200”的告警。

运行一段时间后，业务人员反馈识别结果返回变慢，但接口大多数仍然返回成功。进一步排查发现，问题可能来自多个环节：

• 图片上传或下载耗时增加；
• 预处理程序占用过多 CPU；
• 模型推理阶段等待 GPU 或其他计算资源；
• 某些输入尺寸过大，导致单请求处理时间异常；
• 实例频繁重启，造成连接重试；
• 下游数据库或消息服务响应缓慢；
• 新模型版本导致错误率只在部分输入上升。

如果只有接口成功率，运维人员很难判断问题位于网关、应用代码、模型运行时还是下游服务。AOM 可以作为应用运行状态的统一观测入口，相关产品信息可参考华为云 AOM 产品介绍和AOM 文档中心。

二、监控设计：先定义 AI 服务真正关心的指标

1. 基础运行指标

基础指标用于判断服务是否具备稳定运行条件，通常包括：

• 实例存活状态；
• CPU、内存和磁盘使用情况；
• 网络流量；
• 容器或进程重启次数；
• 请求总量和并发量；
• 接口响应时间；
• HTTP 错误比例。

这些指标可以帮助识别“服务是否可用”，但还不足以判断模型推理质量。例如，接口返回 200 并不代表模型加载的是预期版本，也不代表结果置信度或业务规则都正常。

2. AI 推理相关指标

建议由应用程序主动上报与推理过程相关的业务指标，例如：

其中，AOM 负责指标采集、展示和告警配置；model_version、inference_latency 等业务指标如何生成，需要由推理服务自行埋点。平台不会自动理解某个接口返回结果是否符合业务预期。

三、应用设计示例：建立从请求到模型的观测链路

第一步：为请求生成关联标识

一个推理请求可能经过 API 网关、业务服务、模型服务和结果存储等多个组件。建议在请求进入系统时生成或传递唯一的请求标识，例如：

request_id = 20250301-7f31-00018

该标识应写入：

• API 访问日志；
• 推理服务日志；
• 下游调用日志；
• 异常记录；
• 最终返回结果或排查页面。

如果请求跨越多个服务，还可以使用调用链标识，将同一请求在不同组件中的处理过程关联起来。调用链的具体采集方式需要根据运行环境、开发语言和接入组件确认，不能仅凭配置 AOM 就自动获得完整链路。

第二步：拆分推理阶段的耗时

推理接口不应只记录总耗时。应用可以在关键步骤前后记录时间：

请求接收
  ├── 图片读取：120 ms
  ├── 图像预处理：35 ms
  ├── 模型推理：210 ms
  ├── 结果后处理：18 ms
  └── 响应返回

实际实现时，可以将每个阶段的耗时作为指标上报，同时在异常日志中记录请求标识、模型版本和输入类型。

需要避免将原始图片、完整文档或个人敏感信息直接写入日志。日志中可以保留文件标识、大小、摘要值或脱敏后的业务字段，以降低数据暴露风险。

第三步：记录模型与配置版本

当推理服务出现异常时，首先需要确认当前运行内容。建议服务启动时输出以下信息：

service_name=ocr-inference
service_version=2025.03.01
model_version=ocr-model-v4
config_version=prod-config-12

这些信息应与发布系统中的版本记录保持一致。若模型存储在 OBS 或其他模型管理系统中，服务还应记录模型对象的版本标识，而不是只记录一个容易变化的文件名。

AOM 可以帮助检索和关联运行日志，但版本生成、发布记录和模型登记属于应用交付流程，需要由 CodeArts、模型管理系统或自行开发的平台维护。

四、告警设计：围绕用户影响设置条件

告警不宜只按单一阈值配置。对于 AI 推理服务，可以分为三类。

1. 可用性告警

例如：

• 健康检查连续失败；
• 实例数量低于业务要求；
• 错误率持续超过预设范围；
• 模型加载失败；
• 服务无法访问依赖的模型文件。

这类告警优先级通常较高，因为它们可能直接影响请求处理。

2. 性能告警

例如：

• P95 或 P99 响应时间持续升高；
• 模型推理耗时超过业务可接受范围；
• 请求排队时间增加；
• CPU、内存或其他计算资源长期处于高位；
• 实例重启次数异常增加。

性能告警应结合时间窗口、请求量和发布版本判断。低流量时偶发一次慢请求，不一定代表系统故障；如果在新版本发布后，延迟持续升高，则需要结合变更记录分析。

3. 业务结果告警

例如：

• 空结果比例突然上升；
• 低置信度结果占比异常；
• 特定输入类型的失败率上升；
• 人工复核退回比例增加；
• 推理结果与规则校验结果不一致。

这些指标通常不是 AOM 自动生成的，需要应用程序或业务系统自行计算并上报。告警条件也应经过业务验证，避免因为样本量过小或输入分布变化造成误报。

五、日志与指标如何配合排查问题

发生一次“推理接口变慢”时，可以按照以下顺序排查：

1. 查看服务可用性
   确认实例是否存活、是否发生重启，以及错误率是否同步上升。

2. 观察延迟分布
   区分平均延迟与高分位延迟，判断是整体变慢还是少数请求异常。

3. 拆分处理阶段
   比较预处理、模型推理和后处理耗时，定位主要增长环节。

4. 关联模型和配置版本
   检查问题是否发生在新版本发布之后，确认实际运行的模型版本。

5. 通过请求标识检索日志
   找到具体异常请求，确认输入大小、依赖调用和错误堆栈。

6. 检查下游依赖
   如果推理服务本身处理正常，但响应仍然缓慢，需要继续查看对象存储、数据库、消息系统或网关的运行状态。

AOM 适合提供统一观测和分析入口，但完整排查可能还需要结合云容器、网络、存储、数据库以及发布系统的监控信息。不能将所有故障都归因于模型本身。

六、工程实施中的注意事项

1. 控制指标维度数量

将用户 ID、完整文件名或原始请求内容直接作为指标标签，可能导致指标维度快速增长，增加查询和管理复杂度。指标标签应优先选择服务名、接口名、模型版本、区域和结果类型等有限集合。

2. 区分平台采集与业务埋点

AOM 可以采集和分析应用运行数据，但以下内容通常需要业务侧实现：

• 推理阶段耗时；
• 模型版本识别；
• 置信度分布；
• 空结果比例；
• 业务规则校验结果；
• 脱敏和日志内容控制。

明确边界后，才能避免出现“已经接入监控，但无法回答业务问题”的情况。

3. 为告警设置处理动作

每条重要告警都应有对应的处理说明，例如：

• 查看哪个服务和哪个时间窗口；
• 关联哪些日志字段；
• 是否需要暂停发布；
• 是否可以扩容；
• 是否需要回滚模型或代码；
• 哪些情况需要通知业务人员。

告警数量过多而没有处理流程，容易造成告警疲劳。建议先覆盖服务不可用、推理延迟异常和结果质量异常，再逐步增加更细的指标。

结语

AI 推理服务的可观测性不能只依赖“接口是否返回成功”。稳定的监控体系需要同时观察基础资源、接口性能、模型处理阶段、模型版本和业务结果。AOM 可以为指标、日志和告警提供统一管理基础，但请求标识、模型版本、推理阶段埋点和业务质量指标仍需要由应用团队设计并实现。

在落地过程中，建议先围绕真实故障场景设计观测数据，再决定采集哪些指标和日志。这样既能减少无效监控，也能在模型、代码或基础设施发生变化时，快速判断问题范围并采取合适的恢复措施。