來源：小技術君

在過去的兩年裡，雲原生社群一直在熱烈討論eBPF。eBPF曾是KubeCon、eBPF Days和eBPF Summit的主題，並且越來越受歡迎。像Google和Netflix這樣的公司多年來一直在使用eBPF，新的用例也不斷湧現。特別是在觀測性方面，eBPF被認為將是一個重大改變。

所以讓我們來看看eBPF——這項技術到底是什麼，它如何影響觀測性，它與現有的觀測性實踐有什麼區別，未來可能會發生什麼變化？

什麼是eBPF？

eBPF是一種程式設計框架，允許我們在Linux核心中安全地執行沙盒化的程式，而無需更改核心程式碼。

它最初是為Linux開發的（而且直到今天，這項技術在Linux上最成熟），但微軟正在迅速發展eBPF在Windows上的實現^[1]。

eBPF程式從設計上來說非常高效和安全——核心會對其進行驗證，以確保它們不會危及作業系統的穩定性或安全性。

為什麼eBPF如此重要？

要理解這一點，我們需要了解使用者空間和核心空間。

使用者空間是所有應用程式執行的地方。核心空間位於使用者空間和物理硬體之間。使用者空間中的應用程式無法直接訪問硬體。相反，它們透過系統呼叫與核心通訊，然後核心再訪問硬體。

所有記憶體訪問、檔案讀寫和網路流量都經過核心。核心還管理併發程式。

基本上，所有操作都透過核心進行（見下圖）。

而eBPF提供了一種安全的、高效的擴充套件核心功能的方式。

使用者空間和核心空間

從歷史上看，出於顯而易見的原因，更改核心原始碼或作業系統層的任何內容一直都非常困難。

Linux核心有3000萬行程式碼^[2]，任何更改要從一個想法變成廣泛可用的東西需要數年時間。首先，Linux社群必須同意它。然後，它必須成為官方Linux釋出的一部分。然後，在幾個月後，它會被Red Hat和Ubuntu等發行版採用，然後傳播到更廣泛的使用者。

從技術上講，一個人可以將核心模組載入到核心中，直接進行更改，但這是非常高風險的，涉及複雜的核心級程式設計，因此幾乎普遍不建議這樣做。

eBPF出現並解決了這個問題，提供了一種在核心中附加和執行程式的安全和高效機制。

讓我們看看eBPF如何確保安全性和效能。

高度安全

•嚴格的驗證 — 在任何eBPF程式載入到核心之前，它都會由eBPF驗證器進行驗證，以確保程式碼絕對安全——例如，沒有硬迴圈、無效的記憶體訪問、不安全的操作。•沙盒化 — eBPF程式在核心內部的記憶體隔離沙盒中執行，與其他核心元件分開。這可以防止未經授權的訪問核心記憶體、資料結構和核心原始碼。•有限的操作 — eBPF程式通常必須使用C語言的一個小子集來編寫，即受限指令集。這限制了eBPF程式可以執行的操作，降低了安全漏洞的風險。

高效能 / 輕量級

•以本機機器碼執行 — eBPF程式在CPU上以本機機器指令的形式執行。這導致更快的執行和更好的效能。•沒有上下文切換 — 常規應用程式會在使用者空間和核心空間之間定期切換上下文，這會消耗資源。eBPF程式，因為它們在核心層執行，可以直接訪問核心資料結構和資源。•事件驅動 — eBPF程式通常僅在特定核心事件發生時執行，而不是一直執行。這最小化了開銷。•針對硬體進行最佳化 — eBPF程式在執行之前由核心的即時編譯器（JIT）編譯為機器程式碼，因此程式碼針對特定的硬體進行了最佳化。

因此，eBPF為核心程式設計提供了一種安全且高效的鉤子。考慮到一切都透過核心，這為我們帶來了以前無法實現的新可能性。

為什麼現在才如此重要？

eBPF周圍的技術在很長一段時間內得以發展，已經有大約30年了。

在過去的7-8年中，eBPF已被一些大型公司大規模使用，現在我們正在進入一個使用eBPF變得更加主

流的時代。請參閱eBPF的共同創作者之一、Linux的共同維護者Alexei Starovoitov的這個影片^[3]，瞭解eBPF的發展歷程。

eBPF — 簡要歷史

