alisystemsoftware

大家好,我是来自阿里云的李煌东,今天由我为大家分享 Kubernetes 监控公开课的第二节内容:如何发现 Kubernetes 中服务和工作负载的异常。

本次分享由三个部分组成:

一、Kubernetes 异常定位存在痛点;

二、针对这些痛点,Kubernetes 监控如何更快、更准、更全的发现异常;

三、网络性能监控、中间件监控等典型案例解析。

Kubernetes 异常定位存在痛点

当下的互联网架构中,越来越多的公司采用微服务 + Kubernetes 这样的架构,这样的架构有如下特点:

  1. 首先应用层基于微服务,微服务由解耦开的几个服务相互调用构成,服务一般职责分明、边界明确,造成的结果是一个简单的产品也有几十、甚至上百个微服务,相互之间的依赖、调用是非常复杂的,这给定位问题带来比较大的成本。同时,每个服务的 owner 可能来自不同团队,不同的开发,可能使用不同的语言,对我们监控的影响是对每一种语言都需要进行监控工具的接入,投资回报率低。还有一个特点是多协议,几乎每种中间件(Redis、MySQL、Kafka)都有他们独特的协议,怎么要做到快速对这些协议进行观测,是不小的挑战。
  2. 虽然 Kubernetes 和容器对上层应用屏蔽了底层的复杂度,但是带来的两个结果是:基础设施层越来越高;另一个是上层应用和基础设施之间信息变得越来越复杂了。举个例子,用户反馈网站访问很慢,管理员查看访问日志、服务状态、资源水位发现都没问题,这时候不知道问题出现在哪里,虽然怀疑基础设施有问题,但无法定界的情况下只能一个一个排查效率低,问题的根源就是上层应用和基础设施之间缺少上下问题关联,无法做到端到端串联。
  3. 最后一个痛点是数据散、工具多、信息没打通。举个例子,假设我们收到一个告警,用 grafana 去查看指标,指标只能描述的比较粗略,我们得去看下日志,这时候我们要去 SLS 日志服务看下有没有对应的日志,日志也没问题,这时候我们需要登录到机器上去看,然而登录到容器里面可能又因为重启导致日志没有了。查了一波之后,可能我们会觉得可能问题不是出现在这个应用,于是我们又去看链路追踪是不是下游有问题。总而言之,工具用了一大堆,浏览器开了十几个窗口,效率低、体验差。

这三个痛点分别归纳为成本、效率、体验三个方面。针对这些痛点,接下来我们一起看下 Kubernetes 监控的数据体系,看下怎么来更好的解决成本、效率、体验三大问题。

Kubernetes 监控如何发现异常

下图金子塔自顶向下表示信息的密度或者详细程度,越往下面信息越详细。我们从底部开始讲,Trace 是我们通过eBPF技术以无入侵、多协议、多语言的方式采集应用层协议数据,如 HTTP、MySQL、Redis,协议数据会进一步解析成容易理解的请求详情、响应详情、各个阶段的耗时信息。

图片 1.png

再上一层是指标,指标主要由黄金指标、网络、Kubernetes 体系中的指标。其中黄金指标和网络指标是基于 eBPF 采集的,所以同样他们是没有入侵的,支持各种协议的,有了黄金指标,我们就能知道服务整体上是否有异常、是否有慢、是否影响用户;网络指标主要是对socket的支持,如丢包率、重传率、RTT 等,主要用来监控网络是否正常的指标。Kubernetes 体系中的指标是指原来 Kubernetes 监控体系中的 cAdvisor/MetricServer/Node Exporter/NPD 这些指标。

再上一层是事件,事件直接明确地告诉我们发生了什么,可能我们遇到最多的是 Pod 重启、拉镜像失败等。我们对 Kubernetes 事件进行了持久化存储,并保存一段时间,这样方便定位问题。然后,我们的巡检和健康检查也是支持以事件的形式报出来。

最顶层是告警,告警是监控系统的最后一环,当我们发现某些特定异常可能对业务有损后,我们就需要对指标、事件进行告警配置。告警目前支持 PromQL,智能告警支持对历史数据进行智能算法检测,从而发现潜在的异常事件。告警的配置支持动态阈值,通过调节灵敏度的方式来配置告警,从而避免写死阈值。

有了 Trace、指标、事件、告警之后,我们用拓扑图将这些数据和 Kubernetes 实体都关联起来,每个节点对应 Kubernetes 实体中的服务和工作负载,服务之间调用用线表示。有了拓扑图,我们就像拿到一张地图,能快速识别拓扑图中的异常,并对异常进行进一步的分析,对上下游、依赖、影响面进行分析,从而对系统有了更全面的掌控。

