本文為 DeepFlow 在首屆云原生社區(qū)可觀測性峰會上的演講實錄。回看鏈接[1]，PPT下載[2]。

很高興有機會在第一屆可觀測性峰會上向大家介紹我們的產品 DeepFlow，我相信它會是今天 eBPF 含量最高的一個分享。DeepFlow 的能力很多，而我今天的分享會聚焦于一個點上說透，希望大家由此感知到 eBPF 帶給可觀測性的變革。那么我今天要分享的內容就是，DeepFlow 如何利用 eBPF 技術，在不改代碼、不改配置、不重啟進程的前提下，自動繪制云原生應用的全景拓撲。全景應用拓撲能解決我們很多問題：觀測任意服務的全景依賴關系、觀測整個應用的瓶頸路徑、定位整個應用中的故障位置。

在開始之前，我大概也介紹一下自己的背景：從清華畢業(yè)以來，我一直在云杉網(wǎng)絡工作，我們從 2016 年開始開發(fā) DeepFlow，我們基于 eBPF 等創(chuàng)新技術打通云基礎設施和云原生應用的全棧環(huán)節(jié)，零侵擾的實現(xiàn)應用的可觀測性。今天的分享分為四個部分：第一部分介紹傳統(tǒng)的解決方案如何繪制應用拓撲；第二部分介紹如何用 eBPF 完全零侵擾的實現(xiàn)應用拓撲的計算；第三部分介紹如何利用 eBPF 實現(xiàn)進程、資源、服務等標簽的注入，使得開發(fā)、運維、運營都能從自己熟悉的視角查看這個拓撲；最后第四部分介紹一個全鏈路壓測的 Demo 和我們在客戶處的幾個實戰(zhàn)案例。

01｜傳統(tǒng)解決方案的問題

首先我們知道，在應用拓撲中，節(jié)點可以展示為不同的粒度，例如按服務、按實例、按應用等不同粒度展現(xiàn)。例如對于服務粒度，一個節(jié)點代表一個服務，它由多個實例組成。節(jié)點之間的連線代表調用關系，通常也對應了一系列的指標，表示服務之間調用的吞吐、異常、時延等性能。在云原生時代，云基礎設施、微服務拆分等因素會帶來很多挑戰(zhàn)，導致繪制一個全景的應用拓撲變得非常艱難。

傳統(tǒng)的解決方案我們很熟悉，通過埋點、插碼的方式，修改代碼來輸出類似于 Span 的調用信息，通過聚合 Span 得到應用拓撲。即使是采用自動化的 Java 字節(jié)碼注入等技術，雖然看起來不用改代碼，但還是要修改啟動參數(shù)，意味著服務要重新發(fā)布，至少要重啟服務進程。

插碼方案的困難 – 難以升級

在云原生場景下，使用這樣的方法來獲取應用拓撲變得更加困難。隨著服務拆得越來越微小，每個服務的開發(fā)人員的自由度變得越來越大，因此可能會出現(xiàn)各種新奇的語言、框架。相對于 Java agent 而言，其他語言基本都會涉及到代碼修改、重編譯重發(fā)布。當然一般我們都會將這部分邏輯實現(xiàn)在一個 SDK 中，然而 SDK 的升級也是一個痛苦甚至絕望的過程，業(yè)務方都不愿意升級，升級意味著發(fā)版，發(fā)版可能就意味著故障。

那有方法能避免修改代碼嗎？云原生時代我們還有一個選項 —— 使用服務網(wǎng)格（Service Mesh）。例如 Istio 在 K8s 及非容器環(huán)境下可構建一個服務網(wǎng)絡。

網(wǎng)格方案的困難 – 難以全覆蓋

但服務網(wǎng)格的問題在于并不能覆蓋所有協(xié)議，例如 Istio 主要覆蓋 HTTP/gRPC，而其他大量各種各樣的 Protobuf/Thrift RPC，以及 MySQL/Redis/Kafka/MQTT 等中間件訪問都無法覆蓋到。另外從因果關系來講，我們可以因為選擇了服務網(wǎng)格而順帶實現(xiàn)一部分可觀測性，但肯定不會因為要去實現(xiàn)可觀測性而引入服務網(wǎng)格這樣一個帶有侵入性的技術。