•1993年-來自勞倫斯伯克利國家實驗室的一篇論文^[4]探討了使用核心代理進行資料包過濾。這就是BPF（“伯克利資料包過濾器”）這個名字的由來。•1997年 — BPF正式作為Linux核心的一部分引入（版本2.1.75）。•1997–2014年 — 新增了一些功能，以改進、穩定和擴充套件BPF的功能。•2014年 — 引入了重要的更新，稱為“擴充套件伯克利資料包過濾器”（eBPF）。這個版本對BPF技術進行了重大改進，使其更廣泛可用，因此稱之為“擴充套件”。

之所以說這個釋出很重要，是因為它使得擴充套件核心功能變得容易。

程式設計師可以更多或更少地像編寫常規應用程式一樣編寫程式碼，而周圍的eBPF基礎設施會處理低階驗證、安全性和效率問題。

eBPF的周圍支援生態系統和腳手架使這成為可能（見下圖）。

來源：

更好的是，eBPF程式可以在不重新啟動的情況下載入到核心中，並且可以隨時解除安裝。

所有這些突然使得廣泛採用和應用成為可能。

在生產系統中的廣泛應用

eBPF的受歡迎程度在過去的7-8年中迅速增長，許多大型公司在規模生產系統中使用它。

•到2016年，Netflix廣泛使用eBPF進行跟蹤。Brendan Gregg^[5]實現了它，他在基礎設施和運維領域被廣泛認為是eBPF的權威人士。•2017年 — Facebook開源了他們基於eBPF的負載均衡器Katran^[6]。自2017年以來，每個訪問Facebook.com^[7]的資料包都經過了eBPF。•2020年- Google將eBPF納入其Kubernetes提供的一部分。eBPF現在驅動著GKE的網路、安全和可觀測性層^[8]。到目前為止，企業中也有廣泛的採用，如Capital One^[9]和Adobe^[10]。•2021年 — Facebook、Google、Netflix、Microsoft和Isovalent聯合宣佈建立eBPF基金會^[11]來管理eBPF技術的增長。

現在有成千上萬家公司使用eBPF，並且每年湧現出數百個eBPF專案，探索不同的用例。

eBPF現在是Linux核心中的一個獨立子系統，並擁有廣泛的社群支援。這項技術本身也在不斷擴充套件，有了幾個新的新增。

那麼，我們可以用eBPF做什麼？

eBPF的最常見用途可以分為三個領域：

1.網路2.安全3.可觀測性

安全和網路已經看到了更廣泛的採用和應用，其中包括像Cilum^[12]這樣的專案。相比之下，基於eBPF的可觀測性方案在其演進過程中還處於早期階段。

讓我們首先看看安全和網路的用例。

安全

安全是eBPF的一個非常流行的用例。使用eBPF，程式可以觀察核心級別的一切情況，以高速處理事件以檢查意外行為，並比以前更快地發出警報。

例如 -

•Google^[13]使用eBPF進行大規模入侵檢測•Shopify^[14]使用eBPF來實現容器安全

一些第三方安全產品^[15]現在使用eBPF進行資料收集和監視。

網路

網路是另一個廣泛應用的用例。位於eBPF層的位置允許全面監測網路可觀測性，例如完整網路路徑的可見性，包括所有跳數，以及源IP和目標IP。使用eBPF程式，可以處理高速網路事件並在核心內直接操作網路資料包，而開銷非常低。

這允許各種網路用例，如負載

平衡、DDoS防護、流量整形和服務質量（QoS）。

•Cloudflare^[16]使用eBPF檢測並防止DDoS攻擊，每秒處理1000萬個資料包^[17]而不影響網路效能。•Meta的基於eBPF的Katran^[18]為Facebook的所有負載均衡進行處理

可觀測性

到目前為止，透過核心觀察一切並且eBPF提供了一種高效能和安全的方式來觀察一切，這使得eBPF在可觀察性方面非常有用。

讓我們更深入地探討可觀測性，看看這項技術的影響。

eBPF如何確切影響可觀測性？

為了探討這一點，讓我們離開eBPF的世界，進入可觀測性的世界，看看構成我們標準可觀測性解決方案的內容。

任何可觀測性解決方案都有四個主要元件：

1.資料收集 — 從應用程式和基礎設施獲取遙測資料2.資料處理 — 對收集的資料進行過濾、索引和計算3.資料儲存 — 資料的短期和長期儲存4.使用者體驗層 — 確定使用者如何使用資料

在這些元件中，eBPF影響的是（截至今天）僅僅是資料收集層 — 使用eBPF直接從核心收集遙測資料的簡便機制。

