龙蜥系统运维联盟:Kindling-OriginX 如何集成 DeepFlow 的数据增强网络故障的解释力

02/05 20:41
阅读数 15

编者按:2023年,龙蜥社区正式成立系统运维联盟,该联盟信通院、阿里云、中兴通讯、复旦大学、清华大学、浙江大学、云观秋毫、乘云数字、云杉网络、浪潮信息、统信软件及联通软件院等 12 家单位共同发起。本文转自云观秋毫介绍系统运维联盟成员 Kindling-OriginX 通过结合 DeepFlow 完备的网络数据能力,自动化生成可解释的故障根因报告。



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 算法和专家经验构建故障推理引擎,给用户提供可解释的根因报告。


—— 完 ——

本文分享自微信公众号 - OpenAnolis龙蜥(OpenAnolis)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部