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

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

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

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

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

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

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

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

围绕隐藏Bug的识别和消除，以及新版本上线后CPU飙升问题的处理展开

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

探讨了eBPF（Extended Berkeley Packet Filter）技术在提升故障排障效率方面的应用。

会议中剖析了云原生应用架构的演进过程及其带来的复杂性和挑战。图表通过路径和节点的方式，清晰地展示了从业务代码、框架代码到微服务、容器和虚拟机等不同层次的技术和服务。随着技术的演进，路径逐渐增多，基础设施的复杂性也急剧增长。

我们可以看到业务代码和框架代码作为应用的核心，通过应用进程、代理进程等组件与微服务、容器和虚拟机等基础设施进行交互。这种架构的演进使得服务发布更加快速，单个服务更加简单，同时通用逻辑逐渐被卸载至基础设施，为开发语言和框架提供了更大的自由度。

然而，这种演进也带来了诸多挑战。插桩困难、追踪盲点、标签不足、容量焦虑以及资源消耗过多等问题，都是云原生应用架构在演进过程中需要面对和解决的难题。

为了解决这些问题，使用Prometheus、OpenTelemetry、fluentd、Kafka、Redis、Kubernetes等一系列云原生技术和工具，它们为全栈可观测性提供了支持，帮助开发者更好地监控、追踪和管理云原生应用。

会议中不仅展示云原生应用架构的演进过程，还揭示了其带来的复杂性和挑战，以及可能的解决方案。

其中深入剖析了微服务架构中应用程序性能监控（APM）所面临的两大核心挑战：

插桩困难和定界困难。

插桩困难主要体现在微服务架构中服务数量的庞大上。由于每个服务都需要进行插桩以收集性能数据，这导致了巨大的工作量。同时，插桩过程可能会引入额外的延迟，从而对服务的性能产生负面影响。
定界困难则源于微服务架构中服务间复杂的依赖关系。一个服务的问题可能会波及到其他服务，使得跨服务追踪和日志管理变得异常复杂，难以迅速准确地定位问题所在。
一方坚信问题源于对方的故障，而另一方则坚称一切运行正常。这种情境凸显了在微服务架构中，APM在快速定位和解决性能问题方面的重要性。
此外，微服务架构中的关键组件，如客户端、服务、网关、缓存、数据库等，以及它们之间的调用关系。通过APM工具（如Zipkin、Jaeger等）来追踪和监控这些调用，可以帮助我们更好地识别性能瓶颈和问题所在。
会议中强调了微服务架构中APM的重要性，还揭示了插桩和定界两大挑战。为了有效地管理和监控微服务架构的性能，我们需要借助先进的APM工具和方法，以应对这些挑战。

DeepFlow技术框架以其全栈（Full Stack）和零侵入（Zero Code）的特性，展示了其技术制高点。该框架支持多种网络协议，如HTTP2/HTTPS、HTTP1/SQL、SSL/TLS等，并兼容多种编程语言或框架，如Go、Java、Rust、K8s、C++、Node.js等，确保应用的广泛适用性和灵活性。

DeepFlow通过eBPF（Extended Berkeley Packet Filter）技术，在内核级别实现功能，如Kprobe和Tracepoint，支持Socket、TCP、IP等网络协议，为系统提供深入的网络观测能力。同时，该框架也支持虚拟机（VM）中的iptables、ipvs等网络功能，以及L4、L7层网关，确保在虚拟化环境中的高效网络管理。

DeepFlow还包含vSwitch和vRouter组件，支持KVM/Hyper-V等虚拟化技术，为网络流量提供灵活的路由和交换功能。在驱动程序层面，它支持BPF（Berkeley Packet Filter）和AF_PACKET接口，确保网络数据的高效处理和传输。

用户空间方面，DeepFlow框架集成了POD、侧车（Sidecar）等组件，为用户提供丰富的网络服务和应用支持。整个框架通过eBPF技术实现全栈和零侵入的特点，能够无缝集成到现有的系统中，无需修改现有代码，提供高效和灵活的网络观测和分析能力。

在SIGCOMM 2023纽约城市会议上，DeepFlow框架被选为观测性平台，展示了其在中国原创技术领域的领先地位和可靠性。通过这张技术架构图，我们可以清晰地看到DeepFlow框架的组成和优势，以及它在网络观测和分析领域的广泛应用前景。

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

