使用Spinnaker进行金丝雀分析

2018 年，Kayenta（一种用于自动化金丝雀分析的开源工具）作为 Spinnaker 项目的一部分推出。在本文中，我们描述了如何将 Kayenta 集成到我们现有的部署设施中，极大地提高了部署管道的可靠性并为自动化生产部署创造了先决条件。

概念理解

什么是金丝雀分析？

金丝雀分析 (canary analysis) 是一个两步的过程，分析将根据选定的指标和日志评估金丝雀，以推断我们是否要升级或回滚新版本。因此，我们需要确保在测试过程中收集正确的信息（指标和日志）并进行可靠的分析。

金丝雀分析的执行步骤

• 指标选择
• 指标评估

指标选择

该步骤涉及选择正确的指标来监控应用程序和金丝雀健康状况。因此我们需要确保创建一套平衡的指标来评估指标。最后，需要根据彼此的相关性对指标进行分组。

对于指标的选择，根本不需要选择所有指标，因为目前流行的基于微服务的应用程序通常会生成大量监控指标数据，因此我们不能简单地分析所有指标。

指标评估标准

选择重要的业务指标

最重要的指标是值对 可以反应服务 “成功/失败” 最重要的指标。例如，在在线购物结帐系统中，一定要测量每分钟的交易次数、失败率等。如果这些指标中的任何一个超出基线，您可能会决定回滚金丝雀。再例如，可以检测服务的数据库连接状态，初始化状态等指标，一旦指标超出基线则表示服务异常，这时候需要回滚。

平衡一组慢速与快速指标

一个有意义的金丝雀流程来说，单个指标是不够的。一些要监控的重要指标是立即生成的，而另一些则需要一些时间才能生成，因为它们依赖于负载，网络流量，高内存使用率或其他因素。在快速指标和慢速指标之间平衡您选择的指标非常重要。例如，服务器查询时间和延迟检查可以分别是慢度量和快度量的示例。因此选择一组平衡的指标，是对金丝雀的健康状况有全面的了解。

冒烟测试

从平衡组测试中，我们必须确保我们拥有直接表明金丝雀中存在问题的指标。所以冒烟测试很适合在这里使用，尽管我们的目标是找出金丝雀的健康状况，但使用此类指标找出金丝雀是否存在潜在问题也同样重要。例如，404 响应或其他意外的 HTTP 返回代码（200 秒、300 秒）可能意味着您的测试应立即停止并进行调试。CPU 使用率、内存占用、HTTP 响应码（200 秒、300 秒等）、响应延迟、正确性是一组很好的指标，但 HTTP 返回代码和响应延迟表明影响用户和服务的实际问题。

metrics 标准范围

这些公制选择需要有一个可接受的发挥范围，通过商定的可接受的指标行为，这样将能够消除那些被错误评估为好金丝雀的坏金丝雀。

金丝雀判断

执行金丝雀分析的最后一步是评估指标的值。通过这个步骤，将能够评估金丝雀实例是否应该升级到生产环境。

在提出每个假设之前，我们将定义两个假设，并根据我们的数据证明其中一个假设是错误的。

• Unacceptable：回滚
• Acceptable：部署到生产

Kayenta 比较两个时间序列，并在偏差超过某个阈值时发出警报。作为这些应用程序指标的来源，我们使用 New Relic Insights。对于这个后端，我们还将代码作为开源代码贡献给Kayenta ³。还可以支持其他后端（Datadog、Prometheus 等）。有关自动金丝雀分析的一般信息，请参阅Google和Netflix的优秀文章。

Reference

^[1] Install Halyard on Docker

^[2] ERROR Could not load “versions.yml” from config bucket: 403 #3920

^[3] Spinnaker: How to bring custom boms into spinnaker pod to be able to deploy it with hal?

^[4] MinIO Object Storage for Kubernetes

^[5] BOMs and Configuration on your Filesystem

^[6] ! ERROR No persistent storage type was configured. #5875

^[7] Install in Air Gaped Environment

^[8] I can’t load the Applications screen

^[9] use k8s cluster private, how to access? not use localhost! #4689