如何使用 Kubernetes 监测定位慢调用

作者：李煌东

咱们好，我是阿里云的李煌东。今日我为咱们共享 Kubernetes 监测公开课第四节，如何运用 Kubernetes 监测定位慢调用。今日的课程首要分为三大部分，首要我会介绍一下慢调用的损害以及常见的原因；其次我会介绍慢调用的剖析办法以及最佳实践；最终经过几个事例往来不断演示一下慢调用的剖析进程。

慢调用损害及常见原因

在开发软件进程中，慢调用对错常常见的反常。慢调用或许带来的损害包含：

• 前端事务维度： 首要慢调用或许会引起前端加载慢的问题，前端加载慢或许会进一步导致使用卸载率高，然后影响品牌的口碑。

• 项目交付的维度： 由于接口慢导致达不到 SLO，然后导致项目延期。

• 事务架构稳定性： 当接口调用慢时，十分简单引起超时，当其他事务服务都依靠这个接口，那么就会引发许多重试，然后导致资源耗尽，最终导致部分服务或许整个服务不可用的雪崩的现象。

所以，看似一个无关痛痒的慢调用或许隐藏着巨大危险，咱们应该引起警觉。对慢调用最好都不要去忽视它，应该尽或许去剖析其背面的原因，然后进行危险操控。

发生慢调用的原因有哪些？发生慢调用的原因是千千万万的，归结起来有五个常见原因。

• 第一个是资源运用率过高问题，比如说 CPU 内存、磁盘、网卡等等。当这些运用率过高的时分，十分简单引起服务慢。

• 第二个是代码规划的问题，一般来说假如 SQL 它相关了许多表，做了许多表，那么会十分影响 SQL 履行的功能。

• 第三个是依靠问题，服务自身没有问题，但调用下流服务时下流回来慢，自身服务处于等候状况，也会导致服务慢调用的情况。

• 第四个是规划问题，比如说海量数据的表十分大，亿等级数据查询没有分库分表，那么就会十分简单引起慢查询。类似的情况还有耗时的操作没有做缓存。

• 第五个是网络方面问题，比如说跨洲调用，跨洲调用是物理距离太大了，导致往复时刻比较长，然后导致慢调用。或许两点之间的网络功能或许比较差。比如说有丢包重传率，重传率高的问题。

今日咱们的比如围绕这五个方面，咱们一起来看一下。

定位慢调用一般来说有什么样的进程，或许说有什么样的最佳实践呢？我这儿总结的为三个方面：黄金信号 + 资源目标 + 大局架构。

咱们先来看一下黄金信号。首要，黄金信号是出自谷歌 SRE 圣经里边的 Site Reliability Engineering 一书。用来表征体系是否健康的最小目标的集合，这其间包含：

• 延时–用来描绘体系履行请求花费的时刻。常见目标包含均匀呼应时刻，P90/P95/P99 这些分位数，这些目标能够很好的表征这个体系对外呼应的快还是慢，是比较直观的。

• 流量–用来表征服务繁忙程度，典型的目标有 QPS、TPS。

• 过错–也便是咱们常见的类似于协议里 HTTP 协议里边的 500、400 这些，一般假如过错许多的话，阐明或许现已出现问题了。

• 饱满度–便是资源水位，一般来说挨近饱满的服务比较简单出现问题，比如说磁盘满了，导致日志没办法写入，然后导致服务呼应。典型的那些资源有 CPU、 内存、磁盘、行列长度、连接数等等。

除了黄金信号，咱们还需要重视一个资源目标。著名的功能剖析大神 Brandan Gregg ，在他的功能剖析办法论文章中说到一个 USE 办法。USE 办法是从资源角度进行剖析，它是对于每一个资源去检查 utilization（运用率），saturation （饱满度），error（过错） ，合起来便是 USE 了，检查这三项基本上能够解决 80% 的服务问题，而你只需要花费 5% 的时刻。

前面有了黄金信号、资源目标之后，咱们还需要重视什么？正如 Branda 在办法论里边说到的“咱们不能只见树木，不见森林”。诸葛亮也说过“不谋大局者，不足以谋一域”。咱们应该把体系架构画出来，从大局去看功能问题，而不只是看某个资源、某个服务。把一切东西进行归纳考虑，辨认出瓶颈地点，经过规划办法体系性解决问题，这也是一种更优的办法。所以，咱们需要黄金信号、资源目标以及大局架构这种组合。

慢调用最佳实践

接下来我会讲三个事例，第一个是节点 CPU 打满问题，这也是典型的资源问题导致的服务慢的问题，即服务自身的资源导致的问题。第二个是依靠的服务中间件慢调用的问题。第三个是网络功能差。第一个事例是判别服务自身有没有问题；第二个事例是判别下流服务的问题；第三个便是判别自身跟服务之间的网络功能问题。

