「直播回看」高清云网可观测之全链路追踪实战

“云原生可观测性分享会”第七期《高清云网可观测之全链路追踪实战》由云杉网络 高级产品经理 李倩分享,针对云网络的全链路追踪问题,用「实战」带领大家一步一步破解“网络谜案”。

点击此🔗「链接」观看视频回放。

大家好,我是云杉网络DeepFlow的产品经理李倩,今天给大家带来的分享主题是《高清云网可观测之全链路追踪实战》,我将从四个方面给大家分享内容,云网缺乏可观测性的现状,实现高清云网全链路追踪能力所需的必备要素,以及分享两个案例,并通过Demo环境演示来讲解如何解决实际问题。

云网缺乏可观测性现状1:应用团队视角

首先站在应用团队的视角出发,在缺乏云网可观测能力时会导致什么情况发生?某客户已经使用Skywalking完成了应用的分布式链路追踪,但还是存在吵得不可开交的场景,左边是客户端开发人员拿着日志数据找到服务端人员,理由是服务端时延高,但是服务端通过火焰图表示我们这里时延很低。这样的情景下,谁都不让步,谁都认为问题在对方那里。

右边是在数据库调用时,客户端看某查询语句慢,但数据库团队却没有看到慢日志记录,应用都没问题,到底问题在哪里?这是现状1,客户端没问题,服务端也没问题,问题在哪里?

云网缺乏可观测性现状2:监测工具匮乏

随着架构的迭代,服务的精细化,业务上线速度越来越快,各种监控数据总是滞后,没有足够的监控数据,就会导致工具不行最后人来凑的局面。截图来自一位常年坚持分享运维案例的大佬(微博账号:plantegg)。

在进行徒手抓包的过程,经常需要多部门配合,联系人开权限、联系人下载包,由于云网络的架构复杂,甚至连虚拟网卡名称都会经常变化,还需要联系人确认抓包位置等等,都是非常依赖人的事情,并且还可能发生拿到包后,发现少抓了一部分包,结果还得从头再来这样的情况。这就是现状2,网络监测工具缺乏,堆人抓包定位问题,但是效率如何保障呢?

云网缺乏可观测性现状3:网络团队视角

从网络团队视角来观察,在缺乏云网可观测能力时又会发生什么情况?很多传统行业的客户都在进行数字化转型,而上云是加速数字化及企业架构转型的有效途经,越来越多的传统企业开始上云,但是上云并不意味着能快速懂云,对于徘徊在云外围的运维人员来说,保障云网的稳定运行是一个大难题。

对运维来说最熟悉的方式就是抓包,为了可回溯,基本就是直接抓取原始包全量存储。但在云网的场景下,抓包点多,数据量大、检索困难,为保障云网付出了大量的人力和物理资源,但依旧不能让应用部门满意,因为只能被动响应,最后只能深度依赖云厂商来定位问题。这就是目前的现状3 ,运维人员徘徊在云的外网,只能全包存储,但是磁盘资源消耗巨大,查询又困难,如何破解?

云网缺乏可观测性现状4:各种隧道/层层NAT

现在云网的流量都是通过各种隧道协议来传输,不停的拆隧道、封隧道,穿过各种虚拟交换机和NFV网关,将流量内层/外层流量NAT个遍,最终到目的端时,流量已面目全非?

我们某个客户,数据库运维经常发现某几个IP造成了数据库的压力,可是找到IP并没有用,他们的数据库是部署的云下,云上的各种环境都可以访问,经过各种隧道、网关NAT后,根本找不到IP到底对应哪个应用。这就是现状4, 各种隧道/层层NAT,流量迷失,如何追踪?

高清云网络全链路追踪能力

以上分析了云网络缺乏可观测性时,普遍发生的各式各样的“事故现场”,接下来看看如何通过高清云网络全链路追踪能力来避开这些大坑。

云杉网络DeepFlow产品通过不断演化并在客户处不停实践后,沉淀了一张云网全链路追踪的必备要素图,由3大部分组成。一个核心部分是产品功能,这些功能是从全局视角出发,通过一路追踪到网络路径,追踪到NAT前后,追踪到流,追踪到包头,最后追踪到Payload,一步步高清放大的过程。

底座部分是自动标签能力,在云环境里面,IP的动态性非常高,不能再像传统网络那样,追踪到IP就代表解决问题了,必须将IP与云资源关联起来,才能真正与应用团队对上话。

右边是贯穿所有功能的一个基础能力,黄金指标,即所有的功能都会配有指标,通过指标来加快追踪的效率。

全景流量拓扑

