建设企业网站的目的,wordpress上卖什么,网站推广平台怎么做,商城系统网站建设DeepFlow 是基于 eBPF 的可观测性开源项目#xff0c;旨在为复杂的云基础设施及云原生应用提供深度可观测性。DeepFlow 基于 eBPF 采集了精细的链路追踪数据和网络、应用性能指标#xff0c;其在网络路径上的全链路覆盖能力和丰富的 TCP 性能指标能够为专业用户和网络领域专家… DeepFlow 是基于 eBPF 的可观测性开源项目旨在为复杂的云基础设施及云原生应用提供深度可观测性。DeepFlow 基于 eBPF 采集了精细的链路追踪数据和网络、应用性能指标其在网络路径上的全链路覆盖能力和丰富的 TCP 性能指标能够为专业用户和网络领域专家提供充足的排障定界支撑。 Kindling-OriginX 是一款故障根因推导产品目标是提供给用户一个可解释的故障根因报告让用户能够直接了解故障根因并附有根因的推理过程以便验证根因的准确性。网络故障是故障当中比较难以简单解释的仅仅告知用户哪段网络有问题是不够的用户需要更多指标以及图解才能帮助用户更好的理解网络到底发生了什么故障以及发生在哪个环节。 本文介绍 Kindling-OriginX 通过结合 DeepFlow 完备的网络数据能力自动化生成可解释的故障根因报告。 soma-chaos模拟网络故障 针对seat-service注入200ms延时的网络模拟故障。 接下来我们先使用 DeepFlow 来识别200ms的网络故障并做出相应的action。
人工最简化排障过程 步骤一利用Trace系统缩小范围
在微服务场景中某个接口突然慢了排障的第一步骤应该是看Tracing系统找到Trace慢在哪个环节以及慢的具体表现是什么。
用户通过Tracing系统能够找到具体的Trace通过分析Trace能够发现seat-service执行时间很长同时出现了一条非常长的config-service调用但是config-service执行不慢。这个时候需要联动网络指标来定位网络问题。
步骤二利用DeepFlow火焰图确定故障发生在哪段网络
将故障代表traceid的输入DeepFlow在火焰图中找到Trace在网络层面上的表现然后深入分析这个火焰图如果对火焰图比较了解同时有具备网络知识的专家经验是能够根据火焰图人为分析出这个故障应该是发生在调用者也就是seat-service上而且问题是发生了syscall到网卡的时间段也就是容器网络时段出了问题和故障注入是吻合的。 DeepFlow网络火焰图题 步骤三确定容器网络到底什么网络指标异常
根据故障排查经验用户需要查看seat-service与config-service的pod的网络指标。这个时候用户需要跳转至DeepFlow的Pod级别的网络指标页面。通过该页面用户能够查看出建连有200ms的延时突变以及RTT指标有突变。 DeepFlow-pod级别监控指标 DeepFlow-pod级别监控指标题 步骤四排除可能的干扰因素
根据经验宿主机的CPU被打满和带宽被占满之时虚拟网络也会出现丢包和时延所以要排查当时seat-service与config-service所在node的CPU以及node级别的带宽确保Node级别资源没有饱和。
通过k8s命令确认了两个pod所在的node节点然后去DeepFlow的node指标监控页面查看相应指标发现node的bps,pps等指标均在合理范围内。 通过k8s命令查找pod所在的节点 DeepFlow-node级别监控指标client DeepFlow-node级别监控指标(server) 由于node级别的网络指标没有出现明显异常最终确定是seat-service的pod级别rtt指标异常。
人工排障总结
经过一系列的排查过程最终用户是能够排查出故障的但是对用户有以下要求 网络知识非常丰富 深入理解网络火焰图 熟练使用相关工具 Kindling-OriginX 如何结合 DeepFlow 指标生产可解释的故障报告
Kindling-OriginX 针对不同的用户需求和使用场景Kindling-OriginX 对 DeepFlow 的数据进行了加工呈现。
类比人工最简化排障过程利用 Kindling-OriginX 的排障过程如下
自动化分析每一条Trace
针对此时的故障自动化分析每条Trace并按照故障节点对所列的Trace进行归集。Travel-service是由于级联故障导致的本文不重点论述级联故障如果有兴趣可以参考微服务级联故障该如何处理。 Review故障节点为seat-service的故障根报告
故障根因结论
对于子请求10.244.1.254:50332-10.244.5.79:15679 rtt指标出现200ms左右的延时 故障的推理验证
由于Kindling-OriginX 已经识别出是seat-service调用config-service的网络有问题所以不用完全把 DeepFlow 的火焰图所有数据呈现给用户只需要与 DeepFlow 对接仅仅拿到seat-service调用config-service那段网络调用的相关数据即可。
利用 DeepFlow 的seat-service调用config-service数据自动分析出了客户端pod的容器网络出现了201ms的延时 Kindling-OriginX 会模拟专家分析经验进一步关联DeepFlow的重传指标与RTT指标从而确定到底是什么原因导致了seat-service调用config-service出现了延时的现象。 Kindling-OriginX 还会集成node的CPU利用率以及带宽指标排除干扰因素。 Kindling-OriginX 将整个故障推理都在一页报告中完成并且每个数据来源都是可信可查的。
总结
Kindling-OriginX 与 DeepFlow 都使用了 eBPF 技术立求在不同的场景中为不同需求的用户提供灵活高效解决方案也期待未来能看到国内有更多能力互补产品的出现。
DeepFlow 能提供非常完备的全链路网络基础数据能够让云原生应用具有深度可观测性对于排查网络问题非常有用。
Kindling-OriginX 是利用eBPF采集排障北极星指标、AI算法和专家经验构建故障推理引擎给用户提供可解释的根因报告。 进入产品官方网站[https://originx.kindlingx.com]通过在线Demo体验Kindling-OriginX 如何集成 DeepFlow 的数据增强网络故障的解释力