除此之外，在云原生時代，即使我們去改業(yè)務代碼、上服務網(wǎng)格，仍然無法獲取到一個完整的應用拓撲。比如云基礎設施中的 Open vSwitch，K8s 中的 IPVS，Ingress 位置的 Nginx 網(wǎng)關，這些都是看不到的。

下面出場的就是我們今天要講的主角，eBPF，它是一個非?；馃岬男录夹g。我們來看看它是不是能解決我們今天聚焦的問題，能否將應用拓撲畫全、畫準，能為開發(fā)、運維等不同團隊的人提供一個統(tǒng)一的視圖，消除他們的 Gap。我們知道 eBPF 有很多很好的特性，它不需要業(yè)務改代碼、不需要服務修改啟動參數(shù)、不需要重啟服務進程，它是編程語言無關的，而且能覆蓋到云基礎設施和云原生應用的整個技術棧。DeepFlow 基于 eBPF 技術也享受到了很多這方面的紅利，我們的客戶做 POC、社區(qū)的用戶試用都非常絲滑，不用去考慮運維窗口、實施周期，DeepFlow 的社區(qū)版只需一條命令，五分鐘即可開啟全景、全棧的可觀測性。

DeepFlow 軟件架構

這里也用一頁 PPT 來簡單介紹一下 DeepFlow 社區(qū)版的軟件架構。我們開源至今還不到一年，目前在社區(qū)受到了不少關注。上圖中間藍色的部分是 DeepFlow 的兩個主要組件：Agent 負責采集數(shù)據(jù)，利用 eBPF 的零侵擾特性，覆蓋各種各樣的云原生技術棧；Server 負責富化數(shù)據(jù)，將標簽與數(shù)據(jù)關聯(lián)，并存儲至實時數(shù)倉中。在北向，DeepFlow 提供 SQL、PromQL、OTLP 等接口，通過 DeepFlow 自己的 GUI 展現(xiàn)所有可觀測性數(shù)據(jù)，也兼容 Grafana、Prometheus、OpenTelemetry Collector 等生態(tài)。在南向，DeepFlow 可集成 Prometheus 等指標數(shù)據(jù)、SkyWalking 等追蹤數(shù)據(jù)、Pyrosope 等 Profile 數(shù)據(jù)。

AutoTracing AutoTagging

今天我們要聚焦的一點，就是 DeepFlow 如何使用 eBPF 生成全景應用拓撲。DeepFlow 的兩個核心能力 AutoTracing 和 AutoTagging 為應用拓撲的生成奠定了堅實的基礎。在沒有任何代碼修改、不重啟任何業(yè)務進程的情況下，我們實現(xiàn)了全景應用拓撲的繪制。首先，我們可通過 eBPF 從網(wǎng)絡包、內核 Socket Data 中獲取原始比特流；接下來我們分析 Raw Data 中的 IP、端口等信息，使用 eBPF 將原始數(shù)據(jù)與進程、資源、服務等信息關聯(lián)，以便繪制不同團隊不同視角的應用拓撲，這也是今天分享的第三部分；然后我們會從原始數(shù)據(jù)中提取應用調用協(xié)議，聚合調用中的請求和響應，計算調用的吞吐、時延和異常，以及其他系統(tǒng)和網(wǎng)絡性能指標；最后，基于這類 Request Scope 的 Span 數(shù)據(jù)，我們可以聚合生成全景應用拓撲，也可以通過關聯(lián)關系的計算生成分布式追蹤火焰圖。

今天我們主要講的是應用拓撲的繪制，對于使用 eBPF 實現(xiàn)全自動的分布式追蹤這個話題，DeepFlow 社區(qū)的博客 https://deepflow.io/blog 上有很多資料。

02｜eBPF 零侵擾計算全景應用拓撲

Universal Application Topology