接下来从全景流量拓扑功能开启本次高清云网络全链路追踪之路的第一站。全景流量拓扑功能以业务零侵扰的方式,提供全局视野观测应用调用关系拓扑图,拓扑图结合黄金指标可快速追踪服务及服务的路径。对于应用层的黄金指标,Google已经做了权威的定义,但是对于云网络层面的黄金指标,至今还没有权威机构给出过定义。

云杉网络基于多年在云网络可观测的深耕,总结了一套云网络的黄金指标,包含流量大小、重传比例、建连失败比例、建连时延、数据传输时延,用这套黄金指标能快速发现网络问题。除了黄金指标外,还提供从网络层到应用层的吞吐、性能、异常、各种时延,各种资源属性等指标量。

全景流量拓扑:追踪应用路径

全景流量拓扑中圆圈大小/线条粗细,代表指标量的大小,值越大圆圈越大,线条也越粗;而红色则表示超过了指标量的阈值,提示此路径和服务需要被重点关注了。基于这个背景,第一步我们就可以结合圆圈大小和阈值颜色追踪到应用中某个有“问题”的服务。

第二步高亮追踪到的服务,就能将其关联的路径都高亮,此时可分析追踪的路径中,是否存在不符合预期的访问出现,或者应该存在的访问路径缺失。对于不符合预期的访问从哪里来?缺失的访问路径是什么?则需要去定位为什么没发起访问了。

第三步对上下游的路径进行追踪,先追踪服务的上游路径,结合指标量发现被Loadgenerator服务访问时,存在大量的重传情况。

接下来追踪服务下游路径,看看是不是下游服务重传影响了上游的重传,发现下游product服务重传比例比较高,到此通过全景流量拓扑已追踪到了具体的服务路径。

全栈路径追踪

接下来通过全栈路径追踪继续追踪服务路径对应的网络路径是否存在问题。全栈路径追踪通过对虚拟网络与物理网络的各个节点进行流量追踪。

全栈代表着虚拟网络,物理网络的各个节点都可以进行追踪,包含虚拟网络中客户端与服务的POD、容器节点、宿主机、各种NFV网关,以及物理网络中的各种支持设备。右边的图对应了云杉网络两个产品的界面图,上面是虚拟网络追踪图,下面是物理网络追踪图。

全栈路径追踪:丢包追踪

通过对比各个节点上的流量大小来追踪丢包的问题,通过对比数据可知,客户端容器节点与服务端容器节点接收到的流量大小不一样,图上标记为①;服务端容器节点与服务端的流量大小也不一样,图上标记为②,则可知①②的位置应该都存在丢包,因为①的位置中间还对应物理网络,继续对物理网络进行追踪。

对比物理网络节点的流量大小,与客户端容器节点不一样,但是与服务端容器节点一样,则可知是在客户端容器节点到物理网络北京办公室交换机这条路径上存在丢包,最终锁定为 ③和②路径存在丢包,对于具体是什么包丢了,后面还会继续追踪,在此之前先来看看如何用全栈路径追踪功能,追踪时延瓶颈问题。

全栈路径追踪:时延瓶颈追踪

追踪时延瓶颈问题时,可以结合时延指标量,一般不会直接用建连时延,可使用建连服务端时延指标量。时延数据组成比较简单,右边有一个图说明了syn报文与syn+ack报文之间的时延为建连服务端时延,可查看拓扑图,拓扑图上的数据表达的是每个网络路径上的时延,可知客户端容器节点与服务端容器节点,也就是位置①上是时延瓶颈点。

智能NAT追踪

前面的全景流量拓扑及路径追踪,都只能追踪到未发生NAT的流量,但云环境里面NAT才是常态,而且还是各种隧道内外层NAT、各种网关NAT,因此想一条流追踪到问题根源非常困难,此时就必须使用智能NAT追踪这个功能了。

智能NAT追踪功能是通过DeepFlow自研算法来追踪NAT前后流量,并将流量流经的网络路径节点都追踪出来,这个算法可追踪各种NAT场景的流量。比如SNAT、DNAT、 端口NAT、隧道内外层NAT。

如上图所示通过一个TCP四元组或者五元组来发起追踪,右边的拓扑图是通过NAT前的流量,追踪的NAT后的拓扑,可看到仅通过客户端访问LB的VIP,追踪出来后端的服务端。左边是追踪出来的虚拟网络节点,可看到从客户端穿过宿主机进出NFV网关,一直到对端的的宿主机服务端。

智能NAT追踪:位置追踪

