适用读者：在 AWS 上运行 GenAI 应用、需要把 AI 工作负载纳入现有监控体系的 IT 运维与 SRE 团队。
本文从问题出发，说明 GenAI 工作负载需要监控什么、为什么，以及如何借助 APM 工具（以 ManageEngine Applications Manager 为例）落地。文中工具能力均可在对应官方文档中核实。

引言：一个典型的监控盲区

越来越多的企业把生成式 AI（GenAI）能力集成进生产应用——AI 驱动的智能客服、企业搜索、内容生成、虚拟助手、自动化工作流。在 AWS 生态中，Amazon Bedrock 是这类能力的常见承载：它通过统一 API 暴露多家供应商的基础模型（Foundation Models），并支持微调、检索增强生成（RAG）与 Agent 编排。

但这里出现了一个典型的监控盲区：应用本身运行正常，可当它依赖的 AI 模型响应变慢、调用失败或被限流时，终端用户体验会直接受损，而传统监控却看不到原因。AI 层的任何退化最终都会传递到用户侧，因此 GenAI 工作负载的性能、用量、错误与配额消耗，必须成为应用可观测性的一部分，而不是被隔离在外。

一、GenAI 改变了监控边界

1.1 依赖链的扩展

传统 IT 团队习惯监控服务器、数据库、API、容器、云服务等应用依赖项。引入 GenAI 后，依赖链明显变长：

用户请求 → 应用服务 → API 网关 → Bedrock 调用 → 基础模型（推理、流式输出）
                                     ├── Token 用量（成本）
                                     ├── TPM 配额（限流风险）
                                     └── 日志投递（审计）

模型调用不再是"一次远程 API 请求"，而是一组需要独立观察的信号。

1.2 IT 团队需要回答的新问题

• 当前正在处理多少模型请求？请求量在增长还是下降？
• AI 响应是否在变慢？TTFT（首 Token 时间）是否异常？
• 消耗了多少 Token？成本是否可控？
• 请求失败是客户端错误、服务端错误还是限流导致？
• 工作负载是否正在逼近配额上限？
• 模型调用日志是否正常投递到 CloudWatch / S3？

这些问题对应的指标与解读方法，是本文第二、三节的内容；第四节讨论如何在监控平台中落地。

二、模型层监控：Amazon Bedrock 核心指标

AWS 通过 CloudWatch 提供 Bedrock 的服务级指标，APM 工具将其采集后纳入统一监控环境。以下是需要关注的核心指标及其业务含义：

指标类别	具体指标	业务含义	解读要点
调用量	Invocations（调用次数）	模型正在处理多少请求，工作负载用量趋势	突增可能是业务高峰，也可能是异常请求触发重试风暴
延迟	Invocation Latency（调用延迟）、Time to First Token（首 Token 时间）	模型多快开始响应、请求多久完成	对话场景下 TTFT 是核心体验指标；P50 正常不代表 P99 体验好，需关注长尾
Token 用量	Input Tokens、Output Tokens、Images Generated	模型处理与生成了多少内容	直接驱动力是成本；按模型/应用维度追踪是成本归因（Cost Attribution）与 FinOps 的基础
配额	Estimated TPM Quota Usage（预估每分钟 Token 配额使用率）	工作负载离 Token 吞吐上限有多近	接近配额即会被限流，提前预警可避免生产事故
错误与限流	Client Errors（4xx）、Server Errors（5xx）、Throttled Invocations	请求失败的原因分类	4xx 指向请求参数问题（如超长 Prompt），5xx 需要联系 AWS 支持，限流则需评估配额扩容或优化调用
日志投递	CloudWatch / S3 日志投递成功、失败次数	模型调用审计日志的完整性	失败即意味着审计链路断点，需及时恢复

几个容易被忽视的细节：

• 重试风暴：调用量突增不一定是业务增长，也可能是代码里的自动重试在反复触发，需结合错误率一起看。
• 长尾延迟：流式推理场景中 TTFT 的 P99 比平均值更接近真实用户感受。
• 配额是模型级、区域级的：AWS 对每个模型的每分钟 Token 数（TPM）设有服务限额，具体数值因模型和区域而异。EstimatedTpmQuotaUsage 指标覆盖 Converse、ConverseStream、InvokeModel、InvokeModelWithResponseStream 四个 API 操作的配额消耗。
• 4xx 与 5xx 的处理路径完全不同：分别对应"修自己的代码"和"找云厂商/评估服务健康"，必须分开告警。