首先讓我們看一個效果圖，這是 DeepFlow 展示的一個全景應用拓撲。這個拓撲可能大家比較熟悉，它是 OpenTelemetry 的一個 Demo，它 Fork 自 Google Cloud Platform 的一個項目，它是一個小型的電商應用。從圖中可以看到，DeepFlow 可以獲取所有服務之間的調用關系以及相應的性能指標，這都是通過 eBPF 實現(xiàn)的，沒有做任何的代碼修改和進程重啟，展現(xiàn)這些結果之前我們關閉了所有 OTel Instrumentation。

在這一節(jié)，我們將聚焦四個問題：第一個問題是如何采集原始數(shù)據(jù)；第二個問題是如何解析應用協(xié)議，eBPF做了什么；第三個問題是如何計算全棧性能指標；第四個問題是如何適配低版本內核，許多用戶的內核版本可能是3.10。

數(shù)據(jù)采集：DeepFlow 同時用到了 eBPF 和它的前身，有 30 年歷史的 Classic BPF（cBPF）。在云原生環(huán)境中，應用進程運行在容器 Pod 內，容器可能存在于多個節(jié)點上，并通過網(wǎng)關連接到數(shù)據(jù)庫等其他服務。我們可以使用 eBPF 技術來覆蓋所有的端節(jié)點，并使用 cBPF 覆蓋所有的中間轉發(fā)節(jié)點。從應用進程（端節(jié)點）層面，我們使用 kprobe 和 tracepoint 覆蓋所有的 TCP/UDP socket 讀寫操作；并使用 uprobe 來掛載到應用程序內的核心函數(shù)上，比如 OpenSSL/Golang 的 TLS/SSL 函數(shù)，來獲取加密或壓縮之前的數(shù)據(jù)。除此之外，在兩個服務之間還有許多中間轉發(fā)路徑，例如 IPVS、iptables、OvS 等，此時需要使用 cBPF 來獲取網(wǎng)絡包數(shù)據(jù)，因為這部分流量不會有用戶態(tài)應用程序去讀寫，會直接在內核里查表轉發(fā)。

eBPF Probes

這里列舉了 DeepFlow 中主要使用到的 eBPF Probe，包括最左邊的 kprobe，以及中間最高性能的 tracepoint，以及最右邊解決加密和壓縮數(shù)據(jù)的 uprobe。其中 tracepoint 滿足了 DeepFlow 中的絕大多數(shù)需求。

協(xié)議解析：在獲取原始數(shù)據(jù)方面，我們使用 eBPF 和 cBPF 來捕獲字節(jié)流，但此時我們無法看到任何可理解的信息。接下來，我們要做的就是從這些字節(jié)流中提取出我們關心的應用協(xié)議。大多數(shù)協(xié)議都是明文的，例如 HTTP、RPC、SQL 等，我們可以直接遵照協(xié)議規(guī)范來解析它們的內容。對于一些特殊的協(xié)議，例如 HTTP2 之類的壓縮協(xié)議，我們需要進行更復雜的處理。我們可以使用 tracepoint 或 kprobe 來提取未壓縮的字段，但此時對于已經(jīng)壓縮的頭部字段，還原它們是一項困難的工作，因此我們會選擇使用 uprobe 作為補充來采集壓縮協(xié)議的數(shù)據(jù)。另外對于加密流量也無法從內核函數(shù)中獲取明文，我們通過 uprobe 直接獲取加密之前的數(shù)據(jù)。最后，對于私有協(xié)議，它們沒有可遵循的通用規(guī)范，或者雖然遵循了 Protobuf/Thrift 等標準但無法提供協(xié)議定義文件，此時我們提供了基于 WASM 的插件化的可編程接口，在未來也有計劃提供基于 LUA 的插件機制。

在協(xié)議解析層面還需要考慮的一個事情是流重組。例如一個 HTTP2/gRPC 請求的頭部字段可能會分為多次系統(tǒng)調用讀寫，或者分拆為多個網(wǎng)絡包收發(fā)，此時我們需要還原完整請求或響應頭，一遍重組一遍嘗試解析。

