如何使用Kubernetes监控定位慢调用
内容介绍：
一、课程介绍
二、慢调用的危害和常见原因
三、慢调用的最佳实践
四、案例分析
五、demo状态
六、总结最佳实践
一、课程介绍
今天和大家分享Kubernetes监控公开课第四节如何使用Kubernetes监控定位慢调用。
今天的课程，主要分为三大部分，首先会介绍一下慢调用的危害以及常见的原因，第二会讲解慢调用的分析方法以及最佳实践，之后会通过几个案例来演示一下慢调用的分析过程。
二、慢调用的危害和常见原因
1、慢调用的危害
慢调动大家或多或少都会遇到，慢调用可能带来的危害主要有三个方面。
首先慢调用可能会引起前端加载慢的一个问题，前调加载过慢进一步可能会导致应用的卸载率高，进而影响品牌的口碑。
由于接口慢导致达不到SLO，进而导致项目延期
当接口调用慢的时候，非常容易引起超时，当别人的服务都依赖这个借口时，就会引发大量重试，进而导致资源耗尽，最终导致部分服务或者整个服务不可用的雪崩的现象。
所以综合这三个方面来看，看似是一个无关的问题，可能隐藏着一个大风险，所以我们应该引起警惕，不要忽视慢调用的问题，应该尽可能的去调查引发的原因，从而创造一个更好的方式控制。
慢调用产生的原因归结起来有五个常见的方面，包括资源、代码、依赖、设计、网络。
比如cpu、内存、磁盘、网卡等等，当这些使用过高的时候非常容易引起服务慢进而引起接口慢的情况。
通常来说如果一个SQL的关联了很多重要的表，对MySQL的性能影响这非常大。或者当查询量很大时，也会引起查询慢的问题。
自己的服务没有问题，但是调用下游的时候，下游访问慢了处于等等待状态，也会导致服务的慢调用情况。
比如说海量数据和表，数据量非常大，非常容易引起慢调用。或者是当耗时操作没有缓存。
比如说跨洲调用，跨洲调用的物理距离很大，导致往返时间比较大，进而导致慢调用。或者是两点之间网络性能较差，比如说丢包、重传率。
我们的例子几乎涵盖了这五个方面的原因。
三、定位慢调用的最佳实践
定位慢调用的最佳实践总结了三个方面，一个是黄金信号，一个是资源指标，然后是全局架构。
1、黄金信号
黄金信号是出自SRE圣经 Site Reliability Engineering 一书里的，用于表征系统是否健康的最小指标集合，含延时、流量、错误、饱和度。
典型指标:平均响应、P90/P95/P99分位数，这几个指标可以很好地直观反映出系统对外响应的时间
典型指标:QPS、TPS
- 错误:类似于协议，错误码应分类统计，重点关注严重级别错误码，如5xx HTTP Code.
典型指标:错误码，如果错误很多，代表可能出现了问题
- 饱和度∶资源水位。接近饱和的服务非常出现问题，如磁盘满导致日志无法写入进而导致服务响应慢。
典型指标:CPU、内存、磁盘、队列长度、连接数等
2、资源指标
著名的性能分析大神 Brendan Gregg 在他的性能分析方法论文章里提到了一种方法 USE Method ，USE方法是从资源角度分析的方法，对于每一个资源来说，检查其Utilization（使用率）Saturation（饱和度）、Error(错误)，检查这三项基本上能够解决80%的服务问题，而且只需要花费5%的时间，达到事半功倍的效果。 Brendan Gregg 制作的相关流程图，包括如何查看USE，如何查看每个资源的最终定位结果，不进行展开细讲，但是结论十分重要，USE是一个显性的指标，一般的结构系统或者是框架、资源，都具有该指标，并且对于这些指标的获取也是十分容易的，花费的时间比较少
3、全局架构
全局架构也是 Brendan Gregg 所提到的，即不能只见树木不见森林，不谋全局者不足以谋一域，应该把系统架构画出来，全局地去看性能问题，而不是只是看某一资源或某一服务，那样只能解决局部的问题。应该将各部分内容综合考虑，直识别处慢的瓶颈所在，进一步的通过设计方法去系统性的解决问题。
综合起来看需要环境信号、资源指标以及全局架构的组合构成最佳实践。
四、案例分析
下面进行三个案例的分析，案例一是节点CPU打满的问题，也就是前面提到的资源问题导致的服务慢的问题，这里需要重点突出的是服务自身的资源导致的问题；案例二是有关依赖服务、中间件慢调用的问题，这一部分需要强调的是下游依赖问题；案例三是有关网络性能差导致的慢调用问题，即自身与服务之间可能存在的问题
1、Demo应用
搭建一个简单的电商应用，具有鞋子、玩具等商品可供购买，下图为电商应用的简单架构。
首先入口是阿里云的SLB，用户进入后，流量会进入微服务体系，微服务体系通过网关去接受所有流量，网关会把流量反馈到对应的服务里，然后依赖一些中间件，价格使用阿里云的的监控产品来去监控，故障输入方面注入异常，最上面为流量入口，主要来源于用户、阿里云自身的性能测设产品PTS以及一些开源产品比如说
ApacheBench
2.案例一：节点CPU打满
- 节点CPU打满带来的问题:
- 节点CPU打满后，Pod无法申请到更多 CPU
- 导致线程处于等待调度,进而导致慢调用。
- 类似资源:Memory、磁盘、线程等资源有同样效果。
- CPU在Kubernetes集群中的特点:
- CPU是可压缩资源
- Requests用于调度
- Limits用于运行时资源限制隔离。
- 超过Limit会被Throttled
- 实验原理
实验原理:节点CPU打满后，Pod无法申请到更多CPU，服务因得不到足够CPU调度变慢
- 实验步骤
- 准备工作:配置告警、注入节点CPU打满故障
首先第进行准备工作，通过拓扑图，对关键链路的识别并进行配置告警，比如关键链路（如网关、支付链路)上配置平均响应时间、P90平均响应时间、慢调用率告警。配置完成之后注入网关节点cpu打满故障，等待五分钟之后收到告警。
描述中所讲内容为HTTP协议，以及应用式网关、P90响应时间超过阈值，说明异常已经生效。
首先进入到网关的应用详情，第一步查看黄金信号的响应时间，可以直观地观测到突增区域，慢调用数为1000，属于突然增多的状态，P90和P95上升的比较明显，已经超过1秒了，说明整个服务变慢了，接下来看指标，Pod CPU的使用量上升很快，这个过程需要需要向宿主机申请更多的内存，通过观察可以发现宿主的cpu使用率达到了100%，百分之百是前面用工具中所注入的，反过来说明了节点cpu使用率达到了100%，不可能给 Pod 申请更多的内存了，Pod无法申请到更多的内存，进而导致了服务慢，表现为黄金信号、响应时间大量的增长。所以基本可以定位到故障是由于cpu打满导致的，
流量、资源的使用量不确定因此可能会导致不够的现象，面对这种情况最好的方法就是给资源配置的弹性伸缩。为节点配置弹性伸缩的主要目的是为了确保在负载上升的时候资源能够动态地扩容，可以通过增加副本数来分担流量。配置完成重新执行效果如下图所示：
- 注入cpu慢故障的时候，可以看到慢调用会上升
- 上升之后会触发到弹性伸缩，cpu的使用率超过70%，
- 自动的扩出一些副本去分担流量，可以看到慢调用数量逐步下降直到消失，说明弹性伸缩起到作用。还有其他解决方案比如垂直伸缩。
3.案例二：依赖服务或者中间件慢调用
- 定位步骤
- 准备工作：配置告警、注入SQL慢查询故障
网关进来后调用了两个下游服务，一个是MySQL,一个是Product service 所以要配置以告警：
1)网关P99响应时间大于1s
2) Product服务P99响应时间大于1s
3) MySQL P99响应时间大于1s
配置完成之后在Product服务上注入MySQL慢查询的故障，等待大概两分钟，告警陆续显示出来，监控会把告警时间通过密闭空间应用自动 match 到节点上，所以能够明确地看到哪些服务、哪些应用是有异常的，能够快速定位问题所在
1)查看网关对应指标，P99上涨到1800ms ,因而引发告警
2）查看Product的详情，发现发生慢调用
3）查看product的下游,发现与MySQL的交互有慢调用
4)进一步查看trace数据，发现SQL里关联了多张表
首先是驱动，因为预防的效果优于补救，所以采用先配置告警，然后再去根因定位，然后用拓扑进行可视化的分析，因为拓扑可以进行交互感知、监控下游，以便进行可视化的溯源。
查看到告警后，针对告警去了解具体的应用会发生怎样的情况，例如网关P99上升到1800ms以上，会触发大于阈值的告警，进一步看另外一个发生告警的服务Product，点开节点之后，可以看到 Product 也发生了慢调用，P99和P95都已经不同程度地发生了慢调用，均大于1秒，这时候可以去看资源使用情况的可能。查看到下游，发现MySQL交互的时候会有大量的慢调用，点击慢调用明细，查看调用的时候出现了哪些问题。可以发现Product调用MySQL的时候执行了一条复杂的具有多张表的语句，这样就能够基本定位到是这条SQL产生的问题
流程为：架构感知识别关键路径，配置告警主动发现异常，通过应用和下游持续下钻，跟踪资源指标、黄金信号，网络trace最终定位根因
4、案例二：网络性能差
KBS的网络架构是比较复杂的，包括容器间通信、Pod间通信、Pod与服务之间的通信、外部与服务之间通信等等，所以它的复杂度是比较高的，学习的曲线比较陡峭，定位也就具有一定的困难。
1)速率和带宽
2)吞吐量
3)延时
4) RTT
如果这些指标有异常，那么可能就是网络性能的问题。
- 定位步骤
- 准备工作:配置告警、注入MySQL所在节点丢包高故障
- 收到慢调用告警，网关和product的RT发生大于1s告警
- 根因分析
首先配置告警，然后注入一个MySQL所在节点丢包略高的故障，等待几分钟之后收到慢调用的告警（网关和Product时间都大于1s的告警），接下来是根因分析：
- 网关发生了慢调用，P99响应时间暴增
- product也发生了RT P99平均响应时间告警，点击网关和product之间的线，观察到慢调用
- product服务有慢调用现象
- product下游MySQL之间发生了严重的RTT上升和重传现象，可定界为网络问题，RTT正常情况下很平稳的，反映的是上下游之间的往返时间。如果上涨速度极快，基本上可以认定为是网络问题。
从网关、product、MySQL中总结出通过识别关键路径，然后在拓扑上配置告警的方法可以非常快速的定位问题，而不需要去查证很多散落在各个地方的信息，只需要在拓扑上查看对应的性能指标，即可定位到问题所在。
五、demo状态
1、节点CPU打满
第一个案例中Cpu打满之后会产生慢调用，进入到拓扑图后可以看到告警内容：
P99响应时间大于阈值，当前时间为1450ms.然后可以看到黄金信号指标，这段时间的特别显著，点击详情可以查看对应的资源指标，对cpu的申请非常大，达到了200多；
对节点的使用率到了98%-99%，说明节点的cpu基本上已被用尽，应用的扩容几乎无法完成，进而导致了慢调用的现象。
可以看到从告警发现到定位问题，经历了三个过程，先看拓扑的告警，然后看详情里面的资源指标，然后定位到资源的使用问题。
2、SQL导致的慢调用
首先点击告警，可以看到有大量的慢调用，点击明细发现调用均大于两秒，SQL语句十分复杂，最终导致了慢调用，可以将SQL语句拿出来进行优化来减少慢调用。
六、总结最佳实践
首先配置一些告警去用于主动发现、主动上报，这些告警都是默认下发的，现有几十个告警的最佳实践模板，发现告警之后会进行黄金信号以及资源指标的分析，然后用网络trace来配合下钻，进行异常的定位和发现，以上两步主要是能够更快地发现异常，接下来用拓扑来进行上下游分析、架构感知、影响面分析等，最终通过设计方案进行系统的调优。
