目录
Spinnaker的金丝雀分析并不是Spinnaker通过代码独立完成的，它只是提供了一个概念，借助部署策略和监控工具来实现的。
核心思想：
基于生产环境的镜像和测试版本的镜像各开一组服务器，接入线上流量，利用Prometheus等监控工具来采集这两组服务器的数据，最后利用Spinnaker的Kayenta服务节点对数据进行分析，最终给出评判结果。
金丝雀分析的意义：
1 完全依赖生产环境，测试结果真实可靠
2 完全与业务解耦，应用场景广泛，不需要单独开发脚本，不需要随版本变更而进行脚本的维护。
3 借助Spinnaker的Pipeline可以完全做到自动化
4 金丝雀分析的资源可以在云端按需开通，成本极低。
三大分区：
首先要了解三个分区，每个区负责做自己分内的工作。
载体区：
云实例、弹性伸缩组、Pod、ReplicSet，载体区负责承接生产请求流量。
监控区：
Prometheus、DataDog等监控工具，负责为金丝雀分析提供数据。
Spinnaker区：
负责做金丝雀分析，又分为两部分
CanaryConfig：metres、权重、group
CanaryStage：filter、阈值
载体区的原理图：
1个LB下面挂3个弹性伸缩，其中as_product是生产机器，常驻的。只有做金丝雀分析的时候会新增as_baseline和as_canary这两个新伸缩族，里面各放1个实例。因为Prometheus采集需要消耗性能，而只有as_baseline和as_canary里的机器才是我们采集分析的实例，所以可以通过云平台的tags中Prometheus是否等于on来进行过滤。
金丝雀分析一般设置为1个小时，分析结束后直接销毁as_baseline和as_canary。
监控区的原理图
主要利用Prometheus的Discovery功能自动发现云平台中的实例，然后Spinnaker会拿着分析所需的参数通过http请求来Prometheus这边来取数据。
Spinnaker区的原理图：
先要预设需要分析的Group，每个Group中又可以细分需要分析的指标，按组为单位分配权重，根据最终的分析结果进行打分。满分100，可以自定义审核策略，例如我图中所示60以下判为false，80以上判为true，中间灰色部分需要分析金丝雀报告进行人工干预。
三大区总体图：
最后三大原理图串起来，画一个图，我们一起看下数据是怎么流转的。
思考题：
为什么不直接取一台生产的机器来做baseline呢？
1 不方便管理
充分利用云的tag功能对流量的调度还是Prometheus的自动发现都有极大的便利性。
2 不是同时开机，指标不准确。
举JVM监控这个简单场景，直接取生产机器它的JVM必定会高于刚启动的金丝雀机器，所以要同一时间启动的实例监控来的数据更有说服力。
