eBPF技术揭秘：DeepFlow如何引领故障排查，提升运维效率，ebpf 原理

DeepFlow 实战：eBPF 技术如何提升故障排查效率

目录

DeepFlow 实际应用：eBPF 技术如何提高故障排除效率

微服务架构系统中不同服务、组件及其相互关系的全景图。

零侵入分布式追踪架构和工作流程

零入侵连续分析报告

关于前端404错误处理的会议内容

业务异常-1分钟解决前端404错误

偶尔出现的业务异常503 异常问题旨在在几分钟内快速识别和解决。

偶尔出现的业务异常503 异常问题旨在在几分钟内快速识别和解决。

专注于识别和消除新版本发布后隐藏的错误以及处理CPU激增问题

针对服务超时问题，特别是新功能上线后日志中频繁出现的第三方服务API调用超时问题进行详细的分析和解决策略。

介绍了eBPF（扩展伯克利包过滤器）技术的应用，以提高故障排除效率。

会议分析了云原生应用架构的演进及其带来的复杂性和挑战。该图清楚地展示了不同级别的技术和服务，从业务和框架代码通过路径和节点到微服务、容器和虚拟机。随着技术的发展，路径数量增加，基础设施复杂性显着增加。

您将看到业务代码和框架代码作为应用程序的核心，通过应用程序进程和代理进程等组件与微服务、容器和虚拟机等基础设施进行交互。这种架构演变允许更快的服务发布和更简单的单个服务，同时逐渐将通用逻辑卸载到基础设施并增加语言和框架开发自由度。

然而，这种演变也带来了许多挑战。诸如仪表问题、跟踪盲点、标签丢失、容量问题和资源消耗过多等问题都是云原生应用架构发展过程中需要面对和解决的问题。

为了解决这些问题，采用了Prometheus、OpenTelemetry、fluidd、Kafka、Redis、Kubernetes等一套云原生技术和工具来支持全栈可观测性，帮助开发者更好地监控、跟踪和监控。管理云原生应用程序。

会议不仅展示了云原生应用架构的演变，还强调了它们带来的复杂性和挑战，以及可能的解决方案。

它深入分析了微服务架构中应用程序性能监控(APM) 面临的两大挑战。

难以测量和划分。

客户端请求首先经过Kong API Gateway，然后转发到Spring Gateway或相应的微服务。微服务通过REST API 进行通信，从而实现业务逻辑和协作的分离。部署环境：

该图体现了系统的灵活性和可扩展性，表明服务可以部署在pod（如Kubernetes pod）、虚拟机（VM）和主机（hosts）等不同环境中。性能监控：

该图显示了不同组件之间的延迟时间，例如100 ms、28 ms 等。这些指标可帮助您监控和优化系统的性能瓶颈。消息队列：

虽然图中没有明确显示，但根据微服务架构中的常见做法，系统可能会使用Kafka 等消息队列系统来进行微服务之间的消息传递和异步通信。安全：

eBPF的引入保证了网络数据包的安全，保证只有合法的请求才能到达目标服务。

综上所述，这张全景图涵盖了服务发现、请求路由、数据库交互、消息队列、网络过滤等多个方面，提供了系统稳定性和可扩展性的全面展示。并提供安全保障。

微服务架构系统中各个服务、组件及其相互关系的全景

入口和负载平衡：

作为软件负载均衡器（SLB），NGINX 负责接收和分发进入系统的请求。然后，请求通过Spring Gateway，这是一个用于路由、过滤和监视API 请求的微服务网关。服务网格：

作为服务网格代理，Envoy 负责服务之间的通信，并提供流量管理、安全性和可观察性等功能。 Java服务：

Java 服务通过web-svc DNS 票证服务器进行通信，以确保服务之间的可靠连接。使用Nacos作为服务注册中心，实现服务的自动注册和发现。 Redis作为缓存层来存储常用数据并提高系统响应能力。 MySQL作为关系型数据库，存储着系统的核心数据。应用程序性能管理（APM）：

SkyWalking 是一款APM 工具，用于收集、分析和聚合系统性能数据。它利用eBPF（扩展伯克利数据包过滤器）技术对网络数据包进行详细的过滤和分析，提供更详细的性能监控。客户端与服务器通信：

客户端通过web-svc 发起GET 请求来检索所需的数据。客户端和服务器之间的通信可以使用gRPC协议来保证数据传输的高效可靠。客户端和服务器端也使用Nacos进行服务注册和发现，保证服务的动态可用性。客户端和服务器之间共享Redis和MySQL，保证数据一致性和高效访问。文件存储：

使用/redis.aof 文件作为Redis 的持久存储，以避免重启或故障后数据丢失。

这张完整的图清楚地展示了从入口到后端服务到数据库和缓存的整个分布式跟踪架构，以及组件之间的交互关系和数据流。这为系统运维、性能优化提供了强有力的支持。

零侵扰分布式追踪（Distributed Tracing）的架构和工作流程

让开发人员深入了解不同编程语言的应用程序性能。该报告涵盖了从11:26到11:58的时间段，并提供了丰富的数据分析和图形表示。

报告主要内容如下。

时间范围和关键数据：该报告详细介绍了您的应用程序在此期间的多个性能指标，包括建立的连接数、完成的任务数、内存分配和释放数以及进程数。通过提供创建和销毁时间等开发基础知识，提供全面的性能概述。

技术栈和工具：本报告基于eBPF（增强型伯克利数据包过滤器）技术，结合Rust、C/C++、Golang、Java等编程语言以及Pyrscope等工具进行本机语言分析。确保详细了解应用程序性能。