eBPF WASM

特別提一下我們對私有協(xié)議的識別，通過結合 eBPF 和 WebAssembly 的能力，提供一個靈活的插件機制。插件在 DeepFlow 中解決兩個問題：提供對私有協(xié)議的解析能力、提供對任意協(xié)議的業(yè)務字段解析能力。商用軟件供應商或業(yè)務開發(fā)人員可以輕松添加自定義插件來解析協(xié)議，將可觀測性從 IT 層面提升到業(yè)務層面。這樣的方式使得我們可以自定義提取出一些業(yè)務指標或業(yè)務標簽，例如訂單量、用戶 ID、交易 ID、車機 ID 等信息。這些業(yè)務信息對于不同的業(yè)務場景都是獨特的，我們將這個靈活性給到了業(yè)務方，使得業(yè)務方可以快速實現(xiàn)零侵擾的可觀測性。

RED Metrics

性能指標：我們可以通過數(shù)請求和響應的個數(shù)來獲取吞吐量，同時還可以根據(jù)響應狀態(tài)碼、耗時等信息計算 Error 和 Delay 指標。吞吐和異常的計算相對簡單，只需要基于單個請求或單個響應進行處理即可。最困難的是對時延的計算，我們需要使用 eBPF 技術來關聯(lián)請求和響應這兩個動作。這個過程又分為兩步：從 Socket/Packet Data 中基于 <sip, dip, sport, dport, protocol> 五元組聚合出 TCP/UDP Flow；然后在 Flow 上下文中匹配應用協(xié)議的每一個 Request 和 Response。而對于第二步，一個 Flow 中一般會有多個請求和響應，匹配邏輯我們以 HTTP 協(xié)議為例解釋：

• 對于串行協(xié)議如 HTTP 1.0，直接匹配臨近的請求和響應即可
• 對于并發(fā)協(xié)議如 HTTP 2.0，需要提取協(xié)議頭中的 StreamID 進行請求和響應的配對
• 還有一種特殊情況即 HTTP 1.1 中的管道機制，他是一種偽并發(fā)協(xié)議，我們可以利用它的 FIFO 特點完成請求和響應的配對

Network Metrics

但是，在云原生環(huán)境下，僅僅只統(tǒng)計應用層 RED 往往不夠。例如我們會發(fā)現(xiàn)客戶端側看到的時延是 3 秒，而服務端側看到的時延是 3 毫秒；或者客戶端和服務端側都看不到有請求，但下游服務卻報錯了。針對這些場景，我們基于 Flow 數(shù)據(jù)計算得到了網(wǎng)絡層面的吞吐、異常、時延。業(yè)務開發(fā)發(fā)現(xiàn)時延高時，可以快速查看網(wǎng)絡層時延來判斷到底是業(yè)務自身的問題還是基礎設施問題；另外在發(fā)現(xiàn)請求報錯時可以快速查看是否建連或者傳輸異常了。

針對時延我們分的更細致，通過從 Packet Data 中重建 TCP 狀態(tài)機來更加精細的展現(xiàn)各個層面引入的時延。在生產環(huán)境中我們會發(fā)現(xiàn)高時延的原因一般分為幾個方面：

• 建連慢：由于防火墻、負載均衡、網(wǎng)關的影響，導致 TCP 建連過程慢，這一過程又進一步拆分為了到底是客戶側建連慢還是服務側建連慢
• 框架慢：由于業(yè)務代碼在建連后的慢處理，客戶端在建連后等待了一段時間才發(fā)送請求，這段等待時間我們會刻畫為客戶端等待時延，它能夠方面定位到底是框架/庫層面的問題，還是業(yè)務代碼的問題
• 系統(tǒng)慢：由于操作系統(tǒng)處理不及時，例如系統(tǒng)負載高等，對請求的 TCP ACK 回復慢，從而導致 TCP 無法高效增大窗口大小
• 傳輸慢：網(wǎng)絡重傳、零窗等也是導致高時延的一些可能原因