咱们以一个电商使用举例。首要流量入口是阿里云 SLB，然后流量进入到微服务体系中，微服务里边咱们经过网关去接纳一切流量，然后网关会把流量打到对应的内部服务里边，比如说 ProductService、CartService、 PaymentService 这些。下面咱们依靠了一些中间件，比如说 Redis 、MySQL 等等，这整个架构咱们会运用阿里云的 ARMS 的 Kubernetes 监测产品往来不断监测整个架构。毛病注入方面，咱们会经过 chaosblade 去注入比如 CPU 打满、网络反常等不同类型的反常。

事例一：节点 CPU 打满问题

节点 CPU 打满会带来什么样的问题呢？节点 CPU 打满之后，上面的 Pod 或许没办法请求到更多 CPU，导致里边的线程都处于等候调度的状况，然后导致慢调用。除了节点上面，咱们这除了 CPU 之外，还有一些像磁盘、Memory 等等资源。

接下来咱们看一下 CPU 在 Kubernetes 的集群里边的一些特点。首要，CPU 是可压缩的资源，在 Kubernetes 里边咱们右边看这些装备，有几个常见装备，比如说 Requests，Requests 是首要是用来做调度的。Limits 是用往来不断做运行时的一个限制，超越这个 Limits，它就会被限流。所以，咱们的试验原理是说对节点这个 CPU 进行打满注入，导致 Pod 没办法请求到更多的内存，然后导致服务变慢。

在正式开始前，咱们经过拓扑图对要害链路进行辨认，在上面装备一些告警。比如说网关及支付链路，咱们会装备均匀呼应时刻 P90 以及慢调用等告警。然后装备完之后，我这边会注入一个节点 CPU 打满这么一个毛病。那这个节点选的是网关的节点，大约等候五分钟之后，咱们就能够收到告警，便是第二步里边的那个验证告警的有效性。

接下来咱们进入根因定位。首要，咱们进入到检查到网关的使用概况里边。第一步是检查相关黄金信号，黄金信号便是呼应时刻，咱们看到呼应时刻十分直观显现了突增，下面是慢调用数，慢调用数是有一千多个，慢调用数忽然增多了，P90/P95 出现了明显上升，并超越一秒，阐明整个服务也变慢了。

接下来，咱们需要剖析资源目标，在 Pod CPU 运用量图表中能够看到这段时刻 Pod 运用量上升很快，这个进程阐明需要向宿主机或许节点请求更多内存。咱们进一步看一下节点或许宿主机的 CPU 运用率是怎样样的，咱们看到这段时刻运用率挨近百分之百，Pod 请求不了更多 CPU，进一步导致服务慢了，然后导致均匀呼应时刻许多添加。

定位到问题之后，咱们能够想想详细解决方案。经过 CPU 运用率装备弹性弹性。由于咱们不知道相关流量或许资源，不知道什么时分忽然就不行。那么应对这种场景最好的办法便是给资源装备弹性弹性，为节点装备弹性弹性，首要是为了确保在负载上升时，资源能够动态扩容。为了给使用装备弹性弹性，咱们能够给比如 CPU 目标，装备一个添加副本数的一个扩容动作往来不断分担流量，这儿边咱们能够装备成最大副本数为十，最小副本数为三等等。

作用如下：注入 CPU 慢毛病时，慢调用会上升，上升完成之后会触发到弹性弹性，那便是 CPU 的运用率超越阈值了，如 70%。那么，它就会自动扩出一些副本去分担这些流量，咱们能够看到慢调用数逐步下降直到消失，阐明咱们的那个弹性弹性起到作用了。

事例二：依靠的服务中间件慢调用的问题

接下来咱们看第二个事例。首要介绍一下准备工作，左边这边图咱们能够看到网关进来掉了两个下流服务，一个是 MySQL ，一个是 ProductService，所以在网关上直接装备一个大于一秒的告警，均匀呼应时刻 P99 大于一秒的告警。第二步咱们看这个 Product 也是在要害链路上面，我给它配一个 P99 大于一秒的告警，第三个是 MySQL ，也配一个大于一秒的告警，配完之后，我会在 Product 这个服务上面去注入一个 MySQL 慢查询的毛病，大约比及两分钟之后，咱们就能够看到连续告警就触发出来了，网关跟 Product 上面都有一个红点跟一个灰色的点，这一点其实便是报出来的毛病，报出的告警事情，Kubernetes监测会把这个告警事情经过命名空间使用自动的 match 到这个节点上面，所以能够一眼的看出哪些服务、哪些使用是反常的，这样能够快速定位出问题地点。咱们现在收到告警了之后，下一步去进行一个根因定位。