最佳实践&场景分析

接下来我们讲下发现 Kubernetes 中服务和工作负载的异常的最佳实践。

首先还是先有指标,指标能反应服务的监控状态,我们应尽可能地收集各种指标,并且越全越好,不限于黄金指标、USE 指标、Kubernetes 原生指标等;然后,指标是宏观数据,需要做根因分析我们得有 Trace 数据,多语言、多协议的情况下要考虑采集这些 Trace 的成本,同样尽可能地支持多一点协议、多一点语言;最后,用一张拓扑将指标、Trace、事件汇总起来、串联起来,形成一张拓扑图,用来做架构感知分析、上下游分析。

图片 2.png

通过这三种方法的分析,服务和工作负载的异常通常暴露无遗了,但我们不应该就此停止前进的脚步,加入这个异常下次再来,那么我们这些工作得重来一遍,最好的办法是针对这类异常配置对应的告警,自动化地管理起来。

我们用几个具体的场景来详细介绍:

(一)网络性能监控

网络性能监控以重传为例,重传的意思是说发送方认为发生了丢包现象,就重发这些数据包。以图中的传输过程为例:

图片 3.png

  1. 发送方发送编号为 1 的包,接收方接受了,返回 ACK 2
  2. 发送方发送编号为 2 的包,接收方返回 ACK 2
  3. 发送方发送编号为 3、4、5 的包,接收方都返回 ACK 2
  4. 直到发送方收到 3 次同样的 ACK ,就会触发重传机制,重传会导致延迟升高

代码和日志是观察不出来的,这种情形下最终很难找到根因。为了能快速定位这个问题,我们需要一组网络性能指标来提供定位依据,包含以下指标,P50、P95、P99 指标来表示延时,然后我们需要流量、重传、RTT、丢包这些指标来表征网络情况。

以某个服务 RT 高为例:首先我们看到拓扑的边是红的,红的判断逻辑是根据延时、错误来判断的,当发现这个红边的时候,点击上面的边,就可以看对应的黄金指标了。

图片 4.png

点击底部最左边这个按钮,可以查看当前服务的网络数据列表,我们可以按平均响应时间、重传、RTT 排下序,可以看到第一个服务调用延时比较高,快到一秒的返回时间,同时也看到重传比较高,相比于其他服务高很多。这里其实是通过工具去注入了重传高这么一个故障,看起来更明显一些。这样分析下来我们就知道可能是网络的问题,就可以进一步排查了。有经验的开发一般会拿着网络指标、服务名、ip、域名这些信息去找网络的同事排查,而不是只是告诉对方说我服务很慢,这样对方知道的信息太少,就不会积极去排查,因为别人也不知道从哪里开始,当我们提供了相关数据,对方就有了参考,会顺藤摸瓜进一步推进。

(二)DNS 解析异常

第二个场景是 DNS 解析异常。DNS 通常是协议通信的第一步,比如 HTTP 请求,第一步就是先拿到 IP,也就是我们平常说的服务发现过程,第一步出现问题,整个调用就直接失败了,这就是所谓关键路径不能掉链子。在 Kubernetes 集群中所有的 DNS 都走 CoreDNS 的解析,所以 CoreDNS 上容易出现瓶颈,一旦出现问题,影响面也是非常大的,可能整个集群都不可用了。举个两个月前发生的鲜活的例子,著名的 CDN 公司 Akamai 就发生了一个 DNS 故障,导致众多网站像 Airbnb 网站无法访问,事故持续了长达一个小时。

在 Kubernetes 集群中 DNS 解析比较核心的几个场景有三个:

  1. 调用外部 API 网关
  2. 调用云服务,云服务一般是公网的
  3. 调用外部中间件

图片 5.png

这里对 CoreDNS 常见的问题进行了归纳,大家可以参考下,排查下自己的集群上有没有类似问题:

  1. 配置问题(ndots 问题),ndots 是个数字,表示域名中点的个数要是小于 ndots,那么搜索就优先走 search 列表中的域去查找,这样的话会产生多次查询,对性能的影响还是挺大的。
  2. 由于 Kubernetes 所有的域名解析都走 CoreDNS,非常容易成为性能瓶颈,有人统计过大概 qps 在 5000~8000 的时候就要关注性能问题了。尤其是依赖外部 Redis、MySQL 这种访问量比较大的。
  3. 低版本的 CoreDNS 有稳定性问题,这个也是需要关注的点。
  4. 有些语言,想 PHP 对连接池支持的不是很好,导致每次都要去解析 DNS,创建连接,这个现象也是比较常见的。

