当前位置: 首页 > article >正文

【下一代分布式追踪】将Trace扩展到网络设备

下一代分布式追踪—将Trace扩展到网络设备

  • 一、技术背景
  • 二、研究动机
  • 三、方法
    • 数据采集:
    • 数据整合:
    • 路径重建:
    • 可视化与分析:
  • Foxhound,Foxhound
  • 四、典型案例
  • 五、结论

一、技术背景

随着云计算和微服务的普及,现代应用架构日趋复杂。为了有效监控、诊断和优化这些分布式系统,分布式追踪技术应运而生。传统的分布式追踪,如Zipkin、Jaeger和OpenTelemetry,已经能够很好地追踪应用程序中的请求路径,但它们主要关注应用层,而很少涉及网络层。

网络设备,如交换机、路由器和负载均衡器,在请求传输中起到至关重要的作用。然而,当问题发生时,传统的应用层追踪很难准确地指出问题是由网络设备还是应用程序引起的。

随着摩尔定律的终结,硬件性能的增长逐步放慢,将系统功能下放到网络,进行在网计算已经成为优化系统性能重要方式。但是当前的 Trace 和 INT 采集的数据,都不足以帮助工程师精确地诊断在网计算函数。本文将网络 INT 数据与x86 Trace 数据合并,将 Trace 扩展到网络层,实现对 INC 的跨层监控,帮助工程师诊断 INC 故障。

二、研究动机

为了更好地理解分布式系统中的性能瓶颈、延迟和错误来源,我们不仅需要知道应用程序中的请求路径,还需要了解网络设备如何处理这些请求。将Trace扩展到网络设备,可以提供从客户端到服务端整个请求路径的端到端可见性,从而帮助我们更准确地定位问题。

但是,当前的监控系统是为传统的网络或者应用的性能监控设计的,对 INC 的监控存在以下几种缺陷:

Trace 缺乏跨层的监控能力,无法关联服务器和交换机之间的监控数据。例如,对一个请求,当前的 Trace 的 Span 信息无法精确判断请求是由服务器执行的,还是由交换机执行,导致不能很好地处理 INC 的故障

在网遥测系统(INT)专注于以网络为中心的指标,忽略 RPC 的数据。网络遥测产生的记录不包括诊断 INC 必要的请求级别的数据(例如 RPC 延迟)

三、方法

数据采集:

首先,需要在网络设备上进行数据采集。这可以通过网络镜像、sFlow、NetFlow等技术实现。这些技术可以提供设备端口级别的流量数据,包括数据包大小、时间戳、源/目的IP和端口等信息。

数据整合:

将采集到的网络设备数据与现有的应用层追踪数据进行整合。这需要将两种数据源进行时间戳对齐,并根据源/目的IP和端口等信息将它们关联起来。

路径重建:

利用整合后的数据,可以重建整个请求路径,包括在网络设备中的传输路径。这可以帮助我们更全面地了解请求在分布式系统中的完整路径。

可视化与分析:

最后,通过可视化工具展示整个请求路径,并提供各种分析功能,如延迟分析、错误率分析等,从而帮助用户更快地定位和解决问题。

Foxhound,Foxhound

提出了一个为 INC 设计的的可观测性框架 Foxhound,Foxhound 的架构图如下图所示。Foxhound 的核心设计理念是:开发工程师在 INC 中注释数据,运维工程师在运行时查询可观测性数据。
在这里插入图片描述
假设当前想要诊断一个 INC 函数 NetCache 的故障,Foxhound 的工作流程如下:

  1. PDP 开发人员在 INC 中插入 Annotation,以指示感兴趣的变量

  2. 运维工程师将把所需的查询写入 Foxhound

  3. Foxhound 生成插桩代码并加载到交换机中

  4. Foxhound Shim 层使用唯一的 RPC 标识符(RPCID)标记出站查询请求数据包

4&5. 标记的数据包通过交换机

  1. 交换机将带 Annotation 的变量与标记数据包的RPCID一起存储在交换机ASIC上

  2. 交换机通过 PCI-link 将数据以 PDP Span 的形式导出到Foxhound框架。

  3. x86 服务器 Trace 也被导出到Foxhound框架

  4. 合并 x86 Trace 和 PDP Span

进而 Foxhound 实现了服务器的 Trace 和交换机的监控数据融合的过程,将 Trace 扩展到网络设备。

四、典型案例

假设一个分布式系统由多个微服务组成,这些微服务部署在不同的物理机上,并通过交换机和路由器进行通信。当某个用户反映系统响应慢时,我们可以利用扩展后的分布式追踪进行问题分析。

首先,我们可以通过应用层追踪找到请求的完整路径,包括它经过了哪些微服务和具体的处理时间。然后,结合网络设备数据,我们可以看到请求在网络设备中的传输路径和延迟。如果发现某个交换机或路由器的延迟异常高,那么就可以初步判断问题可能出在网络设备上。

接下来,我们可以进一步分析该网络设备的流量数据,查看是否有异常流量或配置错误。如果有,那么就可以采取相应的措施进行问题修复。

五、结论

将Trace扩展到网络设备,可以提供更全面的分布式系统可见性,帮助我们更准确地定位和解决性能问题。随着技术的不断发展,相信未来会有更多的工具和方法支持这种扩展,使分布式系统的监控和诊断变得更加容易和高效。


http://www.kler.cn/a/228158.html

相关文章:

  • vue3 获取百度天气
  • 【AI日记】25.01.25
  • MAX98357A一款数字脉冲编码调制(PCM)输入D类音频功率放大器
  • 9【如何面对他人学习和生活中的刁难】
  • 二叉树的深度
  • C#设置winform窗体自动适应不同分辨率的电脑
  • web 技术栈有哪些?
  • SQL Server之DML触发器
  • docker 构建个人博客网站
  • 《Python 网络爬虫简易速速上手小册》第3章:Python 网络爬虫的设计(2024 最新版)
  • Qos--优先级映射关系
  • HTML5和CSS3强化知识总结
  • EF Core 的基本使用及常见的坑
  • go-基于逃逸分析来提升性能程序
  • 基于hadoop+spark的大规模日志的一种处理方案
  • 数据安全加密系统的核心目的是什么
  • 从0开始搭建、上传npm包
  • 美敦力呼吸机PB560硬件分析
  • 后端程序员入门react笔记——react的生命周期(二)
  • Qt程序设计-自定义QLineEdit控件添加鼠标单击事件
  • JS第二天、原型、原型链、正则
  • iPhone搞机记录
  • 视频美颜SDK开发指南:从入门到精通的技术实践
  • 机器学习系列——(六)数据降维
  • 一次Kubernetes Pod内存异常导致的测试环境耗时异常问题排查过程
  • android.MediaMuxer时间裁剪