追踪每一次供应商故障转移尝试

概览

当某个请求的首选供应商失败时，ModelRiver 的多供应商故障转移系统会自动使用您工作流（workflow）回退链中的下一个供应商进行重试。每一次失败的尝试都会作为一次**故障转移尝试（failover attempt）**被记录在时间线中，捕获完整的请求/响应数据以及失败原因。这为您提供了对系统弹性行为的完全可见性。

故障转移尝试如何展示

在日志列表中

需要故障转移的请求会显示一个失败模型徽章（failed models badge）：一个红色的徽章，上面带有数字，指示在请求最终得到解决之前失败了多少次供应商尝试。

示例：显示“2 failed”的徽章表示在第三个供应商成功之前（或在耗尽所有供应商之前），有两个供应商失败了。

在时间线（Timeline）中

故障转移尝试在时间线开始时（主请求之前）显示为琥珀色/黄色的徽章：

• 位置：在主请求之前，按时间顺序排列
• 徽章颜色：琥珀色/黄色
• 徽章内容：供应商图标、名称和模型
• 额外信息：持续时间和时间戳

点击后显示内容

点击故障转移尝试将展示：

• 供应商与模型 – 尝试了哪个供应商和模型
• 状态 – 显示为“Failed”（失败），并附有具体错误
• 时长 – 在失败之前这次尝试花费了多长时间
• 时间戳 – 尝试发生的时间
• Request Body 选项卡 – 发送给供应商的准确请求内容
• Response Body 选项卡 – 供应商返回的错误响应

理解故障转移数据

主请求 ID（Primary Request ID）

每一次故障转移尝试都通过 primary_req_id 字段链接到其最终的主请求。这形成了一条链条：

这种链接确保您始终能够追踪任何请求的完整故障转移链条。

常见失败原因

故障转移对性能的影响

每一次故障转移尝试都会增加总的请求延迟：

频繁的故障转移表明供应商不稳定，并直接影响用户体验。请参阅性能监控以进行延迟分析。

故障转移对成本的影响

有些供应商即使在请求失败时也会对 tokens 收费（如果模型在发生错误前处理了 tokens）。这意味着故障转移可能会增加请求的真实成本，使其超出主请求显示的成本。

查看成本分析以获取成本优化策略。

调试故障转移尝试

逐步调查

1. 打开请求详情 – 单击日志列表中的请求
2. 回顾时间线 – 注意故障转移尝试的次数和顺序
3. 单击每次故障转移尝试 – 查看错误详细信息
4. 比较请求体（request bodies） – 验证发送给每个供应商的请求是否相同
5. 阅读错误消息 – 找出具体的失败原因
6. 寻找规律 – 总是同一个供应商失败吗？错误总是一样的吗？

应该寻找什么

• 跨供应商出现相同错误 – 可能表明是请求级别的问题（例如，违反内容策略）而不是供应商问题
• 某一供应商总是失败 – 供应商特定的问题；考虑移除或降低其优先级
• 速率限制错误 – 请求过多；需要分散负载或升级计划
• 间歇性故障 – 暂时的供应商问题；故障转移正在按设计运作

故障转移最佳实践

明智地配置回退供应商

• 多样性：使用来自不同厂商的供应商，以避免相关联的故障
• 优先级：将最可靠的供应商放在最前面
• 成本意识：将更便宜的供应商放在链条的前面
• 兼容性：确保所有回退供应商都支持您的请求格式

监控故障转移率

• 跟踪有多少百分比的请求需要进行故障转移
• 为故障转移率阈值（例如，> 5%）设置警报
• 定期查阅供应商可靠性

对故障转移规律做出响应

• 持续失败：移除失败的供应商或更新凭据
• 速率限制：升级供应商计划或降低请求频率
• 模型弃用：更新工作流以使用替代模型

下一步

• 首要请求 – 主请求的详细信息
• 供应商可靠性 – 总体的供应商故障分析
• 性能监控 – 故障转移对延迟的影响
• 返回时间线（Timeline） – 时间线概览