接下来,我们看下 Kubernetes CoreDNS 中可能会发生问题的地方,首先应用和 CoreDNS 之间的网络可能有问题;第二是 CoreDNS 本身问题,比如 CoreDNS 返回 SERVFAIL、REFUSE 这些错误码,甚至因为 Corefile 配置错了,导致返回值是错的;第三点是跟外部 DNS 通信的时候,发生网络中断、性能问题;最后一个是外部 DNS 不可用。

针对这些问题点总结出以下步骤来盘查:

第一、从客户端侧,先看下请求内容和返回码,如果是返回是错误码说明是服务端有问题。如果是慢解析,可以看下时间瀑布流看下时间耗费在哪个阶段。
第二、看网络是否正常,看流量、重传、丢包、RTT 这几个指标就够了。
第三、查看服务端,看下流量、错误、延时、饱和度这几个指标,再看下 CPU、内存、磁盘等这几个资源指标,也能定位出是否有问题。
第四、看下外部 DNS,同理我们可以通过请求 Trace、返回码、网路流量、重传等指标来定位。

图片 6.png

接下来我们看下拓扑。首先看到红色的线表示有异常的 DNS 解析调用,点击这个我们能看到调用的黄金指标;点击查看列表,弹出详情页面,可查看请求的详情,是请求这个域名,请求过程中经历发送、等待、下载三个过程,看起来指标正常,接下来我们点击看响应,发现响应是域名不存在。那么这时候我们可以进一步看下外部 DNS 是否有问题,步骤也是一样的,后面我会在 demo 中展示,所以这里就不展开先了。

(三)全链路压测

第三个典型场景是全链路压测,对于大促这种场景峰值是平常的数倍,怎么保障大促的稳定,需要通过一系列的压测来验证系统能力、系统稳定性评估、做容量规划、识别系统瓶颈。一般会有这么几个步骤:先预热下,这时候验证下链路是否正常的,逐步加流量直到峰值,然后开始摸高,也就是看下能支持的最大 TPS 是多少,接着再加流量,这时候主要就是看服务是否能正常限流了,因为已经找过最大 TPS 了,再加大力量就是破坏性流量了。那么在这个过程中,我们需要关注哪些点呢?

首先针对我们多语言、多协议的微服务架构,比如这里的 Java、Golang、Python 应用,这里有 RPC、MySQL、Redis、Kafka 应用层协议,我们得有各种语言、各种协议的黄金指标,用来验证系统能力;针对系统的瓶颈、容量规划这块,我们需要 use 指标,去看各种流量级别情况下资源的饱和度,来确定是不是要扩容,每增加一次流量,对应看下 use 指标,对应调整容量,逐步优化;对于复杂架构,需要有一张全局的大图来帮助梳理上下游依赖、全链路架构,确定爆炸报警,比如这里的 CheckoutService 就是个关键的服务,这个点如果出现问题,影响面会很大。

图片 7.png

第一、各种语言、协议通信的黄金指标,通过查看列表进一步看调用的详情
第二、点击节点详情下钻查看 cpu、memory 等 use 资源指标
第三、整个拓扑图是能反映整个架构的形态的,有了全局的架构视角,就能识别哪个服务容易成为瓶颈、爆炸半径有多大,是否需要做高可用保障。

(四)访问外部 MySQL

第四个场景是访问外部 MySQL,先看下访问外部 MySQL 有哪些常见的问题:

图片 8.png

  1. 首先是慢查询,慢查询提现为延时指标高,这时候去看 trace 里面详情请求是啥,查询的是哪张表,哪些字段,进而看下是不是查询量太大了、表太大了、还是说没有建索引等。
  2. 查询语句过大,我们知道查询语句太大会导致传输耗时高,网络稍一抖动就造成失败重试,还会引发带宽占用的问题。一般都是一些批量的更新、插入导致的,出现这种问题延时指标会飙高,这时候我们可以选择RT较高的一些 Trace 来看,看下语句怎么写的、看下查询语句的长度是不是太大了。
  3. 错误码返回,比如表不存在这种,那么解析出其中的错误码就很有帮助了,再进一步看里面的详情,去看语句,就比较容易定位出根因了。
  4. 网络问题,这个点也讲过比较多了,一般配合着延时指标加上 RTT、重传、丢包来确定网络是否有问题。

