Spinnaker第五节-金丝雀分析
目录
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必定会高于刚启动的金丝雀机器,所以要同一时间启动的实例监控来的数据更有说服力。