全流量分析发现问题解决问题案例

一、网络关键路径性能传导视图

在NetInside可观测性模块中，我们基于k8s集群的业务逻辑结构，自定义的建立了以用户体验为中心的网络性能模型，如下图：

在这个流量模型中，浅绿色为体验传递与消减情况，因为用户的一个服务请求，在内部有多个处理逻辑，前一个逻辑的体验时间，依赖后一个逻辑的处理时间，所以其体验时间，会在多个处理逻辑进行传导，我们称之为性能传导视图，浅蓝色部分为处理逻辑向外请求的数据，浅红色则为处理逻辑中影响性能的关键指标。

二、发现问题

视图构建完成之后，竟然出现了橙色体验告警色块，这与我们的想象中的预期不符。在此之前，k8s集群一直是稳定运行，服务器接入也是全千M，基于我们对比业务和流量的了解，纯千的接入完全够用，且传统意义上的监控，也没有出现任何异常，所以出现个近40MS的服务器响应延迟，让我们有点惊讶。

继续看视图，我们发现这个橙色体验告警色块到数据库集时就没有了，可以初步判断问题的关键在于k8s集群。而k8s存在SDN网络，所以是SDN网络问题，还是物理网络问题，我们得区分出来，所以我们把k8s物理网络的性能指标也构建出来做为比较，结果问题还是指向k8s的SDN网络上，结合k8s集群SDN网络里面的关键性能指标，发现TCP的连接失败率还挺高的，由此其实已经可以判断，问题点，应该还是在k8s集群里面。

基于现有分析，我们决定先解决连接失败问题，因为这个问题与响应延迟是同一类型的问题，只是问题表现的程度不同。但面对这个问题的时候，让我们不得不面对一个让我们有点无语的问题。我们知道，TCP连接的建立是由linux内核完成的，而无论是容器也好，k8s的SDN也好，服务器的物理网络也好，对于k8s集群而言，其实都是在同一个内核上！也就是说，同一个人，干的同样的活，为什么表现的情况是不一样的？<