首要说一下这个更新定位的流程，告警驱动由于预防总比补救要好，所以咱们是选用先装备告警，再去更新定位这么一个进程。然后咱们会用拓扑往来不断进行一个可视化剖析，由于拓扑是能够去进行架构感知、剖析上下流，能够进行可视化剖析。当收到告警后，能够针对告警看对应的一个使用发生了什么情况。第一个咱们看那个网关，咱们看到网关的那个 P99 上升到 1800 毫秒以上，所以触发了一个大于 1 秒阈值的这么一个告警。咱们能够也能够看到几个分位数都是上涨的，然后咱们进一步看别的一个发生告警的服务，也便是 Product，点开这个节点之后，咱们能够从那个 panel 上面看到这个 Product 也发生了一个慢调用，P99、P95 都现已不同程度的发生慢调用大都是大于一秒的，然后这时分咱们是能够去看一下 Product 的资源运用情况的，由于或许 Product 自身有问题。咱们检查 Product 的下流，一个是 Nacos，一个是 MySQL，咱们看 MySQL 的这个交互的时分就发现这儿边有许多的一个慢调用，然后看到这些慢调用之后，点击这些明细，去下钻看一下它调用的时分发生了什么事情，咱们进一步看这些数据之后，就会发现 SQL 里边 Product 调用 Mysql 的时分履行了一条很杂乱，Join 了多张表的一个 SQL 的句子。从调用 Trace 看到耗时十分大，这样的话咱们就能够定位到基本上是这条 SQL 发生的一个问题了。

总结一下咱们整个流程，首要咱们会经过架构感知去辨认要害的途径，然后在这个要害途径上去装备告警去自动发现反常。发现反常之后，咱们经过使用自身的资源目标黄金信号等往来不断定位问题。假如自身没有问题，那咱们就可往下追寻下流，咱们去看下流的资源目标，用这么一种办法去定位慢调用的一个依靠的问题，中间件调用的问题。

事例三：网络功能差

接下来咱们讲最终一个比如便是网络功能差，Kubernetes的网络架构是比较杂乱的，容器之间的通讯、Pod 之间的通讯、Pod 与服务之间通讯、外部与服务之间的通讯等等。所以杂乱度是比较高的，学习的曲线也比较峻峭，这给定位问题带来必定困难。那么，咱们怎样去应对这种情况呢？假如选用要害网络环境目标去发现网络反常，有哪些要害环境目标呢？首要一个是速率跟带宽，第二个是吞吐量，第三个是延时，第四个是 RTT。

首要我会这边装备一个告警，注入 MySQL 地点节点丢包率高这个毛病，等候几分钟之后，咱们会收到慢调用告警，网关跟 Product 的呼应时刻都发生了大于一秒的告警。接下来咱们看一下根因定位，咱们看到网关，发生了慢调用 P99 的呼应时刻暴增，然后看 Product 也发生了均匀呼应时刻突增的问题，那便是刚才的服务慢调用了，然后咱们进一步看 Product 的下流，依靠了 Nacos、Redis 、MySQL 这三个服务，能够发现慢调用是比较明显的，然后咱们检查它的下流时就发现了 Product 调 MySQL 的时分发生了比较严重的慢调用，一起它的 RTT 跟重传现象也很明显。

正常情况下 RTT 是很平稳的。它反映的是上下流之间的往复的时刻，假如它都上涨十分快，基本上能够认定为它是网络问题，所以说能够看到便是这儿边有三条，从网关、Product、MySQL，从这儿咱们能够总结到便是经过这种辨认要害途径，然后在拓扑上面去装备告警的这种办法能够十分快的去定位问题，不需要去查验许多散落在各个地方的信息。咱们只需要去在这条拓扑上面去树藤摸瓜的去检查对应的功能目标，网络目标等等，快速定位到问题地点。所以，这便是咱们黄金信号 + 资源目标 + 资源拓扑定位像慢调用这种反常的最佳实践。

最终总结下本次最佳实践：

1、经过默许告警自动发现反常，默许告警模板涵盖 RED，常见资源类型目标。除了默许下发的告警规矩，用户还能够根据模板定制化装备。

2、经过黄金信号和资源目标发现、定位反常，一起 Trace 配合下钻定位根因。

3、经过拓扑图做上下流剖析、依靠剖析、架构感知，有利于从大局视角审视架构，然后得到最优解，做到持续改进，构建更稳定的体系。

点击此处，检查更多可观测相关干货内容与产品实践～

本节课的内容到这儿就完毕了，欢迎咱们前往钉钉扫码或搜索钉钉群（31588365）参加答疑沟通群进行沟通。

近期热门

#HOT TOPIC #云原生加速器，为你而来#

就等你了！从速点击此处参与报名吧～