使用APM無法實(shí)現(xiàn)真正可觀測性的原因

作者介紹：向陽，清華大學(xué)博士，云杉網(wǎng)絡(luò)研發(fā) VP，曾獲網(wǎng)絡(luò)測量領(lǐng)域國際頂會 ACM IMC 頒發(fā)的第一屆 Community Contribution Award，現(xiàn)負(fù)責(zé)云原生可觀測性產(chǎn)品 DeepFlow。產(chǎn)品基于 eBPF 等新技術(shù)幫助云原生應(yīng)用快速實(shí)現(xiàn)零侵?jǐn)_、全棧的可觀測性，相關(guān)論文被通信領(lǐng)域國際頂會 ACM SIGCOMM 2023 主會錄用。

控制理論中的可觀測性是指：系統(tǒng)可以由其外部輸出確定其內(nèi)部狀態(tài)的程度。在復(fù)雜 IT 系統(tǒng)中，具備可觀測性是為了讓系統(tǒng)能達(dá)到某個預(yù)定的穩(wěn)定性、錯誤率目標(biāo)。隨著微服務(wù)數(shù)量的急速膨脹和云原生基礎(chǔ)設(shè)施的快速演進(jìn)，建設(shè)可觀測性已經(jīng)成為了保障業(yè)務(wù)穩(wěn)定性的必要條件。

然而，傳統(tǒng)的 APM 無法實(shí)現(xiàn)真正的可觀測性：一方面插樁行為已經(jīng)修改了原程序，邏輯上已無法實(shí)現(xiàn)原程序的可觀測性；另一方面云原生基礎(chǔ)設(shè)施組件越來越多，基礎(chǔ)服務(wù)難以插樁導(dǎo)致觀測盲點(diǎn)越來越多。實(shí)際上，插樁的方式在金融、電信等重要行業(yè)的核心業(yè)務(wù)系統(tǒng)中幾乎無法落地。eBPF 由于其零侵?jǐn)_的優(yōu)勢，避免了 APM 插樁的缺點(diǎn)，是云原生時代實(shí)現(xiàn)可觀測性的關(guān)鍵技術(shù)。

本文依次論述 APM 無法實(shí)現(xiàn)真正可觀測性的原因，分析為什么 eBPF 是可觀測性的關(guān)鍵技術(shù)，介紹 DeepFlow 基于 eBPF 的三大核心功能，并進(jìn)一步闡述如何向 eBPF 的觀測數(shù)據(jù)中注入業(yè)務(wù)語義。在此之后，本文分享了 DeepFlow 用戶的九大類真實(shí)使用案例，總結(jié)了用戶在采用 eBPF 技術(shù)前的常見疑問。最后，本文進(jìn)一步分析了 eBPF 對新技術(shù)迭代的重大意義。

01: 使用 APM 無法實(shí)現(xiàn)真正的可觀測性

APM 希望通過代碼插樁（Instrumentation）的方式來實(shí)現(xiàn)應(yīng)用程序的可觀測性。利用插樁，應(yīng)用程序可以暴露非常豐富的觀測信號，包括指標(biāo)、追蹤、日志、函數(shù)性能剖析等。然而插樁的行為實(shí)際上改變了原始程序的內(nèi)部狀態(tài)，從邏輯上并不符合可觀測性「從外部數(shù)據(jù)確定內(nèi)部狀態(tài)」的要求。在金融、電信等重要行業(yè)的核心業(yè)務(wù)系統(tǒng)中，APM Agent 落地非常困難。進(jìn)入到云原生時代，這個傳統(tǒng)方法也面臨著更加嚴(yán)峻的挑戰(zhàn)。總的來講，APM 的問題主要體現(xiàn)在兩個方面：Agent 的侵?jǐn)_性導(dǎo)致難以落地，觀測盲點(diǎn)導(dǎo)致無法定界。

第一，探針侵?jǐn)_性導(dǎo)致難以落地。插樁的過程需要對應(yīng)用程序的源代碼進(jìn)行修改，重新發(fā)布上線。即使例如 Java Agent 這類字節(jié)碼增強(qiáng)技術(shù)，也需要修改應(yīng)用程序的啟動參數(shù)并重新發(fā)版。然而，對應(yīng)用代碼的改造還只是第一道關(guān)卡，通常落地過程中還會碰到很多其他方面的問題：

代碼沖突：當(dāng)你為了分布式追蹤、性能剖析、日志甚至服務(wù)網(wǎng)格等目的注入了多個 Java Agent 時，是否經(jīng)常遇到不同 Agent 之間產(chǎn)生的運(yùn)行時沖突？當(dāng)你引入一個可觀測性的 SDK 時，是否遇到過依賴庫版本沖突導(dǎo)致無法編譯成功？業(yè)務(wù)團(tuán)隊數(shù)量越多時，這類兼容性問題的爆發(fā)會越為明顯。

維護(hù)困難：如果你負(fù)責(zé)維護(hù)公司的 Java Agent 或 SDK，你的更新頻率能有多高？就在此時，你們公司的生產(chǎn)環(huán)境中有多少個版本的探針程序？讓他們更新到同一個版本需要花多長時間？你需要同時維護(hù)多少種語言的探針程序？當(dāng)企業(yè)的微服務(wù)框架、RPC 框架無法統(tǒng)一時，這類維護(hù)問題還將會更加嚴(yán)重。

邊界模糊：所有的插樁代碼嚴(yán)絲合縫的進(jìn)入了業(yè)務(wù)代碼的運(yùn)行邏輯中，不分你我、不受控制。這導(dǎo)致當(dāng)出現(xiàn)性能衰減或運(yùn)行錯誤時，插樁代碼往往難辭其咎。即使探針已經(jīng)經(jīng)過了長時間的實(shí)戰(zhàn)打磨，遇到問題時也免不了要求排除嫌疑。