三、编排层监控：Bedrock Agents 可观测性

Bedrock Agents 允许构建能编排多步骤任务的自主智能体。以银行业场景为例，客户说"我信用卡丢了，帮我挂失并告诉我如何补办"，Agent 需要：理解意图（识别"挂失"与"补办"两个任务）→ 调用 API 或 Lambda 执行挂失 → 从知识库检索最新补办流程 → 整合生成回复。

Agent 的故障可能发生在任何环节，而不只是模型推理，因此 Agent 监控与模型监控是两回事。成熟的监控方案至少覆盖以下维度：

监控维度	具体内容	需要观察什么
Agent 配置与状态	生命周期状态、版本、基础模型、编排类型（Orchestration Type）、记忆类型（Memory Type）、IAM 角色、会话空闲 TTL	Agent 是否处于可用状态、配置是否与预期一致
知识库关联	关联的知识库 ID、Grounding Pipeline 状态（接地管道状态）	知识检索源是否正常，RAG 回答是否可能"脱锚"
护栏关联	关联的 Guardrail ID 及版本状态	安全控制是否生效、版本是否与预期一致
Agent 性能	每个 Alias / 操作维度的请求量、延迟、错误、限流、Token 消耗	编排链路整体健康度，快速定位故障发生在哪个 alias/操作
底层模型性能	模型级调用指标：延迟、错误、限流、请求量	在 Agent 编排链中隔离"是模型问题还是编排问题"

通过同时观察模型层与 Agent 层，团队能从"模型调用是否正常"上升到"支撑 GenAI 应用的各组件整体是否健康"。

四、如何落地：以 ManageEngine Applications Manager 为例

以下以一个支持 Bedrock 原生监控的 APM 工具为例，说明这类能力在平台中如何呈现、如何配置。这里选择Applications Manager——它通过 AWS 管理 API 接入 Bedrock 与 Bedrock Agents，将其指标与同一环境中其他 AWS 资源和应用组件放在同一个控制台。

4.1 接入方式

Applications Manager 的 Bedrock 监控采用区域级采集：以 AWS 区域为单位创建监控器，通过 CloudWatch 指标 API 按轮询间隔拉取数据。团队只需提供具备相应权限的 AWS 凭证（IAM 角色），即可在该区域内自动发现并监控 Bedrock 资源，无需在被监控侧安装任何Agent。

4.2 模型层：Bedrock 监控覆盖

创建监控器后，平台提供的指标视图与第二节的指标体系一一对应：

• 错误追踪：Invocation Client Errors（4xx）、Invocation Server Errors（5xx）、Throttled Invocations（限流次数），按轮询间隔统计。
• 配额：Estimated TPM Quota Usage，跨 Converse / ConverseStream / InvokeModel / InvokeModelWithResponseStream 四个 API 操作的配额消耗。
• 延迟：Invocation Latency 与 Time to First Token（标准与流式推理均覆盖）。
• 用量：Input Tokens、Output Tokens、Images Generated。
• 流量：Invocations 总量。
• 日志投递：CloudWatch Logs 与 S3 的成功/失败投递次数，其中 S3 区分标准日志与大日志（Large Data）。

监控器提供 Availability（可用性历史）与 Performance（性能与事件）两类视图，支持查看过去 24 小时或 30 天的趋势。

4.3 编排层：Bedrock Agents 监控覆盖

Applications Manager 的 Bedrock Agents 监控（2026 年 7 月起在 18.1 版本中提供）将第三节的维度落到具体监控对象：

• 配置概览：Agent 信息（生命周期状态、版本、基础模型、创建/更新时间）与 Agent 配置（Guardrail ID 与版本、编排类型、记忆类型、IAM 角色、会话空闲 TTL）。
• 版本与知识库关联：版本详情（Build State）、关联的知识库（ID、描述、Grounding Pipeline State）、关联护栏（ID、版本）。该部分数据默认关闭，需在"设置 → 性能轮询 → 优化数据采集"中手动开启。
• 部署与 Alias：Alias 部署记录（部署状态、关联版本、创建/更新时间），确认流量是否路由到正确的部署版本。
• 性能指标：按 Alias 与操作（Operation）维度统计请求总量、客户端错误、服务端错误、限流请求，以及 TTFT 与请求延迟；Token 消耗按 Prompt Tokens / Response Tokens 拆分到每个 Alias 部署。
• 模型层隔离：提供模型级指标（Model Client/Server Errors、Model Request Throttles、Model Request Latency、Model Requests），用于在编排链中单独判断底层模型是否异常。

4.4 告警与阈值

指标采集只是第一步，真正起作用的是告警。Applications Manager 支持对上述指标配置阈值告警：设置阈值、轮询间隔与连续轮询次数（连续几次超阈值才触发，可减少抖动误报），触发后通过邮件、动作（Action）通知，也可联动 ITSM 工单系统（如与 ServiceDesk Plus 的集成）。一个典型的配置思路：

指标	建议阈值/策略	触发后的动作
Estimated TPM Quota Usage	80% 预警、90% 严重	评估配额扩容或优化 Prompt
TTFT / Invocation Latency	按 P99 基线设定，不用平均值	排查模型负载或网络链路
Client Errors（4xx）	按比例设定，提示代码/参数问题	通知应用开发团队
Server Errors（5xx）	按比例设定，提示服务侧故障	检查 AWS Service Health，必要时联系支持
Throttled Invocations	出现即关注，连续 N 次触发	评估配额或退避重试策略
日志投递失败	出现即告警	检查审计链路完整性

4.5 统一视图与关联分析

Applications Manager 的价值并不只在 Bedrock 监控本身，而在于它把 Bedrock 指标放进了一个本就存在的统一监控体系：同一个控制台中，EC2、RDS、Lambda、容器等资源与 Bedrock 工作负载并列展示。这让三类工作变得直接：

1. 下钻定位：用户反馈"AI 回答很慢"时，可从应用层一路下钻到 Bedrock 调用延迟，无需切换工具。
2. 时间轴关联：把基础设施事件（如 EC2 实例异常、网络波动）与 AI 服务指标放在同一时间轴，快速判断根因。
3. 根因回溯：从用户体验问题回溯到具体的模型、Agent 或 API 调用，缩短 MTTR。

4.6 已知边界（客观说明）

• 指标为区域级聚合，粒度到模型/API 操作级别，不提供单次请求级追踪；单次调用级的排障仍需要结合应用侧日志。
• 延迟、TTFT 等指标按轮询间隔取平均值，长尾分布需自行结合告警阈值（如对高百分位敏感的场景，建议同时监控应用侧埋点）。
• 部分 Agent 深度信息（版本详情、知识库关联）默认不采集，需要手动开启性能轮询。

五、构建 GenAI 监控体系的实践建议

工具只是载体，以下实践建议适用于任何同类监控体系，其中告警基线的经验值参考了 AWS 官方指南与社区实践。

5.1 分层监控，不要只盯模型

层级	关注内容	关键指标
应用层	终端用户体验	端到端延迟、请求成功率、用户满意度
编排层	Agent / 工具链	Agent 调用成功率、工具调用延迟、RAG 检索接地状态
模型层	基础模型	调用延迟、Token 消耗、限流事件、TTFT

5.2 告警基线的建立

• TTFT P99 告警，而非平均值——长尾体验才是用户真正感受到的。
• TPM 配额使用率设置 80% 预警阈值，避免流量高峰撞上配额墙。
• 区分 4xx 与 5xx，分别触发不同的响应流程。
• 关注 Token 消耗的突发增长——可能意味着 Prompt 注入攻击或配置错误。

5.3 成本可观测性

GenAI 按 Token 计费，不是按资源计时。建议：按应用、团队、环境（开发/测试/生产）打标签实现成本归属；追踪每次调用的平均 Token 消耗趋势，发现 Prompt 膨胀；对比不同模型的性价比（如同一任务下 Claude Sonnet 与 Haiku 的 Token 成本），为场景选择最优模型。

5.4 审计与合规

确保模型调用日志（输入/输出、Token 统计、模型 ID）完整投递到 CloudWatch Logs 或 S3——监控平台的日志投递指标在这里起的是"审计的审计"作用；对包含敏感数据的 AI 交互启用 Guardrail 监控，追踪护栏干预次数与类型；保留完整审计追踪链，满足合规与事后分析要求。

六、术语速查表

术语	英文	定义	传统监控类比
调用	Invocation	向基础模型发起的一次请求	API 请求
Token	Token	模型处理或生成的基本文本单元	数据包大小，但直接影响成本
输入 Token	Input Tokens	请求中发送给模型的 Token	请求体大小
输出 Token	Output Tokens	模型在响应中生成的 Token	响应体大小
首 Token 时间	Time to First Token（TTFT）	模型开始生成响应所需的时间	TTFB（首字节时间）
每分钟 Token 数	Tokens Per Minute（TPM）	一分钟内处理的 Token 数量	吞吐量
限流	Throttling	达到服务配额时请求被限制	API Rate Limiting

七、常见问题（FAQ）

Q1: Bedrock 监控与直接用 CloudWatch 监控有什么区别？

CloudWatch 提供 Bedrock 的基础指标与日志能力。APM 平台的差异在于：把 Bedrock 指标与同一应用依赖的 EC2、RDS、Lambda 等资源放在同一仪表板中关联分析；提供开箱即用的告警模板、趋势分析与告警动作（如联动工单系统），降低配置与维护门槛。对于已有 APM 体系的团队，这意味着不新增监控孤岛。

Q2: Agent 监控与模型监控有什么不同？

模型监控关注单次推理的性能（延迟、Token、错误）；Agent 监控还需要覆盖整个编排链路——工具调用成功率、知识库检索的接地状态、护栏执行情况、多轮会话管理。Agent 的故障可能发生在任何环节，而不限于模型推理。

Q3: 如何判断是否需要扩容 Bedrock 配额？

持续观察 Estimated TPM Quota Usage：如果工作时段长期处于 70%–80% 以上，且伴随 Throttled Invocations 上升，应考虑通过 AWS Service Quotas 申请扩容；同时评估优化 Prompt 长度、使用更高效的模型版本以降低 Token 消耗。

Q4: 同时使用多个 Bedrock 模型时，监控策略如何制定？

按模型 ID 拆分关键指标（延迟、Token、错误）——不同模型的服务配额、计费模式与性能特征差异很大。为每个生产模型单独设置告警阈值；对比实际调用效果，为业务场景选择性价比最优的模型。

Q5: GenAI 监控与传统 APM 监控最大的不同在哪？

计费模型与非确定性输出。传统应用按资源计时付费，GenAI 按 Token 计费——一次"慢请求"可能同时意味着"贵请求"；且 AI 输出非确定，监控除了关注"是否成功"，还需逐步引入质量维度（响应相关性、准确性、安全性）。

八、总结

GenAI 正在重塑应用架构，也在重塑监控边界。当 AI 模型成为业务关键路径时，监控范围必须从传统应用依赖项扩展到基础模型调用、Token 消耗、Agent 编排与配额管理。核心变化可以归纳为四点：

1. 监控对象变了：从服务器和 API，扩展到基础模型与 AI Agent。
2. 指标体系变了：延迟关注 TTFT 而非仅端到端响应时间；成本关注 Token 而非仅资源利用率。
3. 故障模式变了：限流（Throttling）是 GenAI 特有的故障模式，需要专门监控与预警。
4. 统一视图是关键：把 Bedrock 监控融入既有 APM 平台而非另起炉灶，才能实现端到端可观测性。

以 Applications Manager 为代表的 APM 工具，其价值在于把上述信号落到可操作的监控对象上：区域级自动发现、与 CloudWatch 对齐的指标体系、按 Alias/操作细分的 Agent 性能视图、阈值告警与统一仪表板。对于正在生产环境运行 GenAI 应用的团队，一套覆盖模型层、编排层与应用层的可观测性体系，已经从"加分项"变成确保 AI 应用稳定、可靠、成本可控的必要条件。