核心组件：
Kong API Gateway：作为系统的入口点，负责接收并处理来自客户端的HTTP/S请求。
Spring Gateway：在微服务架构内部，用于请求路由和转发。
Consul：提供服务发现、配置管理和服务协调功能。
微服务：如svc-web、svc-item、svc-user、svc-order、svc-customer等，各自负责不同的业务逻辑。
数据库：MySQL作为关系型数据库，Redis作为缓存数据库，为微服务提供数据存储和查询服务。
eBPF：扩展Berkeley Packet Filter，用于网络数据包过滤，确保数据的安全性。
服务间通信：
客户端请求首先通过Kong API Gateway，随后被转发至Spring Gateway或相应的微服务。
微服务之间通过REST API进行通信，实现业务逻辑的解耦和协同。
部署环境：
图中展示了服务可以部署在多种环境中，包括Pod（如Kubernetes Pod）、虚拟机（VM）、宿主机（Host）等，体现了系统的灵活性和可扩展性。
性能监控：
图中标注了不同组件之间的时间延迟，如100ms、28ms等，这些指标有助于监控系统的性能瓶颈并进行优化。
消息队列：
虽然图中未明确标出，但根据微服务架构的常见实践，可以推测系统可能使用了如Kafka等消息队列系统，用于微服务之间的消息传递和异步通信。
安全性：
eBPF的引入，确保了网络数据包的安全性，只有合法的请求才能到达目标服务。

总结来说，这张全景图展现了一个微服务架构系统中零侵扰服务的全面视图，涵盖了服务发现、请求路由、数据库交互、消息队列、网络过滤等多个方面，为系统的稳定性、可扩展性和安全性提供了有力保障。

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

入口与负载均衡：
NGINX 作为软件负载均衡器（SLB），负责接收并分发进入系统的请求。
请求随后通过 Spring Gateway，这是一个微服务网关，用于路由、过滤和监控API请求。
服务网格：
Envoy 作为服务网格的代理，负责服务之间的通信，提供流量管理、安全性、可观察性等功能。
Java服务：
Java服务通过web-svc DNS票据服务器进行通信，确保服务之间的可靠连接。
使用Nacos作为服务注册中心，实现服务的自动注册与发现。
Redis作为缓存层，用于存储常用数据，提高系统响应速度。
MySQL作为关系型数据库，存储系统核心数据。
应用性能管理（APM）：
SkyWalking作为APM工具，用于收集、分析和聚合系统性能数据。
利用eBPF（扩展Berkeley Packet Filter）技术，对网络数据包进行深度过滤和分析，以提供更精细的性能监控。
客户端与服务器通信：
客户端通过web-svc发起GET请求，获取所需数据。
客户端和服务器之间的通信可能采用gRPC协议，确保高效、可靠的数据传输。
客户端和服务器同样使用Nacos进行服务注册与发现，确保服务的动态可用性。
Redis和MySQL在客户端和服务器之间共享，确保数据的一致性和高效访问。
文件存储：
使用/redis.aof文件作为Redis的持久化存储，确保数据在重启或故障后不会丢失。

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

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

帮助开发者深入了解应用程序在不同编程语言下的性能表现。报告涵盖了从11:26到11:58的时间段，并提供了丰富的数据分析和图表展示。

报告的主要内容包括：

时间范围与关键数据：报告详细记录了在此时间段内，应用程序的多个性能指标，如建立的连接数、完成的任务数、内存分配与释放次数、进程创建与销毁次数等，为开发者提供了全面的性能概览。

技术栈与工具：报告基于eBPF（扩展Berkeley Packet Filter）技术，结合Rust、C/C++、Golang和Java等编程语言，利用Pyroscope等工具进行语言原生剖析，确保了对应用程序性能的深入洞察。

图表分析：报告中的图表直观地展示了不同时间段内CPU的使用情况，以及各个函数的调用次数、平均时间和总时间。这些图表为开发者提供了快速定位性能瓶颈和优化点的依据。

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

性能剖析：通过这份报告，开发者可以清晰地看到应用程序在不同编程语言下的性能差异，以及各个函数对性能的影响。这有助于开发者优化代码，提高应用程序的性能和效率。

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

首先聚焦于前端页面出现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错误的快速定位和解决。这不仅提高了我们的工作效率，也为客户提供了更加稳定可靠的服务体验。

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

问题描述：
监控中心偶现访问异常，具体表现为503 Service Unavailable错误。值得注意的是，运维团队并未主动触发过503状态码，因此需要定位异常原因。

分析过程：

日志分析：首先，通过快速过滤HTTP调用日志，识别出异常的调用请求。
调用链追踪：进一步，利用调用链追踪技术，确认异常服务，并定位问题发生的具体位置。

排查手段：

业务梳理：按照研发团队的指引，梳理业务访问关系，分析服务日志，以获取更多关于异常的信息。
DeepFlow提效：通过输入503状态码，查看详细的调用日志，并追踪异常调用的发起和调用链，以在五分钟内迅速确认异常服务。

根本原因分析：
经过深入分析，发现业务高峰期时，服务存在瓶颈，导致资源不足，从而引发503异常。

解决方案：
基于上述分析，提出了针对性的解决方案：

