如何发现 Kubernetes 中服务和工作负载的异常
大家好,我是来自阿里云的李煌东,今天由我为大家分享 Kubernetes 监控公开课的第二节内容:如何发现 Kubernetes 中服务和工作负载的异常。本次分享由三个部分组成:一、Kubernetes 异常定位存在痛点;二、针对这些痛点,Kubernetes 监控如何更快、更准、更全的发现异常;三、网络性能监控、中间件监控等典型案例解析。
1
Kubernetes 异常定位存在痛点
首先应用层基于微服务,微服务由解耦开的几个服务相互调用构成,服务一般职责分明、边界明确,造成的结果是一个简单的产品也有几十、甚至上百个微服务,相互之间的依赖、调用是非常复杂的,这给定位问题带来比较大的成本。同时,每个服务的 owner 可能来自不同团队,不同的开发,可能使用不同的语言,对我们监控的影响是对每一种语言都需要进行监控工具的接入,投资回报率低。还有一个特点是多协议,几乎每种中间件(Redis、MySQL、Kafka)都有他们独特的协议,怎么要做到快速对这些协议进行观测,是不小的挑战。
虽然 Kubernetes 和容器对上层应用屏蔽了底层的复杂度,但是带来的两个结果是:基础设施层越来越高;另一个是上层应用和基础设施之间信息变得越来越复杂了。举个例子,用户反馈网站访问很慢,管理员查看访问日志、服务状态、资源水位发现都没问题,这时候不知道问题出现在哪里,虽然怀疑基础设施有问题,但无法定界的情况下只能一个一个排查效率低,问题的根源就是上层应用和基础设施之间缺少上下问题关联,无法做到端到端串联。
最后一个痛点是数据散、工具多、信息没打通。举个例子,假设我们收到一个告警,用 grafana 去查看指标,指标只能描述的比较粗略,我们得去看下日志,这时候我们要去 SLS 日志服务看下有没有对应的日志,日志也没问题,这时候我们需要登录到机器上去看,然而登录到容器里面可能又因为重启导致日志没有了。查了一波之后,可能我们会觉得可能问题不是出现在这个应用,于是我们又去看链路追踪是不是下游有问题。总而言之,工具用了一大堆,浏览器开了十几个窗口,效率低、体验差。
2
Kubernetes 监控如何发现异常
再上一层是事件,事件直接明确地告诉我们发生了什么,可能我们遇到最多的是 Pod 重启、拉镜像失败等。我们对 Kubernetes 事件进行了持久化存储,并保存一段时间,这样方便定位问题。然后,我们的巡检和健康检查也是支持以事件的形式报出来。
3
最佳实践&场景分析
发送方发送编号为 1 的包,接收方接受了,返回 ACK 2
发送方发送编号为 2 的包,接收方返回 ACK 2
发送方发送编号为 3、4、5 的包,接收方都返回 ACK 2
直到发送方收到 3 次同样的 ACK ,就会触发重传机制,重传会导致延迟升高
调用外部 API 网关
调用云服务,云服务一般是公网的
调用外部中间件
配置问题(ndots 问题),ndots 是个数字,表示域名中点的个数要是小于 ndots,那么搜索就优先走 search 列表中的域去查找,这样的话会产生多次查询,对性能的影响还是挺大的。
由于 Kubernetes 所有的域名解析都走 CoreDNS,非常容易成为性能瓶颈,有人统计过大概 qps 在 5000~8000 的时候就要关注性能问题了。尤其是依赖外部 Redis、MySQL 这种访问量比较大的。
低版本的 CoreDNS 有稳定性问题,这个也是需要关注的点。
有些语言,想 PHP 对连接池支持的不是很好,导致每次都要去解析 DNS,创建连接,这个现象也是比较常见的。
首先是慢查询,慢查询提现为延时指标高,这时候去看 trace 里面详情请求是啥,查询的是哪张表,哪些字段,进而看下是不是查询量太大了、表太大了、还是说没有建索引等。
查询语句过大,我们知道查询语句太大会导致传输耗时高,网络稍一抖动就造成失败重试,还会引发带宽占用的问题。一般都是一些批量的更新、插入导致的,出现这种问题延时指标会飙高,这时候我们可以选择RT较高的一些 Trace 来看,看下语句怎么写的、看下查询语句的长度是不是太大了。
错误码返回,比如表不存在这种,那么解析出其中的错误码就很有帮助了,再进一步看里面的详情,去看语句,就比较容易定位出根因了。
网络问题,这个点也讲过比较多了,一般配合着延时指标加上 RTT、重传、丢包来确定网络是否有问题。
网络监控:如何能分析网络导致的服务的错慢、中断,如何分析网络问题带来的影响
服务监控:如何通过黄金指标确定服务是否健康?如何通过支持多协议的 Trace 查看详情?
中间件、基础设施监控:如何用黄金指标、trace 分析中间件、基础设施的异常,如何快速定界是网络问题,还是自身问题,还是下游服务问题
架构感知:如何通过拓扑感知整个架构,梳理上下游、内部外部依赖,进而能掌控全局?如何通过拓扑保障架构有足够的观测性、稳定性保障,如何通过拓扑分析、发现系统中的瓶颈、爆炸半径。
4
产品价值
通过多协议、多语言、无入侵的方式采集服务的指标和 Trace 数据,最大限度地减少接入的成本,同时提供覆盖度全面的指标和Trace;
有了这些指标和 Trace 之后我们就能,对服务和工作负载进行科学的分析、下钻;
将这些指标、Trace 关联起来串成一张拓扑图,能在一张大图上进行架构感知、上下游分析、上下文关联等,充分得理解架构,评估潜在的性能瓶颈等,方便做进一步的架构优化;
提供配置简单的告警配置方法,将经验知识沉淀到告警中,做到主动发现。