图表分析：报告中的图表直观地展示了各个时间段的CPU使用率、每个函数的调用次数、平均时间、总时间。这些图表为开发人员快速识别性能瓶颈和优化点提供了基础。

函数统计：报告提供业务函数、库函数、运行时函数、共享库函数和内核函数的详细统计信息，包括调用次数、平均时间和总时间，帮助开发人员了解其应用程序的各个部分，帮助了解性能。

性能分析：通过此报告，开发人员可以清楚地看到他们的应用程序在不同编程语言中的表现以及每个功能如何影响性能。这有助于开发人员优化代码并提高应用程序性能和效率。

关于零侵扰持续性能剖析（Continuous Profiling）的报告

首先，我们看一下前端页面遇到404错误的情况，这种情况被识别为一种业务异常。当用户在前端遇到空白页面并且您的API 返回404 错误时，您需要快速查找并追踪返回错误的服务。对于故障排除步骤，我们首先回顾一下传统的故障排除方法。找到该URL对应的后端服务，分析该后端服务的日志，通过多节点抓包查看日志中是否没有记录访问情况。请求的方向。其次，有了实施DeepFlow后的新体验，现在可以通过输入URL来快速查询通话记录，并且上述步骤可以在5分钟内完成，极大地提高了故障排除效率。会议重点分析了错误类型，比如确认HTTP调用日志中返回了错误的IP地址，确认DNS调用日志中域名解析没有异常。这些分析将帮助您更准确地查明问题。

经过充分讨论，会议确定访问异常的根本原因是代理设置不当。这一发现为后续解决方案提供了重要基础。

最后，提供了故障排除过程的时间比较，强调了实施DeepFlow 后故障排除时间从几个小时到5 分钟的显着变化。这不仅提高了工作效率，也体现了团队在处理业务异常时的快速反应能力。

关于前端404错误处理的会议内容

问题描述：前端出现空白页面，API返回404错误。这通常意味着服务器找不到所请求的资源。

解决步骤：

确定问题：我们首先确定了与违规URL 相对应的后端服务，并分析了该服务的日志。由于日志中没有访问记录，我们从多个节点抓包来进一步确认请求的方向。确定错误原因：接下来，我们根据HTTP调用日志确定返回404错误的IP地址或服务器。验证域名解析：为了确认问题不是由域名解析引起的，我们还检查了DNS调用日志，确认域名解析没有异常。

故障排除经验对比：

过去：在DeepFlow 出现之前，解决此类问题通常需要几个小时。现在：借助DeepFlow 工具，我们现在可以在不到5 分钟的时间内快速识别并解决404 错误，大大提高了我们的故障排除效率。

根本原因：经过进一步排查，我们发现问题的根本原因是代理设置导致的访问异常。

我们将向您展示如何部署DeepFlow 工具来快速识别和解决前端404 错误。这不仅提高了工作效率，也为客户提供了更加稳定可靠的服务体验。

业务异常 – 一分钟解决前端404错误

问题描述：

监控中心时常出现访问异常的情况，具体表现为503服务不可用错误。请注意，您的运维团队并未主动触发503状态码，因此您需要确定异常的原因。

分析过程：

日志分析：首先，通过快速过滤HTTP调用日志，识别异常调用请求。调用链跟踪：此外，使用调用链跟踪技术来检查异常服务并查明问题发生的具体位置。

故障排除方法：

业务分类：在研发团队的指导下，整理业务访问关系，分析服务日志，获取异常详细信息。使用DeepFlow 提高效率：输入503 状态代码即可查看详细的呼叫日志、跟踪异常呼叫发起和呼叫链，并在5 分钟内快速识别异常服务。

根本原因分析：

进一步分析发现，该服务在业务高峰时段出现瓶颈，资源耗尽并触发503异常。

解决了：

基于以上分析，提出针对性的解决方案。

服务扩容：业务高峰期进行服务扩容，保证资源充足，避免503异常再次发生。持续优化：持续关注业务运营，通过技术优化和流程改进，提高系统稳定性和可用性。

快速识别和分析偶尔发生的503 异常问题并提出有效的解决方案。通过日志分析、调用链追踪、业务分流，我们不仅发现了问题的根本原因

业务异常中偶现的503异常问题，旨在实现分钟级定位并快速解决。

问题描述：

监控中心时常出现访问异常的情况，具体表现为503服务不可用错误。请注意，您的运维团队并未主动触发503状态码，因此您需要确定异常的原因。

分析流程： 日志分析：首先，通过快速过滤HTTP调用日志，识别异常调用请求。调用链跟踪：此外，使用调用链跟踪技术来查看异常服务并查明问题发生的具体位置。

故障排除方法：

业务分类：在研发团队的指导下，整理业务访问关系，分析服务日志，获取异常详细信息。使用DeepFlow 提高效率：输入503 状态代码即可查看详细的呼叫日志、跟踪异常呼叫发起和呼叫链，并在5 分钟内快速识别异常服务。

根本原因分析：

进一步分析发现，该服务在业务高峰时段出现瓶颈，资源耗尽并触发503异常。

解决了：

根据上述分析，提出针对性的解决方案。

服务扩容：业务高峰期进行服务扩容，保证资源充足，避免503异常再次发生。持续优化：持续关注业务运营，通过技术优化和流程改进，提高系统稳定性和可用性。

实现对偶发503异常问题的快速识别和分析，并提出有效的解决方案。通过日志分析、调用链跟踪、业务分流，我们不仅找出了问题的根本原因，还提出了针对性的改进建议。

业务异常中偶现的503异常问题，旨在实现分钟级定位并快速解决。