eBPF — 對可觀測性的影響

所以當我們說“eBPF可觀測性”時，我們實際上是指使用eBPF作為收集遙測資料的工具，而不是使用其他方法來進行儀器化。可觀測性解決方案的其他元件保持不變。

eBPF可觀測性的工作原理

為了充分理解eBPF可觀測性背後的機制，我們需要了解掛鉤（hooks）的概念。

正如我們前面所看到的，eBPF程式主要是事件驅動的，即每次發生特定事件時都會觸發它們。例如，每次進行函式呼叫時，都可以呼叫一個eBPF程式來捕獲一些用於可觀測性目的的資料。

首先，這些掛鉤可以在核心空間或使用者空間。因此，eBPF可以用於監視使用者空間應用程式以及核心級事件。

其次，這些掛鉤可以是預定義的/靜態的，也可以在執行中動態插入到系統中（無需重新啟動！）

這四種不同的eBPF機制允許每一種（見下圖）

使用者空間和核心空間的靜態和動態eBPF掛鉤

1.核心跟蹤點 — 用於掛接到由核心開發人員預定義的事件（使用TRACE_EVENT宏）2.USDT — 用於掛接到應用程式程式碼中由開發人員預定義的跟蹤點3.Kprobes（核心探針） — 用於在執行時動態掛接到核心程式碼的任何部分4.Uprobes（使用者探針） — 用於在執行時動態掛接到使用者空間應用程式的任何部分

在核心空間中有許多預定義的掛鉤，可以輕鬆將eBPF程式附加到其中（例如，系統呼叫、函式入口/出口、網路事件、核心跟蹤點）。類似地，在使用者空間中，許多語言執行時、資料庫系統和軟體堆疊會暴露出Linux BCC工具的預定義掛鉤，eBPF程式可以連線到這些掛鉤。

但更有趣的是kprobes和uprobes。如果生產中出現問題，我沒有足夠的資訊，並且我希望在執行時動態新增儀表化，該怎麼辦？這就是kprobes和uprobes允許強大的可觀測性的地方。

eBPF kprobes 和 uprobes

例如，使用uprobes，可以在不修改應用程式程式碼的情況下在執行時掛接到應用程式內的特定函式。每當執行該函式時，都會觸發一個eBPF程式以捕獲所需的資料。這允許像實時^[19]除錯這樣的令人興奮的可能性。

現在我們知道了eBPF可觀測性是如何工作的，讓我們來看看用例。

eBPF可觀測性用例

eBPF可用於幾乎所有常見的現有可觀測性用例，並且還提供了新的可能性。

1.系統和基礎設施監控2.應用程式效能監控（APM）3.安全監控4.故障排除

系統和基礎設施監控

在這個領域，eBPF最常用於監控Linux主機的效能和資源使用情況。

•CPU和記憶體使用率•硬碟和網路效能•程式活動和排程•檔案系統活動

eBPF程式可以輕鬆地在這些事件的發生時捕獲資料，並將其傳送到儲存後端，以便稍後分析。

應用程式效能監控（APM）

eBPF也用於應用程式內部的效能監控。例如，在Go應用程式中，可以使用uprobes掛接到某個特定函式，以捕獲函式引數、返回值和執行時間。這對於詳細分析應用程式效能問題非常有用。

安全監控

eBPF在安全監控方面也非常有用。它可以用於檢測惡意行為、網路攻擊和異常事件。eBPF程式可以在核心和應用程式級別捕獲事件，並將其傳遞給安全資訊和事件管理系統，以進行進一步的分析和響應。

故障排除

eBPF還可以用於故障排除。它可以用於跟蹤應用程式崩潰、效能下降或其他問題的根本原因。eBPF程式可以捕獲關鍵效能指標、事件和上下文資訊，以幫助診斷問題並進行修復。

實際示例

以下是一些eBPF可觀測性用例的實際示例：

•Tracing和Profiling — 使用eBPF捕獲應用程式的效能資料，例如函式呼叫、系統呼叫和記憶體分配，以識別瓶頸和最佳化效能。•網路可觀測性 — 使用eBPF來監視網路流量、分析網路包，並實施防火牆策略和負載平衡。•容器監控 — 在Kubernetes叢集中，使用eBPF來監控容器內部的資源使用情況、效能和問題。•安全監控 — 使用eBPF來檢測潛在的安全威脅，例如異常網路活動、不尋常的系統呼叫和入侵嘗試。•分散式跟蹤 — 使用eBPF捕獲應用程式的分散式跟蹤資料，以分析請求的流經整個系統的路徑，幫助診斷和最佳化效能問題。