實(shí)際上，這也是為什么侵?jǐn)_性的插樁方案少見于成功的商業(yè)產(chǎn)品，更多見于活躍的開源社區(qū)。OpenTelemetry、SkyWalking 等社區(qū)的活躍正是佐證。而在部門分工明確的大型企業(yè)中，克服協(xié)作上的困難是一個技術(shù)方案能夠成功落地永遠(yuǎn)也繞不開的坎。特別是在金融、電信、電力等承載國計民生的關(guān)鍵行業(yè)中，部門之間的職責(zé)區(qū)分和利益沖突往往會使得落地插樁式的解決方案成為「不可能」。即使是在開放協(xié)作的互聯(lián)網(wǎng)企業(yè)中，也少不了開發(fā)人員對插樁的不情愿、運(yùn)維人員在出現(xiàn)性能故障時的背鍋等問題。在經(jīng)歷了長久的努力之后人們已經(jīng)發(fā)現(xiàn)，侵入性的解決方案僅僅適合于每個業(yè)務(wù)開發(fā)團(tuán)隊自己主動引入、自己維護(hù)各類 Agent 和 SDK 的版本、自己對性能隱患和運(yùn)行故障的風(fēng)險負(fù)責(zé)。當(dāng)然，我們也看到了一些得益于基建高度統(tǒng)一而取得成功的大型互聯(lián)網(wǎng)公司案例，例如 Google 就在 2010 年的 Dapper 論文中坦言：

True application-level transparency, possibly our most challenging design goal, was achieved by restricting Dapper’s core tracing instrumentation to a small corpus of ubiquitous threading, control flow, and RPC library code.

再例如字節(jié)跳動在 2022 年的對外分享《分布式鏈路追蹤在字節(jié)跳動的實(shí)踐》中也表示：

得益于長期的統(tǒng)一基建工作，字節(jié)全公司范圍內(nèi)的所有微服務(wù)使用的底層技術(shù)方案統(tǒng)一度較高。絕大部分微服務(wù)都部署在公司統(tǒng)一的容器平臺上，采用統(tǒng)一的公司微服務(wù)框架和網(wǎng)格方案，使用公司統(tǒng)一提供的存儲組件及相應(yīng) SDK。高度的一致性對于基礎(chǔ)架構(gòu)團(tuán)隊建設(shè)公司級別的統(tǒng)一鏈路追蹤系統(tǒng)提供了有利的基礎(chǔ)。

第二，觀測盲點(diǎn)導(dǎo)致無法定界。即使 APM 已經(jīng)在企業(yè)內(nèi)落地，我們還是會發(fā)現(xiàn)排障邊界依然難以界定，特別是在云原生基礎(chǔ)設(shè)施中。這是因?yàn)殚_發(fā)和運(yùn)維往往使用不同的語言在對話，例如當(dāng)調(diào)用時延過高時開發(fā)會懷疑網(wǎng)絡(luò)慢、網(wǎng)關(guān)慢、數(shù)據(jù)庫慢、服務(wù)端慢，但由于全?？捎^測性的缺乏，網(wǎng)絡(luò)、網(wǎng)關(guān)、數(shù)據(jù)庫給出的應(yīng)答通常是網(wǎng)卡沒丟包、進(jìn)程 CPU 不高、DB 沒有慢日志、服務(wù)端時延很低等一大堆毫無關(guān)聯(lián)的指標(biāo)，仍然解決不了問題。定界是整個故障處理流程中最關(guān)鍵的一環(huán)，它的效率至關(guān)重要。

定界在故障處理流程中的核心作用

這里我們想澄清兩個概念：排障邊界和職責(zé)邊界。雖然開發(fā)的職責(zé)邊界是應(yīng)用程序本身，但排障邊界卻需要延展到網(wǎng)絡(luò)傳輸上。舉個例子：微服務(wù)在請求 RDS 云服務(wù)時偶現(xiàn)高達(dá) 200ms 的時延，如果開發(fā)以此為依據(jù)向云服務(wù)商提交工單，得到的應(yīng)答大概率會是「RDS 沒有觀察到慢日志，請自查」。我們在很多客戶處碰到了大量此類案例，根因有的是 RDS 前的 SLB 導(dǎo)致、有的是 K8s Node 的 SNAT 導(dǎo)致，背后的原因千奇百怪，但若不能在第一時間完成故障定界，都會導(dǎo)致租戶（開發(fā)）和云服務(wù)商（基礎(chǔ)設(shè)施）之間長達(dá)數(shù)天乃至數(shù)周的工單拉鋸戰(zhàn)。從排障邊界的角度來講，若開發(fā)能給出「網(wǎng)卡發(fā)送請求到收到響應(yīng)之間的時延高達(dá) 200ms」，就能快速完成定界，推動云服務(wù)商排查。找對了正確的人，之后的問題解決一般都非?？?。我們在后文也會分享幾個真實(shí)案例。

不同角色的排障邊界

上圖中我們對不同場景下的排障邊界進(jìn)行了總結(jié)：如果你是一個業(yè)務(wù)開發(fā)工程師，除了業(yè)務(wù)本身以外，還應(yīng)該關(guān)心系統(tǒng)調(diào)用和網(wǎng)絡(luò)傳輸過程；如果你是一個 Serverless 租戶，你可能還需要關(guān)注服務(wù)網(wǎng)格邊車及其網(wǎng)絡(luò)傳輸；如果你直接使用虛擬機(jī)或自建 K8s 集群，那么容器網(wǎng)絡(luò)是需要重點(diǎn)關(guān)注的問題點(diǎn)，特別還需注意 K8s 中的 CoreDNS、Ingress Gateway 等基礎(chǔ)服務(wù)；如果你是私有云的計算服務(wù)管理員，應(yīng)該關(guān)心 KVM 宿主機(jī)上的網(wǎng)絡(luò)性能；如果你是私有云的網(wǎng)關(guān)、存儲、安全團(tuán)隊，也需要關(guān)注服務(wù)節(jié)點(diǎn)上的系統(tǒng)調(diào)用和網(wǎng)絡(luò)傳輸性能。實(shí)際上更為重要的是，用于故障定界的數(shù)據(jù)應(yīng)該使用類似的語言進(jìn)行陳述：一次應(yīng)用調(diào)用在整個全棧路徑中，每一跳到底消耗了多長時間。通過上述分析我們發(fā)現(xiàn)，開發(fā)者通過插樁提供的觀測數(shù)據(jù)，可能只占了整個全棧路徑的 1/4。在云原生時代，單純依靠 APM 來解決故障定界，本身就是妄念。

02: 為什么 eBPF 是可觀測性的關(guān)鍵技術(shù)

