共计 5240 个字符,预计需要花费 14 分钟才能阅读完成。
作者:李煌东
大家好,我是阿里云的李煌东。明天我为大家分享 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 # 云原生加速器,为你而来 #
就等你了!赶快点击此处参加报名吧~