eBPF和傳統觀測性的比較

現在讓我們來比較eBPF可觀測性和傳統觀測性方法。

傳統觀測性

傳統的可觀測性方法通常基於以下原則：

•代理和代理整合 — 在目標系統中安裝代理，代理負責收集和傳輸遙測資料。這通常需要在每個目標系統上部署代理，而且代理也需要進行版本控制和維護。•度量指標整合 — 需要配置和管理度量和日誌指標的整合。這通常涉及到手動配置和更新，以確保適當的指標和日誌資料被採集。•額外的開銷 — 代理需要在目標系統上執行，這可能會引入額外的開銷，例如CPU和記憶體消耗。•侷限性 — 傳統的可觀測性方法可能會受到系統複雜性和效能問題的限制，因為它們可能無法實時捕獲足夠的資料。•安全性 — 代理可能會引入潛在的安全風險，因為它們在目標系統上執行並訪問敏感資料。

eBPF可觀測性

與傳統觀測性方法相比，eBPF可觀測性具有以下優勢：

•核心級別的可觀測性 — eBPF程式在核心級別執行，可以觀察系統的內部狀態和事件，無需在目標系統上執行代理。•輕量級 — eBPF程式通常對系統資源的開銷很小，因為它們在核心級別執行，無需獨立的代理。•安全性 — eBPF程式受到核心驗證器的強制約束，以確保它們不會引入安全風險。•靈活性 — eBPF程式可以在執行時動態附加到系統中，無需重新啟動目標系統，從而提供了更大的靈活性和可伸縮性。•效能 — eBPF程式通常以本機機器指令執行，因此效能很高，可以實時捕獲大量資料。

儘管eBPF可觀測性具有許多優勢，但它也具有一些挑戰和限制。首先，eBPF程式設計需要一定的學習曲線，因為它涉及到特定的程式設計模型和語言。此外，某些高階用例可能需要更復雜的eBPF程式。

未來展望

eBPF可觀測性已經取得了巨大的進展，但仍有很多潛在的未來發展方向。

•更多的工具和庫 — 隨著eBPF的流行，可以預期會有更多的工具和庫出現，用於

簡化eBPF程式的開發、除錯和部署。

•標準化 — 隨著eBPF的廣泛應用，可以期待出現更多的標準和最佳實踐，以幫助開發人員更輕鬆地使用eBPF進行可觀測性。•更廣泛的整合 — eBPF將繼續整合到各種雲端計算和容器平臺中，以幫助使用者監控和除錯分散式應用程式。•更多的可觀測性用例 — 隨著eBPF技術的不斷髮展，可以預期將出現更多的創新可觀測性用例，幫助使用者更好地瞭解和最佳化其應用程式和基礎設施的效能。

總之，eBPF可觀測性是一個充滿潛力的領域，已經取得了令人印象深刻的進展。它提供了一種強大而靈活的方式來觀察和監視應用程式和基礎設施的行為，有望在未來繼續發展和成熟。對於那些希望更好地瞭解和控制其系統的使用者來說，eBPF可觀測性是一個令人興奮的選擇。

引用連結

[1] eBPF在Windows上的實現: 
[2] 3000萬行程式碼: 
[3] 這個影片: 
[4] 論文: 
[5] Brendan Gregg: 
[6] Katran: 
[7] Facebook.com: 
[8] 網路、安全和可觀測性層: https://cloud.google.com/blog/products/containers-kubernetes/bringing-ebpf-and-cilium-to-google-kubernetes-engine
[9] Capital One: 
[10] Adobe: 
[11] 建立eBPF基金會: https://isovalent.com/blog/post/2021-08-ebpf-foundation-announcement/
[12] Cilum: 
[13] Google: 
[14] Shopify: 
[15] 第三方安全產品: https://www.traceable.ai/blog-post/ebpf-and-api-security-with-traceable
[16] Cloudflare: https://legacy.netdevconf.info/2.1/session.html?bertin=
[17] 1000萬個資料包: https://blog.cloudflare.com/how-to-drop-10-million-packets/
[18] Katran: 
[19] 實時: https://www.cncf.io/blog/2021/11/17/debugging-with-ebpf-part-1-tracing-go-function-arguments-in-prod/