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