在云原生環(huán)境下，還有一個特點是網(wǎng)絡路徑非常長，例如兩個服務之間的通信可能依次經(jīng)過容器 Pod 網(wǎng)卡、容器 Node 網(wǎng)卡、KVM 主機網(wǎng)卡等。路徑的復雜性也是引發(fā)傳輸慢的主要原因。由于 DeepFlow 同時使用 cBPF，因此可以從所有中間轉發(fā)路徑中觀測到應用層和網(wǎng)絡層的時延，然后通過對比逐跳時延來定位到底是哪一跳開始出現(xiàn)了問題。

System Metrics

除了網(wǎng)絡層面以外，造成慢調用的還有一個重要原因是 IO 慢。例如 Client 訪問 DB 時可能出現(xiàn)時延抖動，而這些抖動通常是由 DB 的文件讀寫慢導致。再例如大數(shù)據(jù)場景下一批 Worker 中可能總有那么一兩個 Worker 完成的慢，排查后會發(fā)現(xiàn)通常是由于文件讀寫慢導致。這里 DeepFlow 的做法是觀測所有與應用調用相關的 IO 時延，并記錄所有的慢 IO 事件。實現(xiàn)層面，文件 IO 與 Socket IO 事件可通過 tracepoint/kprobe hook 同樣一組函數(shù)獲取到，通過 FD 的類型可以進行區(qū)分。依靠這樣的能力，我們能快速的定位到 deepflow-server 寫入 clickhouse-server 偶發(fā)性慢是由于文件 IO 時延抖動造成，且能定位到具體的文件路徑。

低版內核：最后我們總結一下本節(jié)。我們希望在低版本內核中 DeepFlow 也能展現(xiàn)更多的能力。以 Kernel 4.14 為界，DeepFlow 在 4.14 的環(huán)境下可以基于 eBPF 實現(xiàn)全功能，包括加密數(shù)據(jù)的觀測、應用進程的性能指標、系統(tǒng)層面文件 IO 性能指標，以及全自動的分布式追蹤能力。而在 4.14 以下的內核環(huán)境中，我們基于 cBPF 也實現(xiàn)了大部分的能力，包括對于明文協(xié)議、私有協(xié)議的觀測，對于壓縮協(xié)議部分頭部字段的觀測，以及對于應用性能、網(wǎng)絡性能指標的采集，對于性能指標的全棧路徑追蹤。

03｜eBPF 自動關聯(lián)服務和資源標簽

講到這里實際上我們整個目標只完成了一半。我們從原始數(shù)據(jù)中提取出來了指標、調用關系、調用鏈，但還需要以開發(fā)者熟悉的方式展現(xiàn)出來。Packet 和 Socket Data 中只有 IP 和端口號信息，這是開發(fā)和運維都無法理解的。我們希望所有的數(shù)據(jù)都能從實例、服務、業(yè)務等維度按需展示。

在這個問題上我們也遇到了一些挑戰(zhàn)：我會先介紹從哪里采集標簽，以及采集什么樣的標簽；然后討論輪詢采集的方式會帶來哪些問題；接下來我會介紹一下基于 eBPF 的事件觸發(fā)的方案，來避免輪詢的缺陷；最后同樣的也會介紹一下我們在低版本內核環(huán)境下的一些能力。

標簽數(shù)據(jù)：首先僅通過 IP 地址是不能完整關聯(lián)客戶端和服務端的服務信息的，這是因為實際環(huán)境中普遍存在 NAT，包括 SNAT、DNAT、FULLNAT 等。實際上通過單側的 IP Port 也難以準確關聯(lián)，這是因為 Client Port Reuse 也是一個普遍存在的現(xiàn)象。因此，在 DeepFlow 中使用五元組來將通信端點關聯(lián)至服務。具體來講，我們會通過 K8s apiserver 獲取 IP 對應的容器資源標簽；通過 CMDB 及腳本化的插件獲取 PID 對應的業(yè)務標簽信息；然后再依靠下面要講的一些機制將 IP Port 的五元組與 PID 關聯(lián)起來，最終實現(xiàn)資源、服務、業(yè)務標簽的自動注入。