服务扩容：针对业务高峰期，进行服务扩容，确保资源充足，避免再次出现503异常。
持续优化：持续关注业务运行状况，通过技术优化和流程改进，提升系统的稳定性和可用性。

对偶发503异常问题的快速定位和分析，并提出了有效的解决方案。通过日志分析、调用链追踪和业务梳理等手段，不仅找到了问题的根本原因

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

问题描述：
监控中心偶现访问异常，具体表现为503 Service Unavailable错误。值得注意的是，运维团队并未主动触发过503状态码，因此需要定位异常原因。

分析过程：日志分析：首先，通过快速过滤HTTP调用日志，识别出异常的调用请求。调用链追踪：进一步，利用调用链追踪技术，确认异常服务，并定位问题发生的具体位置。

排查手段：

业务梳理：按照研发团队的指引，梳理业务访问关系，分析服务日志，以获取更多关于异常的信息。
DeepFlow提效：通过输入503状态码，查看详细的调用日志，并追踪异常调用的发起和调用链，以在五分钟内迅速确认异常服务。

根本原因分析：
经过深入分析，发现业务高峰期时，服务存在瓶颈，导致资源不足，从而引发503异常。

解决方案：
基于上述分析，提出了针对性的解决方案：

服务扩容：针对业务高峰期，进行服务扩容，确保资源充足，避免再次出现503异常。
持续优化：持续关注业务运行状况，通过技术优化和流程改进，提升系统的稳定性和可用性。

成功实现了对偶发503异常问题的快速定位和分析，并提出了有效的解决方案。通过日志分析、调用链追踪和业务梳理等手段，不仅找到了问题的根本原因，还提出了针对性的改进措施

围绕隐藏Bug的识别和消除，以及新版本上线后CPU飙升问题的处理展开

首先，会议通过CPU使用率的图表，对比了新版本上线前后CPU使用率的显著变化，并指出了CPU飙升的问题。随后，通过监控发布过程，发现CPU和QPS（每秒查询率）的上升，这提示了可能存在性能瓶颈或异常请求。
接下来，会议通过下钻分析，锁定了Top URI（统一资源标识符），并确认了请求突增的情况。通过进一步分析海量日志，会议团队快速定位了问题的根因，即客户端与服务端版本不一致导致的客户端频繁重试。
为了消除这一隐患并优化性能，会议提出了多项措施。首先，通过调用日志和Wasm插件增加业务属性，确认了SDK版本，从而解决了版本不一致的问题。此外，还讨论了其他调优技术，如调整参数和优化代码，以进一步提升系统性能。

通过收集数据、分析数据、确定问题原因，并最终解决问题。

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

如何精准界定这类超时问题是由网络因素还是第三方服务本身所导致。

会议回顾了错误日志的详细情况，其中包含了ResourceAccessException异常，这明确指出了在尝试通过GET请求获取数据时发生了I/O错误，具体表现为读取超时。通过RestTemplate的调用栈，我们能够追踪到问题发生在RestTemplate.doExecute方法中，这进一步指向了网络层面的潜在问题。
会议对现有的网络指标进行了深入分析。通过监控TCP连接状态、流量、丢包率等关键指标，发现存在网络抖动和重传比例高等异常情况。这些指标为提供了网络层面可能存在问题的线索。
为了更精确地定位问题根源，会议引入了DeepFlow工具来分析网络流量和抖动情况。通过这一工具，确定了服务端重置是导致调用超时的主要原因，这进一步指向了第三方服务异常的可能性。
基于以上分析，提出了针对性的解决方案。如果问题源于网络抖动，将优化网络连接以确保稳定性；如果问题确实由第三方服务引起，将与第三方服务提供方紧密沟通，共同寻求解决方案。

会议不仅深入探讨了服务超时问题的排查方法，还通过日志分析、网络监控和异常处理等手段，精准界定了问题的根本原因，并制定了相应的解决策略。这为我们未来处理类似问题提供了宝贵的经验和参考。

探讨了eBPF（Extended Berkeley Packet Filter）技术在提升故障排障效率方面的应用。

强调了eBPF技术能够实现零侵扰数据采集，这意味着在不影响系统正常运行的情况下，该技术能够捕获从内核到用户空间的关键数据流动，包括Process、write()、read()、sendmsg()、recvmsg()等系统调用，以及socket、TCP/IP、Block Device、Network Device等网络和设备相关组件的交互信息。
eBPF技术如何帮助实现分钟级的问题定位。通过将eBPF程序加载到Linux内核，系统管理员可以实时收集和分析系统数据，从而迅速发现故障点，极大地提高了故障排查的效率。
此外，提到了eBPF技术的其他优势，如“无盲点、细粒度”的数据收集能力，以及“全景图、分布式追踪、持续剖析”的监控策略。这些特点使得eBPF技术能够提供一个全面、细致且持续的系统监控和故障排查方案。