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

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

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

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

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

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

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

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

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

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

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

實(shí)際上，這也是為什么侵?jǐn)_性的插樁方案少見(jiàn)于成功的商業(yè)產(chǎn)品，更多見(jiàn)于活躍的開(kāi)源社區(qū)。OpenTelemetry、SkyWalking 等社區(qū)的活躍正是佐證。而在部門(mén)分工明確的大型企業(yè)中，克服協(xié)作上的困難是一個(gè)技術(shù)方案能夠成功落地永遠(yuǎn)也繞不開(kāi)的坎。特別是在金融、電信、電力等承載國(guó)計(jì)民生的關(guān)鍵行業(yè)中，部門(mén)之間的職責(zé)區(qū)分和利益沖突往往會(huì)使得落地插樁式的解決方案成為「不可能」。即使是在開(kāi)放協(xié)作的互聯(lián)網(wǎng)企業(yè)中，也少不了開(kāi)發(fā)人員對(duì)插樁的不情愿、運(yùn)維人員在出現(xiàn)性能故障時(shí)的背鍋等問(wèn)題。在經(jīng)歷了長(zhǎng)久的努力之后人們已經(jīng)發(fā)現(xiàn)，侵入性的解決方案僅僅適合于每個(gè)業(yè)務(wù)開(kāi)發(fā)團(tuán)隊(duì)自己主動(dòng)引入、自己維護(hù)各類(lèi) Agent 和 SDK 的版本、自己對(duì)性能隱患和運(yùn)行故障的風(fēng)險(xiǎn)負(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é)跳動(dòng)在 2022 年的對(duì)外分享《分布式鏈路追蹤在字節(jié)跳動(dòng)的實(shí)踐》中也表示：

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

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

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

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

不同角色的排障邊界

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

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

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

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

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

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

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

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

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

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

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

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

通過(guò)利用 eBPF 和 cBPF 采集應(yīng)用函數(shù)、系統(tǒng)調(diào)用函數(shù)、網(wǎng)卡收發(fā)的數(shù)據(jù)，DeepFlow 首先聚合成 TCP/UDP 流日志（Flow Log）；通過(guò)應(yīng)用協(xié)議識(shí)別，DeepFlow 聚合得到應(yīng)用調(diào)用日志（Request Log），進(jìn)而計(jì)算出全棧的 RED（Request/Error/Delay）性能指標(biāo)，并關(guān)聯(lián)調(diào)用日志實(shí)現(xiàn)分布式追蹤。除此之外，DeepFlow 在流日志聚合過(guò)程中還計(jì)算了 TCP 吞吐、時(shí)延、建連異常、重傳、零窗等網(wǎng)絡(luò)層性能指標(biāo)，以及通過(guò) Hook 文件讀寫(xiě)操作計(jì)算了 IO 吞吐和時(shí)延指標(biāo)，并將所有這些指標(biāo)關(guān)聯(lián)至每個(gè)調(diào)用日志上。另外，DeepFlow 也支持通過(guò) eBPF 獲取每個(gè)進(jìn)程的 OnCPU、OffCPU 函數(shù)火焰圖，以及分析 TCP 包繪制 Network Profile 時(shí)序圖。所有這些能力最終體現(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)勢(shì)，對(duì)比 APM 有限的覆蓋能力，所有的服務(wù)都能出現(xiàn)在全景圖中。但 eBPF 獲取的調(diào)用日志不能直接用于拓?fù)湔宫F(xiàn)，DeepFlow 為所有的數(shù)據(jù)注入了豐富的標(biāo)簽，包括云資源屬性、K8s 資源屬性、自定義 K8s 標(biāo)簽等。通過(guò)這些標(biāo)簽可以快速過(guò)濾出指定業(yè)務(wù)的全景圖，并且可以按不同標(biāo)簽分組展示，例如 K8s Pod、K8s Deployment、K8s Service、自定義標(biāo)簽等。全景圖不僅描述了服務(wù)之間的調(diào)用關(guān)系，還展現(xiàn)了調(diào)用路徑上的全棧性能指標(biāo)，例如下圖右側(cè)為兩個(gè) K8s 服務(wù)的進(jìn)程在相互訪(fǎng)問(wèn)時(shí)的逐跳時(shí)延變化。我們可以很快的發(fā)現(xiàn)性能瓶頸到底位于業(yè)務(wù)進(jìn)程、容器網(wǎng)絡(luò)、K8s 網(wǎng)絡(luò)、KVM 網(wǎng)絡(luò)還是 Underlay 網(wǎng)絡(luò)。充足的中立觀測(cè)數(shù)據(jù)是快速定界的必要條件。

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

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

DeepFlow 和 APM 的分布式追蹤對(duì)比

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

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

DeepFlow 中的 CPU Profile 和 Network Profile

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

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

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

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

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

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

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

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

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

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

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

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

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

第二類(lèi)案例，快速定界訪(fǎng)問(wèn)托管服務(wù)的故障：

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

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

快速定界訪(fǎng)問(wèn)托管服務(wù)的故障

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

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

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

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

第四類(lèi)案例，快速定位代碼問(wèn)題：

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

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

快速定位代碼問(wèn)題

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

06: 使用 eBPF 技術(shù)前的常見(jiàn)疑問(wèn)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

08: 總結(jié)

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

審核編輯：湯梓紅