輪詢方案：我們首先能想到的是通過輪詢 /proc/pid/net/ 文件夾來獲取 PID 與 Socket 五元組的關聯(lián)。每個 agent 獲取本機的關聯(lián)信息，并通過 server 交換得到全局的關聯(lián)信息，從而使得每個 agent 能獨立的為客戶端和服務端標注雙端的 PID 信息。

輪詢方案也會碰到一些挑戰(zhàn)，例如 LVS 場景下，/proc 下的 Socket 信息指向的是 LVS，但從業(yè)務上來講我們希望獲取 LVS 背后的 RS 的進程信息。DeepFlow 通過同步 LVS 轉發(fā)規(guī)則解決這個問題。具體來講，基于 LVS 規(guī)則和包頭中嵌入的 TOA（TCP Option Address）字段，可以快速的在 RS 上定位客戶端的 PID，并通過 LVS 轉發(fā)規(guī)則快速的在客戶端側定位服務端的 PID。

觸發(fā)方案：當時輪詢總會存在時間間隔，因此永遠無法解決短連接的監(jiān)控問題。在這方面 DeepFlow 也做了一些工作，這就是下面我們要介紹的觸發(fā)式方案。

受 TOA 的啟發(fā)，我們基于 eBPF 實現(xiàn)了一個 TOT（TCP Option Tracing）的機制，即在 TCP 包頭 Option 字段中嵌入額外的信息，表示發(fā)送方的 IP 和 PID。這樣的話我們就能將源發(fā)的進程信息告知對端了。為了實現(xiàn)這樣的機制，我們使用 eBPF sockops 和 tracepoint，一共 Hook 了五個函數(shù)。我們會在每個 TCP SYN、SYN-ACK 包中注入 TOT 信息，使得連接新建時即能標記進程信息。同時也會概率性的抽取 TCP PSH 包注入 TOT，使得對于長連接，即使 agent 的啟動時間滯后于業(yè)務進程，也能及時獲取到進程信息。

低版內核：同樣這里也分享一下我們在低版本內核上做的一些工作。首先輪詢的方案依靠掃描 /proc 文件夾實現(xiàn)，因此是能適配所有 2.6 的內核環(huán)境的。在 3.10 及以上的內核中，我們也提供了一個精巧的 ko 模塊來實現(xiàn) TOT 的注入，這個內核模塊僅有 227 行代碼，我們也進行了開源，歡迎大家使用。

04｜Demo – 持續(xù)觀測全鏈路壓測性能瓶頸

OTel Demo

最后通過一個 Demo 介紹一下這些工作的效果。我們仍然是以 OTel 的電商 Demo 為例，仍然是關閉了其中的所有 OTel Instrumentation。選擇這個 Demo 的理由在于，他是一個典型的微服務架構的應用，且盡力模擬了比較真實的電商場景，微服務的實現(xiàn)語言涵蓋了十二種之多，也包含了 PostgreSQL、Redis、Kafka、Envoy 等中間件。

首先我們可以看到，不修改代碼、不修改啟動參數(shù)、不重啟進程，我們已經(jīng)能自動繪制微服務粒度的全景應用。當我們注入一個 1.5K QPS 的壓力時，能清晰的在拓撲中看到瓶頸鏈路。沿著 frontend 服務一路往下，也能快速的定位瓶頸服務 ProductCatalog。接下來我們分為三次，分別將 ProductCatalog 擴容至 2x、4x、8x 副本數(shù)，擴容的過程中也可清晰的看到瓶頸鏈路在逐漸消失，知道最終所有服務的時延恢復正常。

除了這個 Demo 意外，這里也分享幾個我們在客戶處的實戰(zhàn)案例：

