New Relic LLM 可观测性：证明每个调用由一条路由负责

New Relic LLM 的可观测性功能可显示模型延迟、令牌数、错误、追踪信息以及 AI 响应数据。但仅凭该功能本身，无法让运维人员确定两个采集器是否统计了同一条模型调用，也无法确定代理是否生成了所请求的外部结果。实际操作中的默认做法是： 为每个模型调用边界指定一名仪器化所有者 ，将每条记录与一个无内容信息的调用 ID 相关联，并为可交付成果单独保留一份收据。 这条规则之所以重要，是因为 New Relic 记录了多种合法路径。其原生 AI监控 使用 APM 代理。New Relic 还记录了 OpenLIT 优先于 OTLP 用于跟踪和指标以及 OpenLLMetry 优先于 OTLP 用于追踪。LiteLLM 有一个单独的 New Relic 集成 围绕其回调函数和 New Relic、Python 代理构建。 这些路径只是选项，并非证明所有人都应配置相同的边界。即使所有权设置有误、证据已过时、必填字段缺失，或者已完成的模型调用没有经过验证的结果，仪表盘仍可能显示相关数据。 在相信海图之前，先规划好航线 请从部署清单开始，而不是从查询开始。该清单应明确指定服务、待监控的边界、唯一有权报告该边界的负责人、该负责人可发出的信号类型、关联字段以及数据新鲜度限制。 所有者 与 信号类型 之间的区别可避免一种粗略的去重错误。一个已声明的所有者可能会针对同一通呼叫，有意识地发出一个 APM 跨度记录和一个 AI 消息事件。当这些记录共享相同的呼叫 ID 且部署契约要求同时包含两者时，它们是互补的。针对同一边界的 OpenLIT 记录和 OpenLLMetry 记录属于两个不同的所有者，即使它们的字段看起来相似。 清单应由启用了仪器化的部署生成。请勿根据用户界面中恰好显示的任何实体来推断该清单。设置路径通过不同方式确定身份： New Relic AI 监控需以 APM 代理和受支持的库或框架为基础。 OpenLIT 将跟踪信息和指标发送至 New Relic 的 OTLP 端点。 OpenLLMetry 将跟踪信息发送到该端点，而 New Relic 则从 OpenTelemetry 的 service.name 资源属性中推导出服务实体。 LiteLLM 启用了 newrelic 回调，并使用 New Relic 和 Python 代理来处理 APM 遥测数据。其文档指出，该回调会记录一条初始化消息，且跟踪详细信息可能需要两到三分钟才会显示出来。 仅此一点就足以要求添加一条显式路由记录。但这并不能证明任何特定的两方组合一定会导致调用重复。安全的运行声明范围更为狭窄：如果观察到某个边界存在两个所有者，而该边界的规范仅允许一个所有者，那么在部署问题得到解决之前，总计值和健康状态判定将处于不确定状态。 请使用不透明的呼叫标识符，而不是提示哈希值。一个有用的观察信封可以不包含任何内容： 提示和响应内容对于所有权、时效性、令牌字段存在性或目标验证而言并非必要。LiteLLM 既记录了 New Relic 特有的 turn off message logging 设置，也记录了一个用于禁用 AI 监控内容记录的环境开关。请将内容保留视为一项独立的隐私决策；切勿仅为了使所有权审计正常运行而启用该功能。 重现绿色视图所隐藏的八种状态 随附的审计使用了八个合成调用。它采用以下优先级规则： 1. 无观察结果； 2. 预期的所有者缺席； 3. 有多个所有者； 4. 信号类型异常或缺少必填字段； 5. 过时的证据； 6. 合理的等待； 7. 在未收到结果确认的情况下完成； 8. 完成并收到结果确认单。 优先级很重要。来自正确所有者的过期记录是不健康的。来自错误所有者的最新记录同样不健康。只有在所有权、结构和新鲜度都通过验证后，才会对“等待”进行评估，因此批准暂停无法掩盖集合中的问题。 完整的程序中不包含任何提示或响应。运行该程序会产生八种不同的判决结果： 该分类器是刻意设计得比较小的： 每项“不健康”的判定结果都对应一种不同的修复方案： 结论 其确立的内容 有界下一个动作 NO TELEMETRY 未收到预期来电的相关记录 检查仪表初始化情况、导出器的可达性以及查询窗口 ROUTE DRIFT 数据已收到，但并非来自声明的所有者 将部署清单与正在运行的进程进行对比，并禁用非预期的路径 MULTIPLE OWNERS 有多位仪表所有者观察到了该边界 将该调用从总计中隔离；选择一个所有者，或记录一个有时间限制的迁移异常 SCHEMA GAP 所有权信息正确，但证据无法使用或不完整 在触发警报之前，请先修正字段映射或信号类型契约 STALE 最新证据显示其年龄超过了允许范围 检查导出程序的延迟、队列、时钟同步以及查询时间 WAITING 集合状态良好，且指定依赖项仍然存在 通知所有者或等待至记录的截止时间；请勿重启代理 OUTCOME UNVERIFIED 模型调用已完成，但未提供所请求效果的证明 运行确定性目标检查 HEALTHY 所有权、证据、工作状态和结果均一致 请保留收据，并按常规稳定性窗口操作 MULTIPLE OWNERS 不应自动删除或合并记录。在计划性迁移期间，双重收集可能很有用。请明确说明该例外情况，包括开始时间、结束时间、负责人以及对账规则。在比较两条路径之前，请将迁移观察结果排除在生产环境的成本和可靠性分母之外。否则，看似突增的令牌数量可能只是监控配置的变更，而非行为变化。 该故障单还说明了为什么“通用红色状态”的诊断能力较弱。 ROUTE DRIFT 是一个部署问题； STALE 可能是数据摄取或查询窗口问题； WAITING 并非故障；而 OUTCOME UNVERIFIED 需要进行目标检查，而非再次执行跟踪查询。 将可观测性关联到结果收据 New Relic 的 AI 监控文档描述了性能、成本、令牌、响应、跟踪以及用户反馈等证据。这些都是关于 AI 层的有用信号。模型响应之后，仍可能出现工具调用失败、文件未提交、电子邮件未发送，或者任务正在等待审批等情况。 因此，请将目标收据保存在模型调用遥测数据之外： 目标和验证方法取决于具体任务。对于文件上传，应使用对象版本；对于代码变更，应使用提交哈希值并进行校验；对于消息投递，应使用提供商消息 ID；对于配置变更，应使用 API 读回。当预期结果存在于其他地方时，命令退出代码的可靠性会降低。 在重放中， false complete 和 healthy 具有相同的两个 New Relic 侧信号类型、所有者、字段和新鲜度。仅目标收据发生变化。这就是操作边界：LLM 的可观察性解释了模型调用的证据；收据则证明了代理预期的结果确实存在。 实际的部署规模较小： 1. 选择一个真实的模型 调用边界。 2. 在部署中记录其预期的仪表所有者及允许的信号类型。 3. 生成一个合成呼叫ID，并查询与该ID相关的所有New Relic事件类型。 4. 如果预期所有者缺席或出现任何未声明的所有者，则终止部署。 5. 验证必填字段和限定的新鲜度时间段。 6. 分别记录 working （一个命名等待依赖关系）或 complete 。 7. 在将 complete 标记为“正常”状态之前，必须收到确定性的目标确认。 8. 在 SDK、回调、导出程序或代理升级后请重复此操作。 该流程存在一个局限性：它无法证明所有由 New Relic 支持的集成都会对每种框架组合进行双重配置。它仅能证明 您观察到的部署 是否与其声明的所有权契约相符。此外，它也不能替代 New Relic 的兼容性检查，也不能替代完整的 OpenTelemetry 模式符合性测试。 Sidewisp 的预期作用与这一区分密切相关：将有关可达性、有效进展、工具、成果、时间和预算的证据整合到一个“代理健康”视图中。Sidewisp 目前处于私密预览阶段。 当前上线的产品是一个早期访问网站和演示系统；正式版的 New Relic 适配器、监控引擎和自动恢复执行器尚未发布。请将上述审核结果与您当前的遥测和目标系统结合使用，而非假设 Sidewisp 目前已收集或修复了相关数据。 该解决方案的实施相当简单：每个模型调用边界对应一个声明的仪器所有者；仅当清单允许时才使用多种信号类型；提供新的、不含内容的信息；明确的等待状态；以及独立的结果收据。只有当这些边界达成一致后，绿色 New Relic 视图才对代理操作具有可信度。