本文假設(shè)你對 eBPF 有了基礎(chǔ)的了解，它是一項安全、高效的通過在沙箱中運(yùn)行程序以實(shí)現(xiàn)內(nèi)核功能擴(kuò)展的技術(shù)，是對傳統(tǒng)的修改內(nèi)核源代碼和編寫內(nèi)核模塊方式的革命性創(chuàng)新。你可訪問 ebpf.io 以了解更多的 eBPF 相關(guān)知識，本文聚焦于討論 eBPF 對云原生應(yīng)用可觀測性的革命性意義。

eBPF 程序是事件驅(qū)動的，當(dāng)內(nèi)核或用戶程序經(jīng)過一個 eBPF Hook 時，對應(yīng) Hook 點(diǎn)上加載的 eBPF 程序就會被執(zhí)行。Linux 內(nèi)核中預(yù)定義了一系列常用的 Hook 點(diǎn)，你也可以利用 kprobe 和 uprobe 技術(shù)動態(tài)增加內(nèi)核和應(yīng)用程序的自定義 Hook 點(diǎn)。得益于 Just-in-Time (JIT) 技術(shù)，eBPF 代碼的運(yùn)行效率可媲美內(nèi)核原生代碼和內(nèi)核模塊。得益于 Verification 機(jī)制，eBPF 代碼將會安全的運(yùn)行，不會導(dǎo)致內(nèi)核崩潰或進(jìn)入死循環(huán)。

https://ebpf.io/what-is-ebpf/#hook-overview

回到可觀測性上，沙箱機(jī)制是 eBPF 有別于 APM 插樁機(jī)制的核心所在，「沙箱」在 eBPF 代碼和應(yīng)用程序的代碼之間劃上了一道清晰的界限，使得我們能在不對應(yīng)用程序做任何修改的前提下，通過獲取外部數(shù)據(jù)就能確定其內(nèi)部狀態(tài)。下面我們來詳細(xì)分析下為何 eBPF 是解決 APM 代碼插樁缺陷的絕佳解決方案：

第一，零侵?jǐn)_解決落地難的問題。由于 eBPF 程序無需修改應(yīng)用程序代碼，因此不會有類似 Java Agent 的運(yùn)行時沖突和 SDK 的編譯時沖突，解決了代碼沖突問題；由于運(yùn)行 eBPF 程序無需改變和重啟應(yīng)用進(jìn)程，不需要應(yīng)用程序重新發(fā)版，不會有 Java Agent 和 SDK 的版本維護(hù)痛苦，解決了維護(hù)困難問題；由于 eBPF 在 JIT 技術(shù)和 Verification 機(jī)制的保障下高效安全的運(yùn)行，因此不用擔(dān)心會引發(fā)應(yīng)用進(jìn)程預(yù)期之外的性能衰減或運(yùn)行時錯誤，解決了邊界模糊問題。另外從管理層面，由于只需要在每個主機(jī)上運(yùn)行一個獨(dú)立的 eBPF Agent 進(jìn)程，使得我們可以對它的 CPU 等資源消耗進(jìn)行單獨(dú)的、精確的控制。

第二，全棧能力解決故障定界難的問題。eBPF 的能力覆蓋了從內(nèi)核到用戶程序的每一個層面，因此我們得以跟蹤一個請求從應(yīng)用程序出發(fā)，經(jīng)過系統(tǒng)調(diào)用、網(wǎng)絡(luò)傳輸、網(wǎng)關(guān)服務(wù)、安全服務(wù)，到達(dá)數(shù)據(jù)庫服務(wù)或?qū)Χ宋⒎?wù)的全棧路徑，提供充足的中立觀測數(shù)據(jù)，快速完成故障的定界。

然而，eBPF 并不是一個易于掌握的技術(shù)，它需要開發(fā)者有一定的內(nèi)核編程基礎(chǔ)，它獲取的原始數(shù)據(jù)缺乏結(jié)構(gòu)化信息。下文將會以我們的產(chǎn)品 DeepFlow 為例，介紹如何掃清這些障礙，充分發(fā)揮 eBPF 對可觀測性工程的關(guān)鍵作用。

03: DeepFlow 基于 eBPF 的三大核心功能

DeepFlow [GitHub] 旨在為復(fù)雜的云原生應(yīng)用提供簡單可落地的深度可觀測性。DeepFlow 基于 eBPF 和 Wasm 技術(shù)實(shí)現(xiàn)了零侵?jǐn)_（Zero Code）、全棧（Full Stack）的指標(biāo)、追蹤、調(diào)用日志、函數(shù)剖析數(shù)據(jù)采集，并通過智能標(biāo)簽技術(shù)實(shí)現(xiàn)了所有數(shù)據(jù)的全關(guān)聯(lián)（Universal Tagging）和高效存取。使用 DeepFlow，可以讓云原生應(yīng)用自動具有深度可觀測性，從而消除開發(fā)者不斷插樁的沉重負(fù)擔(dān)，并為 DevOps/SRE 團(tuán)隊提供從代碼到基礎(chǔ)設(shè)施的監(jiān)控及診斷能力。

DeepFlow 基于 eBPF 技術(shù)實(shí)現(xiàn)云原生應(yīng)用的零侵?jǐn)_可觀測性

通過利用 eBPF 和 cBPF 采集應(yīng)用函數(shù)、系統(tǒng)調(diào)用函數(shù)、網(wǎng)卡收發(fā)的數(shù)據(jù)，DeepFlow 首先聚合成 TCP/UDP 流日志（Flow Log）；通過應(yīng)用協(xié)議識別，DeepFlow 聚合得到應(yīng)用調(diào)用日志（Request Log），進(jìn)而計算出全棧的 RED（Request/Error/Delay）性能指標(biāo)，并關(guān)聯(lián)調(diào)用日志實(shí)現(xiàn)分布式追蹤。除此之外，DeepFlow 在流日志聚合過程中還計算了 TCP 吞吐、時延、建連異常、重傳、零窗等網(wǎng)絡(luò)層性能指標(biāo)，以及通過 Hook 文件讀寫操作計算了 IO 吞吐和時延指標(biāo)，并將所有這些指標(biāo)關(guān)聯(lián)至每個調(diào)用日志上。另外，DeepFlow 也支持通過 eBPF 獲取每個進(jìn)程的 OnCPU、OffCPU 函數(shù)火焰圖，以及分析 TCP 包繪制 Network Profile 時序圖。所有這些能力最終體現(xiàn)為三大核心功能：