除了流量追踪以外,智能NAT追踪还能追踪NAT发生的位置,可通过高亮NAT前后的流量,找到对应流量穿过的网络节点。高亮NAT前的流量,看到流量进入NFV网关后,这股流就没了。再追踪NAT后的流量,是从出NFV网关开始的,因此可知在NFV网关上发生的DNAT,从图上还可知,追踪的某个后端的流量,仅经过了NFV网关的2/3/4号网关,并没有过1号,追踪到这个位置,即使要抓包也不用全网关集群去开启抓包,就可以定向抓包了。

除了位置外,TIP还提供追踪出来的位置的详细信息,比如采集位置、采集网卡、隧道信息,同时都包含指标量。结合指标量还可以做更多的追踪,这里就不展开说了,对于指标的使用,前面两个功能都已经说明了。

全网流日志

完成各种路径追踪后,可以通过全网流日志功能来实现追踪路径的流。全网流日志功能,是按分钟粒度记录每一条流的详细信息,以表格的形式来展示。

记录流从链路层到应用层的详细信息,MAC、IP、隧道、端口、TCP的标志等各种信息。

以及通过自动标签能力打的各种云平台标签,包含K8s的各种Label。还会记录采集流相关的信息,比如采集位置、采集网卡、流开始时间、结束时间等等。每条流也都会记录对应的指标量。

全网流日志:追踪时延高的流

在需要追踪时延高的流量时,仅需对时延指标量按从大到小进行排序即可,前面的即为时延高的流。

全网流日志:追踪长链接的流

追踪长链接的流,可对流持续时间,按长链接定义的时间进行过滤,过滤后的流量都为长链接的流。

全网流日志:追踪异常的流

对于异常的流的追踪,每条路径都会记录一个状态,只需要过滤状态为异常的流即可。

全包时序图

接着来说如何对一条流中的包进行追踪?可使用全包时序图功能来完成。时序图,记录的是一条TCP流的每个包的详细信息,通过时序图可以追踪包头的Flag、Seq、Ack、Payload长度、Option字段,也可以根据包的间隔时间来进行追踪,如果还需要对Payload进行追踪,也支持将流对应的Pcap文件下载下来,通过Wireshark继续追踪。

实战案例1:精准定位K8s网络问题引发的应用故障

接下来将为大家分享两个案例,以便更好的理解云网可观测性是如何产生实际价值的,先来看第一个案例,精准定位K8s网络问题引发的应用故障,是应用团队反馈,在集群内部访问某个容器服务响应时延高的问题。

请点击此🔗「链接」观看视频

实战案例2:精准定位NFV云网关性能瓶颈引发的应用故障

第二个案例来自应用团队的反馈,访问某数据库总是出现连接不上的情况。第一步:查看某数据库的访问路径,结合黄金指标发现存在多个建连失败的情况,选择其中一条路径的流量进行追踪,看看到底是什么问题。

第二步:进行网络路径追踪,发现只能追踪到NFV网关,可以肯定是存在NAT场景,继续使用智能NAT追踪来定位问题。

第三步:使用智能NAT追踪后,查看右边的流量拓扑可知,追踪出来两条流量存在两次SNAT,一次内部的SNAT,使用内部的NAT_IP;一次外部SNAT,使用了外部的NAT_IP,对比指标数据发现,内部NAT存在丢包问题,需要进一步追踪到底是什么流量存在丢包。

第四步:通过高亮观察,丢包的内部网关是在完成SNAT为169网段的IP时,发生了丢包。结合进一步的指标信息发现,内部NAT为非对称的NAT,仅发送数据包存在丢包情况,拿到此信息后,结合流日志来进一步分析是什么流量发生了丢包。

第五步:查看进出内部NAT网关的流日志,追踪建连失败的流日志,发现仅存在进NAT网关的流,出NAT网关的流不存在,结合时序图功能,查看建连失败的时序图,发现仅一个SYN报文,到此基本已经有结论了。

是客户端对数据库发起请求时,在内部NAT网关,即2号网关上丢了部分SYN报文,导致了访问数据库失败的情况。今天的分享到此结束,谢谢大家的观看。

Related Posts

云杉网络 DeepFlow 联合 TDSQL 完成技术兼容互认证

近日,北京云杉世纪网络科技有限公司(以下简称:云杉网络)的云原生可观测性产品 DeepFlow&nb […]

Read More

浅谈云原生可观测性生态的优化和丰富

云杉 世纪

2024年4月5日

云杉动态

云原生可观测数据中的时序数据 Metrics,在业务高基数、持久化存储、乱序写入、多租户隔离等场景下,对后端时 […]

Read More