Argo Rollouts 中 Datadog 指标查询 404 错误分析与解决方案

问题背景

在使用 Argo Rollouts 进行渐进式部署时，许多团队会依赖 Datadog 提供的监控指标作为金丝雀发布的分析依据。近期有用户报告，在升级到 v1.7.0-rc1 版本后，AnalysisTemplate 中使用 Datadog 提供商的查询开始频繁出现 404 错误，导致部署流程无法正常完成。

错误现象

当 Rollout 资源执行到分析阶段时，Datadog 查询会返回以下错误信息：

received non 2xx response code: 404 {"errors":["Not found"]}

这种错误会导致分析步骤失败，进而阻止整个部署流程的完成。值得注意的是，这个问题在 v1.6.6 版本中仅偶尔出现，但在 v1.7.0-rc1 中变得更为频繁。

问题分析

通过深入调查，我们发现这个问题与 Argo Rollouts 中 Datadog 提供商 API 版本的处理方式有关。在 v1.7.0 版本中，一个重要的变更是将默认 API 版本从代码中移出，改为通过安装清单(install.yaml)进行配置。

关键点在于：

1. 当 apiVersion 参数未明确设置时，系统可能会构造 v2 版本的请求
2. 但实际路由仍在使用 v1 版本的 API 端点
3. 这种版本不匹配导致了 404 错误响应

解决方案

要解决这个问题，需要确保 Datadog 提供商的 API 版本配置正确：

1. 更新安装清单：确保在升级到 v1.7.0 或更高版本时，同时更新 install.yaml 文件，包含正确的 API 版本配置。

2. 明确指定 API 版本：在 AnalysisTemplate 中显式设置 Datadog 提供商的 apiVersion 参数，避免依赖默认值。

3. 完整部署流程：注意在更改配置后，需要进行全新的部署，简单的回滚或同步可能无法完全解决问题。

最佳实践建议

为了避免类似问题，我们建议：

1. 版本升级时检查变更日志：特别是涉及外部服务集成的变更。

2. 测试环境先行：在生产环境部署前，先在测试环境中验证新版本的兼容性。

3. 明确配置优于隐式默认：对于关键配置如 API 版本，建议显式声明而非依赖默认值。

4. 监控部署过程：设置适当的告警机制，及时发现分析步骤中的异常。

总结

Argo Rollouts 与 Datadog 的集成为渐进式部署提供了强大的监控能力，但版本升级时的配置变更需要特别注意。通过理解 API 版本管理机制并遵循明确的配置实践，可以避免类似 404 错误的发生，确保部署流程的顺畅进行。

对于已经遇到此问题的团队，按照上述解决方案更新配置后，应该能够恢复正常功能。未来版本中，Argo Rollouts 团队也可能会进一步优化默认配置的处理逻辑，减少此类问题的发生概率。