Universal Map for Any Service，任意服務(wù)的全景圖

Distributed Tracing for Any Request，任意調(diào)用的分布式追蹤

Continuous Profiling for Any Function，任何函數(shù)的持續(xù)性能剖析

DeepFlow 基于 eBPF 的三大核心功能

核心功能一：任意服務(wù)的全景圖。全景圖直接體現(xiàn)出了 eBPF 零侵?jǐn)_的優(yōu)勢，對比 APM 有限的覆蓋能力，所有的服務(wù)都能出現(xiàn)在全景圖中。但 eBPF 獲取的調(diào)用日志不能直接用于拓?fù)湔宫F(xiàn)，DeepFlow 為所有的數(shù)據(jù)注入了豐富的標(biāo)簽，包括云資源屬性、K8s 資源屬性、自定義 K8s 標(biāo)簽等。通過這些標(biāo)簽可以快速過濾出指定業(yè)務(wù)的全景圖，并且可以按不同標(biāo)簽分組展示，例如 K8s Pod、K8s Deployment、K8s Service、自定義標(biāo)簽等。全景圖不僅描述了服務(wù)之間的調(diào)用關(guān)系，還展現(xiàn)了調(diào)用路徑上的全棧性能指標(biāo)，例如下圖右側(cè)為兩個 K8s 服務(wù)的進(jìn)程在相互訪問時的逐跳時延變化。我們可以很快的發(fā)現(xiàn)性能瓶頸到底位于業(yè)務(wù)進(jìn)程、容器網(wǎng)絡(luò)、K8s 網(wǎng)絡(luò)、KVM 網(wǎng)絡(luò)還是 Underlay 網(wǎng)絡(luò)。充足的中立觀測數(shù)據(jù)是快速定界的必要條件。

DeepFlow 的全景圖對比 APM Agent 獲取的拓?fù)鋱D

核心功能二：任意調(diào)用的分布式追蹤。零侵?jǐn)_的分布式追蹤（AutoTracing）是 DeepFlow 中的一個重大創(chuàng)新，在通過 eBPF 和 cBPF 采集調(diào)用日志時，DeepFlow 基于系統(tǒng)調(diào)用上下文計算出了 syscall_trace_id、thread_id、goroutine_id、cap_seq、tcp_seq 等信息，無需修改應(yīng)用代碼、無需注入 TraceID、SpanID 即可實(shí)現(xiàn)分布式追蹤。目前 DeepFlow 除了跨線程（通過內(nèi)存 Queue 或 Channel 傳遞信息）和異步調(diào)用以外，都能實(shí)現(xiàn)零侵?jǐn)_的分布式追蹤。此外也支持解析應(yīng)用注入的唯一 Request ID（例如幾乎所有網(wǎng)關(guān)都會注入 X-Request-ID）來解決跨線程和異步的問題。下圖對比了 DeepFlow 和 APM 的分布式追蹤能力。APM 僅能對插樁的服務(wù)實(shí)現(xiàn)追蹤，常見的是利用 Java Agent 覆蓋 Java 服務(wù)。DeepFlow 使用 eBPF 實(shí)現(xiàn)了所有服務(wù)的追蹤，包括 Nginx 等 SLB、Spring Cloud Gateway 等微服務(wù)網(wǎng)關(guān)、Envoy 等 Service Mesh 邊車，以及 MySQL、Redis、CoreDNS 等基礎(chǔ)服務(wù)（包括它們讀寫文件的耗時），除此之外還覆蓋了 Pod NIC、Node NIC、KVM NIC、物理交換機(jī)等網(wǎng)絡(luò)傳輸路徑，更重要的是對 Java、Golang 以及所有語言都可無差別支持。

DeepFlow 和 APM 的分布式追蹤對比

注意 eBPF 和 APM 的分布式追蹤能力并不是矛盾的。APM 能用于追蹤應(yīng)用進(jìn)程內(nèi)部的函數(shù)調(diào)用路徑，也擅長于解決跨線程和異步場景。而 eBPF 有全局的覆蓋能力，能輕松覆蓋網(wǎng)關(guān)、基礎(chǔ)服務(wù)、網(wǎng)絡(luò)路徑、多語言服務(wù)。在 DeepFlow 中，我們支持調(diào)用 APM 的 Trace API 以展示 APM + eBPF 的全鏈路分布式追蹤圖，同時也對外提供了Trace Completion API使得 APM 可調(diào)用 DeepFlow 以獲取并關(guān)聯(lián) eBPF 的追蹤數(shù)據(jù)。

核心功能三：任意函數(shù)的持續(xù)性能剖析。通過獲取應(yīng)用程序的函數(shù)調(diào)用?？煺眨珼eepFlow 可繪制任意進(jìn)程的 CPU Profile，幫助開發(fā)者快速定位函數(shù)性能瓶頸。函數(shù)調(diào)用棧中除了包含業(yè)務(wù)函數(shù)以外，還可展現(xiàn)動態(tài)鏈接庫、內(nèi)核系統(tǒng)調(diào)用函數(shù)的耗時情況。除此之外，DeepFlow 在采集函數(shù)調(diào)用棧時生成了唯一標(biāo)識，可用于與調(diào)用日志相關(guān)聯(lián)，實(shí)現(xiàn)分布式追蹤和函數(shù)性能剖析的聯(lián)動。特別地，DeepFlow 還利用 cBPF 對網(wǎng)絡(luò)中的逐包進(jìn)行了分析，使得在低內(nèi)核環(huán)境中可以繪制每個 TCP 流的 Network Profile，剖析其中的建連時延、系統(tǒng)（ACK）時延、服務(wù)響應(yīng)時延、客戶端等待時延。使用 Network Profile 可推斷應(yīng)用程序中性能瓶頸的代碼范圍，我們在后文中也會分享相關(guān)案例。

DeepFlow 中的 CPU Profile 和 Network Profile

本文無法完整的解釋這些激動人心的特性背后的原理，DeepFlow 同時也是一個開源項目，您可以閱讀我們的 GitHub 代碼和文檔了解更多信息，也可閱讀我們發(fā)表在網(wǎng)絡(luò)通信領(lǐng)域頂級會議ACM SIGCOMM 2023上的論文 Network-Centric Distributed Tracing with DeepFlow: Troubleshooting Your Microservices in Zero Code。

04: 向 eBPF 觀測數(shù)據(jù)中注入業(yè)務(wù)語義

使用 APM Agent 的另一個訴求是向數(shù)據(jù)中注入業(yè)務(wù)語義，例如一個調(diào)用關(guān)聯(lián)的用戶信息、交易信息，以及服務(wù)所在的業(yè)務(wù)模塊名稱等。從 eBPF 采集到的原始字節(jié)流中很難用通用的方法提取業(yè)務(wù)語義，在 DeepFlow 中我們實(shí)現(xiàn)了兩個插件機(jī)制來彌補(bǔ)這個不足：通過 Wasm Plugin 注入調(diào)用粒度的業(yè)務(wù)語義，通過 API 注入服務(wù)粒度的業(yè)務(wù)語義。

第一、通過 Wasm Plugin 注入調(diào)用粒度的業(yè)務(wù)語義：DeepFlow Agent 內(nèi)置了常見應(yīng)用協(xié)議的解析能力，且在持續(xù)迭代增加中，下圖中藍(lán)色部分均為原生支持的協(xié)議。我們發(fā)現(xiàn)實(shí)際業(yè)務(wù)環(huán)境中情況會更加復(fù)雜：開發(fā)會堅持返回 HTTP 200 同時將錯誤信息放到自定義 JSON 結(jié)構(gòu)中，大量 RPC 的 Payload 部分使用 Protobuf、Thrift 等依賴 Schema 進(jìn)行解碼的序列化方式，調(diào)用的處理流程中發(fā)生了跨線程導(dǎo)致 eBPF AutoTracing 斷鏈。為了解決這些問題 DeepFlow 提供了 Wasm Plugin 機(jī)制，支持開發(fā)者對 Pipeline 中的 ProtocolParser 進(jìn)行增強(qiáng)。

利用 DeepFlow Wasm Plugin 注入調(diào)用粒度的業(yè)務(wù)語義

實(shí)際上，我們也觀察到在金融、電信、游戲等行業(yè)中，已經(jīng)存在了「天然」的分布式追蹤標(biāo)記，例如金融業(yè)務(wù)中的全局交易流水號，電信核心網(wǎng)中的呼叫 ID、游戲業(yè)務(wù)中的業(yè)務(wù)請求 ID 等等。這些 ID 會攜帶在所有調(diào)用中，但具體的位置是業(yè)務(wù)自身決定的。通過 Wasm Plugin 釋放的靈活性，開發(fā)者可以很容易的編寫插件支持將這些信息提取為 TraceID。

第二、通過 API 注入服務(wù)粒度的業(yè)務(wù)語義：默認(rèn)情況下，DeepFlow 的 SmartEncoding 機(jī)制會自動為所有觀測信號注入云資源、容器 K8s 資源、K8s 自定義 Label 標(biāo)簽。然而這些標(biāo)簽體現(xiàn)的只是應(yīng)用層面的語義，為了幫助用戶將 CMDB 等系統(tǒng)中的業(yè)務(wù)語義注入到觀測數(shù)據(jù)中，DeepFlow 提供了一套用于業(yè)務(wù)標(biāo)簽注入的 API。

05: DeepFlow 用戶的真實(shí)使用案例

在本章節(jié)中，我們將為大家分享 DeepFlow 用戶的九大類實(shí)戰(zhàn)案例。這些案例都是一些難以提前預(yù)料的疑難雜癥，我們將會看到在僅有 APM 數(shù)據(jù)時，它們通常持續(xù)了數(shù)天甚至數(shù)周都還找不到方向，而依靠 eBPF 的能力往往能在 5 分鐘之內(nèi)完成故障定界。在開始介紹它們之前我還想澄清一下，這并不意味著 eBPF 的能力只擅長于解決疑難雜癥，我們現(xiàn)在已經(jīng)知道 eBPF 能夠零侵?jǐn)_的采集 Metrics、Request Logs、Profiles 等觀測信號，DeepFlow 也已經(jīng)基于這些信號實(shí)現(xiàn)了通用的全景圖（包括性能指標(biāo)、調(diào)用日志等）、分布式追蹤、持續(xù)性能剖析功能。

第一類案例，快速定位引發(fā)問題的服務(wù)：

案例 1：5 分鐘定位訪問共享服務(wù)的 Top 客戶端。MySQL、Redis、Consul 等基礎(chǔ)設(shè)施通常被很多微服務(wù)共享使用，當(dāng)它們的負(fù)載過高時通常很難判斷是哪些客戶端造成的。這是因?yàn)槿萜?Pod 訪問這些共享服務(wù)時通常會做 SNAT，服務(wù)端看到的是容器節(jié)點(diǎn)的 IP；非容器環(huán)境下每個主機(jī)上也會有大量進(jìn)程共享使用主機(jī)的 IP?？梢韵胂髲姆?wù)端的調(diào)用日志中分析 IP 地址是十分低效的，而我們也不能寄期望于所有客戶端都注入了 APM Agent。使用 DeepFlow，我們的一個大型銀行客戶在 5 分鐘內(nèi)從近十萬個 Pod 中快速定位了請求 RDS 集群最高頻的微服務(wù)，我們的一個智能汽車客戶在 5 分鐘內(nèi)從上萬個 Pod 中快速定位了請求 Consul 最高頻的微服務(wù)。

案例 2：5 分鐘定位被忽視的共享服務(wù)。DeepFlow 的一個大型銀行客戶在進(jìn)行「分布式核心交易系統(tǒng)」上線測試時，發(fā)現(xiàn)由物理環(huán)境遷移到私有云上的交易系統(tǒng)性能非常差。經(jīng)過了兩周的排查、在注入了一大堆 APM Agent 以后，最終只能定位到問題位于名為cr****rs的服務(wù)訪問授權(quán)交易服務(wù)au****in的鏈路上，但這兩個服務(wù)在遷移上云之前沒有任何性能問題。開發(fā)團(tuán)隊一度開始懷疑私有云基礎(chǔ)設(shè)施，但沒有任何數(shù)據(jù)支撐。毫無頭緒時找到了 DeepFlow 團(tuán)隊，在部署 eBPF Agent 以后所有微服務(wù)之間的訪問關(guān)系和性能指標(biāo)全部呈現(xiàn)在了眼前，立即發(fā)現(xiàn)了在cr****rs訪問授權(quán)交易服務(wù)au****in時，還會經(jīng)過 Spring Cloud Gateway，而后者正在以極高的速率請求服務(wù)注冊中心 Consul。至此問題明確了，這是由于網(wǎng)關(guān)的緩存配置不合理，導(dǎo)致服務(wù)注冊中心成為了瓶頸。?案例 3：5 分鐘定位被忽視的背景壓力。在軟件開發(fā)過程中，壓力測試環(huán)境通常由多人共享，甚至開發(fā)、測試等多個團(tuán)隊也會使用同一套壓測環(huán)境。DeepFlow 的一個智能汽車客戶的測試人員在壓測某服務(wù)中，發(fā)現(xiàn)總是有少量的 HTTP 5XX 錯誤出現(xiàn)，而這將直接導(dǎo)致一次壓測結(jié)果作廢。正當(dāng)測試人員一籌莫展時，打開 DeepFlow 全景圖后馬上發(fā)現(xiàn)還有其他服務(wù)正在以不可忽視的速率訪問著被測服務(wù)。

快速定位引發(fā)問題的服務(wù)

第二類案例，快速定界訪問托管服務(wù)的故障：

?案例 1：5 分鐘定界托管云服務(wù)故障- SLB 會話遷移。由于托管服務(wù)無法插樁，以往通常會給故障排查帶來困難。DeepFlow 的一個智能汽車客戶，充電業(yè)務(wù)每 10min 發(fā)生一次高時延現(xiàn)象。通過 APM Agent 只能定位到問題由充電核心服務(wù)訪問 RDS 導(dǎo)致，但公有云服務(wù)商在仔細(xì)檢查慢日志和 RDS 性能指標(biāo)之后關(guān)閉了工單，因?yàn)闆]有發(fā)現(xiàn)任何異常。這個問題持續(xù)了一周仍未解決，而通過 DeepFlow 的全棧指標(biāo)數(shù)據(jù)，清晰的看到故障發(fā)生時從系統(tǒng)調(diào)用、Pod 網(wǎng)卡、Node 網(wǎng)卡觀測到的 RDS 訪問時延均超過了 200ms，并伴隨著網(wǎng)絡(luò)指標(biāo)中的「服務(wù)端 RST」數(shù)量激增。這些數(shù)據(jù)使得公有云服務(wù)商重新開始排查此問題，最終發(fā)現(xiàn) RDS 之前的 SLB 集群在高并發(fā)時觸發(fā)會話遷移導(dǎo)致了此問題?？梢钥吹饺珬？捎^測性是跨團(tuán)隊排查問題的關(guān)鍵。

?案例 2：5 分鐘定界托管云服務(wù)故障- K8s SNAT 沖突。這個案例中同樣也出現(xiàn)了 SLB，但根因大不相同。DeepFlow 的一個智能汽車客戶，車控服務(wù)在訪問賬戶服務(wù)時偶發(fā)超時，每個 Pod 每天發(fā)生 7 次。公有云服務(wù)商同樣也沒有看到任何 SLB 異常指標(biāo)，此工單持續(xù)一個月仍未解決。查看 DeepFlow 全景圖之后又一次快速完成了定界，可以看到故障發(fā)生時網(wǎng)絡(luò)指標(biāo)中的「建連異常」數(shù)量激增，進(jìn)一步查看關(guān)聯(lián)的流日志發(fā)現(xiàn)此時 TCP 連接的失敗原因?yàn)椤窼NAT 端口沖突」。可以看到即使對于「沒有調(diào)用日志」的超時類故障，利用全棧性能指標(biāo)也能快速定界故障原因。

快速定界訪問托管服務(wù)的故障

第三類案例，快速定界各類網(wǎng)關(guān)和云基礎(chǔ)設(shè)施的問題：

?案例 1：5 分鐘定界造成性能瓶頸或故障的網(wǎng)關(guān)。為了集中實(shí)現(xiàn)負(fù)載均衡、安全審計、微服務(wù)拆分、限流和熔斷等功能，云原生基礎(chǔ)設(shè)施中通常會部署各類網(wǎng)關(guān)。DeepFlow 的一個游戲客戶使用 KNative 作為 Serverless 基礎(chǔ)設(shè)施，在該環(huán)境下任何一個客戶端在訪問微服務(wù)時，都要穿越 Envoy Ingress Gateway、K8s Service、Envoy Sidecar、Queue Sidecar 共四種網(wǎng)關(guān)。當(dāng)客戶端側(cè)的調(diào)用時延遠(yuǎn)高于服務(wù)端側(cè)的調(diào)用時延，或者發(fā)生 HTTP 5XX 調(diào)用故障時，以往客戶主要通過檢索日志文件、tcpdump 抓包來排查問題，而利用 DeepFlow 可以在 5 分鐘內(nèi)定位網(wǎng)關(guān)路徑上的性能瓶頸或故障位置。例如某一次就快速發(fā)現(xiàn)了 Envoy Sidecar 配置不合理導(dǎo)致的慢請求問題。

?案例 2：5 分鐘定界私有云基礎(chǔ)設(shè)施性能瓶頸。DeepFlow 的一個大型銀行客戶在「分布式核心交易系統(tǒng)」上線私有云之前進(jìn)行了大量的性能測試，期間發(fā)現(xiàn) K8s 集群中的微服務(wù)訪問裸金屬服務(wù)器上的 MySQL 服務(wù)時，客戶端側(cè)的時延（3ms）與 DBA 團(tuán)隊看到的時延（1ms）有較大的差距，這意味著整個過程中基礎(chǔ)設(shè)施的耗時占了 67%，但并不清楚具體是哪個環(huán)節(jié)引入的。通過 DeepFlow 可以看到，整個訪問過程中的主要時延消耗在 KVM 宿主機(jī)上。這些數(shù)據(jù)反饋到私有云供應(yīng)商以后進(jìn)行了快速的排查，發(fā)現(xiàn)該環(huán)境下宿主機(jī)使用了 ARM CPU 和 SRIOV 網(wǎng)卡，并開啟了 VXLAN Offloading，復(fù)雜的環(huán)境下一些不合理的配置導(dǎo)致流量轉(zhuǎn)發(fā)時延過高。通過修改配置，DeepFlow 觀測到 KVM 處的時延下降了 80%，有效的保障了整個分布式核心交易系統(tǒng)的順利上線。

快速定界各類網(wǎng)關(guān)和云基礎(chǔ)設(shè)施的問題

第四類案例，快速定位代碼問題：

?案例 1：利用調(diào)用日志發(fā)現(xiàn)祖?zhèn)鞔a的問題。這里的祖?zhèn)鞔a指的是那些開發(fā)人員已經(jīng)離職，或者接手它的開發(fā)者已經(jīng)更換了好幾次，又或者是一個外部供應(yīng)商提供的沒有源代碼的服務(wù)。即使客戶想通過插樁的方式提升服務(wù)的可觀測性，對此類服務(wù)也是力不從心。我們的很多客戶在部署 DeepFlow 的第一天就能立即發(fā)現(xiàn)此類服務(wù)的一些問題，例如一個游戲客戶發(fā)現(xiàn)某個游戲的 Charge API 正在報錯，雖然對玩家沒有任何影響，但卻給公司帶來著持續(xù)的經(jīng)濟(jì)損失。例如一個云服務(wù)商的開發(fā)團(tuán)隊發(fā)現(xiàn)某個服務(wù)正在寫入一個不存在的數(shù)據(jù)庫表，而這個服務(wù)的負(fù)責(zé)團(tuán)隊已經(jīng)更換了好幾次，它沒有造成業(yè)務(wù)的故障，但卻導(dǎo)致了運(yùn)營數(shù)據(jù)的錯誤。

?案例 2：利用 Network Profile 發(fā)現(xiàn)代碼性能瓶頸。在 Linux 內(nèi)核 4.9 以上的運(yùn)行環(huán)境中，利用 eBPF Profile 定位代碼性能瓶頸是一個非常方便的能力。而 DeepFlow 的 Network Profile 在更普遍的內(nèi)核環(huán)境下也能實(shí)現(xiàn)一部分效果。例如我們的一個游戲客戶在壓測 Redis 托管服務(wù)時發(fā)現(xiàn)壓測程序打印的時延高達(dá) 200ms，查看 DeepFlow 性能指標(biāo)后顯示主機(jī)網(wǎng)卡上觀測到的時延只有不到 3ms。壓測人員并不是壓測程序的編寫者，壓測程序所在的服務(wù)器內(nèi)核也不具備 eBPF 能力。為了弄清楚原因，壓測人員查看通過 cBPF 數(shù)據(jù)生成的 Network Profile，馬上發(fā)現(xiàn)了客戶端等待時延（Client Wait Time）高達(dá) 200ms。這意味著壓測程序在兩次調(diào)用的間隙中花費(fèi)了太多的時間，這個信息反饋給壓測程序的開發(fā)團(tuán)隊時對方非常驚喜，立即進(jìn)行了優(yōu)化并取得了立桿建議的效果。

快速定位代碼問題

本章節(jié)介紹的所有案例均為 DeepFlow 客戶實(shí)際工作中的真實(shí)案例，希望能讓你更真實(shí)的感受 eBPF 技術(shù)對可觀測性的重要性。

06: 使用 eBPF 技術(shù)前的常見疑問

問題一，eBPF Agent 能在多大程度上替代 APM Agent？如果我們僅考慮分布式追蹤目的，即使存在跨線程和異步調(diào)用，也可在 Wasm Plugin 的加持下，充分利用金融、電信、游戲等典型業(yè)務(wù)的請求頭中的唯一 ID 字段完成追蹤，同時 Wasm Plugin 也可用于業(yè)務(wù)語義的提取，因此使用 eBPF Agent 可完全替代 APM Agent。對于追蹤應(yīng)用內(nèi)部函數(shù)之間調(diào)用路徑的需求，一般聚焦在對微服務(wù)框架、RPC 框架、ORM 框架的追蹤，由于這類函數(shù)相對標(biāo)準(zhǔn)，我們相信未來可實(shí)現(xiàn)基于 Wasm plugin 驅(qū)動的 eBPF 動態(tài) Hook，以獲取程序內(nèi)部的 Span 數(shù)據(jù)。

問題二，eBPF Agent 對內(nèi)核的要求很高嗎？DeepFlow Agent 中超過一半的能力基于內(nèi)核 2.6+ 的 cBPF 即可實(shí)現(xiàn)，當(dāng)內(nèi)核達(dá)到 4.9+ 時可支持函數(shù)性能剖析功能，當(dāng)內(nèi)核達(dá)到 4.14+ 時可支持 eBPF AutoTracing 以及 SSL/TLS 加密數(shù)據(jù)采集功能。另外在 Wasm Plugin 的加持下，AutoTracing 并不是強(qiáng)依賴 4.14+ 內(nèi)核的，通過提取請求中現(xiàn)有的唯一 ID 字段可以在任何 2.6+ 的內(nèi)核上實(shí)現(xiàn) AutoTracing。

問題三，采集全棧數(shù)據(jù)是否會占用大量的存儲空間？四層網(wǎng)關(guān)不會改變一個調(diào)用的內(nèi)容，七層網(wǎng)關(guān)一般只會修改一個調(diào)用的協(xié)議頭。因此網(wǎng)絡(luò)流量中采集到的調(diào)用日志可以非常簡單，僅包含少部分關(guān)聯(lián)信息和時間戳信息即可，無需保留詳細(xì)的請求和響應(yīng)字段。這樣計算下來，網(wǎng)絡(luò)轉(zhuǎn)發(fā)路徑上采集到的 Span 只會增加很小的存儲負(fù)擔(dān)。

問題四，eBPF 能用于實(shí)現(xiàn) RUM 嗎？eBPF 并不是一項瀏覽器上的技術(shù)，因此不適用于 Web 側(cè)。eBPF 是一項主機(jī)范圍的數(shù)據(jù)采集技術(shù)，因此不適合運(yùn)行在個人移動設(shè)備上采集所有 APP 的數(shù)據(jù)。但對于由企業(yè)完全控制的終端系統(tǒng)來講，eBPF 是有著廣泛的應(yīng)用場景的，例如基于 Linux 或 Andriod 操作系統(tǒng)的 IoT 終端、智能汽車的車載娛樂系統(tǒng)等。

07: eBPF 對新技術(shù)迭代的重大意義

以往 APM Agent 無法實(shí)現(xiàn)基礎(chǔ)設(shè)施的可觀測性，使得用戶會傾向于追求基礎(chǔ)設(shè)施的穩(wěn)定和低頻變更，但這必然會導(dǎo)致創(chuàng)新被抑制。因此，基于 eBPF 實(shí)現(xiàn)可觀測性對新技術(shù)的迭代發(fā)展有著重大意義。各行各業(yè)的創(chuàng)新正在解決業(yè)務(wù)面臨的痛點(diǎn)，人們看到收益之后也會加快對創(chuàng)新的采納速度，零侵?jǐn)_的可觀測性是對創(chuàng)新速度的有力保障。

云原生基礎(chǔ)設(shè)施的持續(xù)創(chuàng)新：以網(wǎng)關(guān)為例，云原生環(huán)境下微服務(wù)接入的網(wǎng)關(guān)數(shù)量可能會令你大吃一驚，下面這張漫畫非常形象的表達(dá)了這個現(xiàn)狀。這些網(wǎng)關(guān)正在解決著業(yè)務(wù)上遇到的實(shí)際問題，負(fù)載均衡器避免了單點(diǎn)故障；API 網(wǎng)關(guān)保障了 API 暴露的安全性；微服務(wù)網(wǎng)關(guān)讓同一個業(yè)務(wù)系統(tǒng)中的前端可以很方便的訪問到后端的任意一個微服務(wù)；Service Mesh 提供了限流、熔斷、路由能力，減少了業(yè)務(wù)開發(fā)的重復(fù)工作?？v使不同的網(wǎng)關(guān)可能存在能力的交疊，這也是技術(shù)發(fā)展過程中不可避免的中間態(tài)。另外，不同的網(wǎng)關(guān)往往由不同的團(tuán)隊負(fù)責(zé)管理，且管理人員通常沒有二次開發(fā)能力。若無法實(shí)現(xiàn)網(wǎng)關(guān)的零侵?jǐn)_可觀測性，對故障排查會帶來災(zāi)難性的后果。

微服務(wù)接入的各種網(wǎng)關(guān)，來自 theburningmonk@twitter

金融核心交易系統(tǒng)的分布式改造：以往金融業(yè)務(wù)的核心交易系統(tǒng)是由專用硬件來承載的，不易于擴(kuò)展迭代且價格昂貴。DeepFlow 的銀行、證券、保險客戶近兩年紛紛開啟了核心交易系統(tǒng)的分布式改造，這些系統(tǒng)關(guān)系著國計民生，零侵?jǐn)_的可觀測性正是保障這類系統(tǒng)順利上線的前提。

一個手機(jī)銀行業(yè)務(wù)的服務(wù)拓?fù)?/p>

電信核心網(wǎng)面向服務(wù)的架構(gòu)改造：與金融類似的是，電信核心網(wǎng)以往也是由專用硬件來承載的。然而從 5G 核心網(wǎng)開始，3GPP 已經(jīng)明確的提出了面向服務(wù)的架構(gòu)（SBA）規(guī)范，核心網(wǎng)網(wǎng)元已經(jīng)拆分為一系列微服務(wù)運(yùn)行在了 K8s 容器環(huán)境中。同樣，零侵?jǐn)_的可觀測性也是保障電信核心業(yè)務(wù)系統(tǒng)順利上線的前提。

5G 核心網(wǎng)網(wǎng)元及其通信協(xié)議，控制面每個網(wǎng)元都采用 SBA 架構(gòu)

智能網(wǎng)聯(lián)汽車的發(fā)展：智能汽車網(wǎng)絡(luò)由中心云、邊緣云（工廠/園區(qū)）、終端（車載系統(tǒng)）組成。為了給用戶帶來持續(xù)更新的軟件體驗(yàn)，整個智能汽車網(wǎng)絡(luò)中的服務(wù)均采用微服務(wù)架構(gòu)、云原生部署。一個具備可觀測性的基礎(chǔ)設(shè)施同樣也是這張大網(wǎng)持續(xù)迭代的前提。

智能網(wǎng)聯(lián)汽車

對 AIOps 發(fā)展的重要意義：以往，AIOps 方案落地之前，觀測數(shù)據(jù)（通常是指標(biāo)和日志）需要進(jìn)行集中和清洗。這是一個漫長的過程，通常耗時數(shù)月都難以完成。eBPF 有望對這一現(xiàn)狀進(jìn)行根本上的改變，由于 eBPF 采集的數(shù)據(jù)覆蓋了所有服務(wù)、具有高度一致的標(biāo)簽信息和數(shù)據(jù)格式，將會極大降低 AIOps 解決方案的落地門檻。

08: 總結(jié)

APM Agent 由于其侵?jǐn)_性，難以在金融、電信、電力等行業(yè)的核心業(yè)務(wù)系統(tǒng)中落地，難以在云原生基礎(chǔ)設(shè)施中插樁。eBPF 的零侵?jǐn)_優(yōu)勢很好的解決了這些痛點(diǎn)，是云原生時代實(shí)現(xiàn)可觀測性的關(guān)鍵技術(shù)。DeepFlow 基于 eBPF 的全景圖、分布式追蹤、持續(xù)性能剖析能力已服務(wù)于各行各業(yè)，幫助金融行業(yè)的分布式核心交易系統(tǒng)、電信行業(yè)的 5G 核心網(wǎng)、能源行業(yè)的分布式電力交易系統(tǒng)、智能網(wǎng)聯(lián)汽車、云原生游戲服務(wù)等快速實(shí)現(xiàn)了零侵?jǐn)_的可觀測性，保障了新一代業(yè)務(wù)和基礎(chǔ)設(shè)施的持續(xù)創(chuàng)新。

審核編輯：湯梓紅