• 某造車新勢力客戶，使用 DeepFlow 從數(shù)萬 Pod 中在 5 分鐘內定位 RDS 訪問量最大的 Pod、所屬服務、負責該服務的團隊。
• 某股份制銀行客戶，信用卡核心業(yè)務上線受阻，壓測性能上不去，使用 DeepFlow 在 5 分鐘內發(fā)現(xiàn)兩個服務之間 API 網(wǎng)關是性能瓶頸，進而發(fā)現(xiàn)緩存設置不合理。
• 某互聯(lián)網(wǎng)客戶，使用 DeepFlow 在 5 分鐘內定位服務間 K8s CNI 性能瓶頸，識別由于環(huán)路造成的某個服務上下云訪問時延周期性飆升的問題，云廠商兩周無解。
• 某證券客戶，使用 DeepFlow 在 5 分鐘內定位 ARP 故障導致 Pod 無法上線的問題，「瞬間」結束業(yè)務、系統(tǒng)、網(wǎng)絡多部門「會商」。
• 某基礎設施軟件客戶，使用 DeepFlow 在 5 分鐘內定位 Rust 客戶端使用 Tokio 不合理導致的 gRPC 偶發(fā)性超大時延，終結了 QA 及多個開發(fā)團隊之間踢來踢去的 Bug。
• 某四大行客戶，使用 DeepFlow 在 5 分鐘內定位某個 NFVGW 實例對特定服務流量不轉發(fā)導致的客戶端頻繁重試。

從這些案例中我們能發(fā)現(xiàn)，依靠 eBPF 技術的零侵擾特性，我們能完整的覆蓋應用的全景調用拓撲，且能展現(xiàn)任意調用路徑中的全棧性能指標。得益于這些可觀測性能力，我們能快速的定位 RDS、API 網(wǎng)關、K8s CNI、ARP 故障、Rust Tokio 庫、NFVGW 造成的故障。

Distributed Profile

這是最后一張PPT，我想和大家分享一下 DeepFlow 對可觀測性的更多思考。在傳統(tǒng) APM 中，我們通常使用 Span 之間的關聯(lián)關系以火焰圖的方式展現(xiàn)一次分布式調用（Trace），也會講所有的 Span 聚合為指標來展現(xiàn)所有服務之間的應用拓撲。我們發(fā)現(xiàn)拓撲展現(xiàn)了所有調用的數(shù)據(jù)，而追蹤展現(xiàn)了一個調用的數(shù)據(jù)，它們二者恰恰是取了兩個極端。DeepFlow 目前正在探索，中間是否有一個折中的點，他們展示一組聚合的火焰圖或拓撲圖，有點類似于單個進程的 Profile，但是用于分布式應用的場景，我們稱它為 Distributed Profile。我們相信這樣的折中會帶來效率的提升，它不香所有調用聚合而成的拓撲，會有太多噪聲；也不像單一請求展示出來的 Trace，問題排查需要一個一個 Trace 的看。

而 eBPF，正是絕佳的實現(xiàn) Distributed Profile 的技術手段，請期待后續(xù)我們進一步的分享。

05｜什么是 DeepFlow

DeepFlow[3] 是一款開源的高度自動化的可觀測性平臺，是為云原生應用開發(fā)者建設可觀測性能力而量身打造的全棧、全鏈路、高性能數(shù)據(jù)引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技術，創(chuàng)新的實現(xiàn)了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心機制，幫助開發(fā)者提升埋點插碼的自動化水平，降低可觀測性平臺的運維復雜度。利用 DeepFlow 的可編程能力和開放接口，開發(fā)者可以快速將其融入到自己的可觀測性技術棧中。

GitHub 地址：https://github.com/deepflowio/deepflow

訪問 DeepFlow Demo[4]，體驗高度自動化的可觀測性新時代。

參考資料

[1]回看鏈接: https://www.bilibili.com/video/BV1B14y1f7UB/

[2]PPT下載: http://yunshan-guangzhou.oss-cn-beijing.aliyuncs.com/yunshan-ticket/pdf/1a1847b242ae7c16d53f0af31d9c6aa4_20230509140119.pdf

[3]DeepFlow: https://github.com/deepflowio/deepflow

[4]DeepFlow Demo: https://deepflow.yunshan.net/docs/zh/install/overview/