图片 9.png

接下来看下拓扑图,中间框住的应用依赖了外部的 MySQL 服务,点击拓扑线可以进一步看黄金指标,点击查看列表可以进一步看请求的详情、响应等。同时我们也可以看下网络性能指标,这个 table 是将当前拓扑中的网络数据根据来源和目标进行归类,可以分别查看请求数、错误数、平均响应时间、socket 重传、socket rtt,点击上面箭头可以对应地排序。

(五)多租户架构

第五个典型案例是多租户架构。多租户指的是不同的租户、工作负载、不同团队,公用一个集群,通常一个租户对应一个命名空间,同时保证资源的逻辑隔离或者物理隔离,互不影响、互不干扰。常见的场景有:企业内部用户,一个团队对应一个租户,同一个命名空间内网络不受限制,用网络策略去控制不同命名空间之间的网络流量。第二种是 SaaS 提供商多租户架构,每个用户对应一个命名空间,同时租户和平台分别处于不同的命名空间。虽然 Kubernetes 的命名空间特性给多租户架构带来了便利,但也给可观测带来两个挑战:第一命名空间非常多,查找信息变得很繁琐,增加了管理成本、理解成本。第二是租户之间有流量隔离的要求,在命名空间比较多的情况下往往无法做到准确、全面的发现异常流量。第三是对多协议、多语言的 Trace 支持。曾经遇到过一个客户,一个集群里面有 400 多个命名空间,管理起来非常痛苦,而且应用是多协议、多语言的,要支持 Trace,得一个个改造。

图片 10.png

这是我们产品的集群首页,Kubernetes 的实体以命名空间的方式划分,支持查询来定位到我想看的集群。气泡图上展示对应命名空间上的实体数,以及有异常的实体数,比如框子里 3 个命名空间里存在有异常的 pod,点进去可以进一步看异常。首页下面是按黄金指标排序的性能概览,也就是场景的 Top 功能,这样能快速查看哪几个命名空间是有异常的。

图片 11.png

在拓扑图中,如果命名空间比较多,可以通过过滤功能查看想看的命名空间,或者通过搜索方式快速定位到想看的命名空间。由于节点是以命名空间分组的,能通过命名空间之间的线来查看命名空间的流量,这样就能方便地查看有来自哪些命名空间的流量、是否有异常流量等等。

图片 12.png

我们将上述场景介绍总结如下:

图片 13.png

  1. 网络监控:如何能分析网络导致的服务的错慢、中断,如何分析网络问题带来的影响
  2. 服务监控:如何通过黄金指标确定服务是否健康?如何通过支持多协议的 Trace 查看详情?
  3. 中间件、基础设施监控:如何用黄金指标、trace 分析中间件、基础设施的异常,如何快速定界是网络问题,还是自身问题,还是下游服务问题
  4. 架构感知:如何通过拓扑感知整个架构,梳理上下游、内部外部依赖,进而能掌控全局?如何通过拓扑保障架构有足够的观测性、稳定性保障,如何通过拓扑分析、发现系统中的瓶颈、爆炸半径。

从这几个场景中又进一步列举常见的 case:网络、服务的可用性检测,健康检查;中间件架构升级可观测性保障;新业务上线验证;服务性能优化;中间件性能监控;方案选型;全链路压测等。

产品价值

经过以上内容介绍,我们将 Kubernetes 的产品价值总结如下:

图片 14.png

  1. 通过多协议、多语言、无入侵的方式采集服务的指标和 Trace 数据,最大限度地减少接入的成本,同时提供覆盖度全面的指标和Trace;
  2. 有了这些指标和 Trace 之后我们就能,对服务和工作负载进行科学的分析、下钻;
  3. 将这些指标、Trace 关联起来串成一张拓扑图,能在一张大图上进行架构感知、上下游分析、上下文关联等,充分得理解架构,评估潜在的性能瓶颈等,方便做进一步的架构优化;
  4. 提供配置简单的告警配置方法,将经验知识沉淀到告警中,做到主动发现。

本节课的内容到这里就结束了,欢迎大家前往钉钉搜索群号(31588365)加入答疑交流群进行交流。

目前 Kubernetes 监控已经全面免费公测,点击下方链接,立即开启试用!
https://www.aliyun.com/activity/middleware/container-monitoring?spm=5176.20960838.0.0.42b6305eAqJy2n

相关文章: