AWS 上的 LLM 可观察性：审核 AgentCore 跨度目标

AWS 上的 LLM 可观察性 的实际答案不是“打开 CloudWatch 仪表板”。首先证明 Amazon Bedrock AgentCore 应在何处交付跨度，然后搜索仍可包含证据的每个目标、验证会话和跟踪身份、拒绝过时的观察结果，并将跟踪连接到单独的收据以获取预期的外部结果。 该顺序很重要，因为 AgentCore 的目的地可能会发生变化。当前的 AWS 文档称，受支持的新代理可以将跨度发送到每个代理日志组，而旧配置可能使用共享的 aws/spans 组。 0.18.0 之前的 ADOT 版本忽略统一目标设置。更改设置不会移动旧的跨度。因此，仅针对今天的日志组的查询可能会产生错误的“无遥测”诊断，即使丢失的证据正是先前配置所放置的位置。 本指南针对该边界构建了无内容审核。它使用资源标识、版本、目的地、时间戳、相关标识符、运行状态和布尔结果收据。它不需要提示、响应、工具参数或秘密。 在宣布证据丢失之前先找到证据 AgentCore 可观察性 为 AgentCore 资源提供内置指标，并将指标、跨度和日志存储在 Amazon CloudWatch 中。重要的界限是内置指标与应用程序跟踪不同。 AWS 记录内存资源的默认跨度，而代理运行时和网关跟踪详细信息取决于检测。 这就产生了三个独立的问题： 1. 是否启用了 AWS 观察路径？ 必须启用 CloudWatch Transaction Search，并且跟踪段目标必须是 CloudWatch Logs。 2. 当前跨度应落在哪里？ 答案取决于统一目标设置、区域支持、代理年龄、执行角色和 ADOT 版本。 3. 历史跨度可以保留在哪里？ 切换之前使用的任何目标仍然是调查窗口的一部分，因为 AWS 不会迁移现有跨度数据。 这 AgentCore配置指南 给出了一个特别有用的操作边界：每个代理统一交付需要 aws opentelemetry distro =0.18.0 。早期版本忽略配置并将跨度传递到共享组。该指南需要安装相关 CloudWatch Logs 资源策略的权限。 在查询之前使用这些事实来计算预期目的地： 观察 预期当前搜索范围 算子结论 交易搜索已禁用 目前还没有一个值得信赖 修复设置；不推断代理的健康状况 跟踪段未路由到 CloudWatch Logs 目前还没有一个值得信赖 修复目标先决条件 统一要求，ADOT低于 0.18.0 共享 aws/spans 每个代理组为空是查询范围错误 允许统一的活动和角色策略 每个代理运行时日志组 检查那里的当前跨度 审核期间目的地发生变更 当前和以前的组 搜索两者；旧的跨度留在他们着陆的地方 该表故意不是单一的“遥测存在”检查。每个代理组中的记录丢失可能意味着设置失败、传送受阻、旧的 ADOT 版本或共享组中的正确历史记录。这些州需要不同的修复。 保留目的地转换记录 不要将活动设置作为唯一的事实来源。在 Runbook 旁边存储一个小的转换记录： 该记录不包含任何提示或响应内容。它回答了仪表板以后无法重建的查询计划问题：哪些目的地与事件窗口重叠？ 运行迁移感知的 AgentCore 审核 本文使用的审计评估了 11 个固定案例。它的输入契约故意很小： 它的决策顺序比它的语法更重要： 在产生的夹具上运行分类器： 这些案例包括禁用的事务搜索、错误的跟踪目标、仅在每个代理组中查询旧的 ADOT、切换后遗漏历史证据、交付权限不足、缺少当前跨度、过时的证据、损坏的关联、合法的批准等待、错误完成以及健康的迁移感知结果。 这是一个决策测试，而不是有关真实 AWS 账户的证据。根据您自己的配置和金丝雀查询调整其输入。保留顺序：否则通用的 telemetry missing 判决可能会隐藏操作员搜索错误位置这一更具可操作性的事实。 保留会话身份、跟踪身份和新鲜度 AWS 将 AgentCore 可观察性描述为层次结构：会话包含跟踪，跟踪包含跨度。这 遥测文档 使层次结构变得明确。仅当身份在请求路径中幸存下来时它才有用。 对于 ADOT 检测的 AgentCore 运行时调用，配置指南记录了两个传播详细信息： 发送 X Amzn Bedrock AgentCore Runtime Session Id 以便会话 ID 到达下游遥测； 当必须传播跟踪 ID 时，使用 traceId=<traceId 调用运行时。 记录这些标识符是否存在，而不是记录它们的敏感负载上下文。没有可连接会话的跨度仍然可以证明代码已执行，但它不能支持会话级事件时间线。将其分类为 correlation broken ，不健康。 新鲜度需要类似的明确合同。上周发现的痕迹并不能证明交付现在有效。定义： 从工作流程的预期节奏和事件容忍度中选择最大期限。对于每分钟金丝雀来说，五分钟是合理的；对于每晚一批来说是不合理的。将阈值与判决一起存储，以便“新鲜”仍然可以检查。 等待也需要证据。如果跟踪显示与所有者的有限批准依赖性并且运行可恢复，则返回 waiting 。不要仅仅因为没有出现新的工具跨度而将其页面卡住。如果审批记录不存在、矛盾或过期，请返回 uncertain 或根据操作手册升级。 跟踪后需要结果收据 完整的跟踪回答“检测的执行路径是否完成？”它不一定回答“预期的工作发生了吗？” 这种区别在常见故障中显而易见： 上传工具在目的地提交对象之前返回； 消息 API 接受请求，但消息从未到达预期通道； 代理写入本地文件，而所需的工件属于远程存储； 下游事务回滚后，最终模型调用成功； 批准等待被错误地转换为最终成功。 AWS 规范性指南 建议将 LLM 证据与下游影响相关联。隐私最小化实现可以通过结果收据来做到这一点： 收据应由可用的最强确定性检查生成：对象 HEAD 、通过稳定密钥读取的数据库、公共 API 获取、校验和或有针对性的测试。它不应包含对象主体、提示、响应或秘密。 将两个判决分开： 痕迹证据 结果收据 状态 丢失或陈旧 任何 可观察性证据不足 完全的 丢失的 false complete 等待记录批准 还没预计到 waiting 完整且新鲜 目前并已验证 healthy 对于此测试结果 最后一行是有范围的。它证明了固定的金丝雀和目的地，而不是每条路线、每项任务或语义输出质量。 通过审核而不收集内容 有用的生产收据只需要足够的数据来区分故障层： 编辑或散列形式的代理资源和端点标识符； 区域和观察时间； 交易搜索和追踪目的地状态； ADOT版本和统一目标设置； 当前和之前的目的地舱位； 调查窗口是否对两个目的地进行了搜查； 最新匹配的金丝雀时间； 会话 ID 和跟踪 ID 的存在； 运行状态和有界批准状态； 稳定的操作身份和确定性的结果接收状态。 将此收据中的提示文本、模型响应、工具参数、凭据、原始标头和客户负载保留在其中。如果特定事件需要进行更深入的内容检查，请单独授权并确定其范围。 审计也有局限性。它不能证明每个应用程序路径的仪器覆盖范围、采样完整性、CloudWatch 保留、导出恢复或语义答案质量。它证明所选的证据路径是可配置的且可搜索的，金丝雀是新鲜的且相关的，并且所选的外部结果有自己的收据。 这足以防止代价高昂的类别错误：因为操作员搜索了错误的跨度目标而更改代理。 Sidewisp 目前处于私密预览阶段。 其预期作用是将目的地覆盖范围、新鲜度、相关性、等待状态和结果验证等证据转化为清晰的健康视图。目前尚未发货生产 AgentCore 和 CloudWatch 监控适配器，因此本文是您现在可以应用的操作模式，而不是声称 Sidewisp 已经运行此审核。