#挑戰30天在頭條寫日記# #網際網路# #讓AI觸手可及# #金融# #财經# #馬斯克# #程式員# #chat GPT#
上期跟大家聊了下eBPF的發展曆史還有特性，點選這裡，擎創技術流 | 深入淺出運維可觀測工具（一）：聊聊eBPF的前世今生，一鍵回看上期精彩内容。
這期主要跟大家分享下eBPF在應用過程中可能出現的問題，希望能幫到遇到類似問題的朋友，話不多說，我們進入正題。
一、核心适應性，老版本的某些功能不可用
eBPF 最低要求版本為LInux 4.1，eBPF的最低核心版本要求是 Linux 4.1，這是在 2015 年釋出的核心版本。在這個版本之前的核心不支援 eBPF。
1.對于Linux4.1版本之前的監控
擎創對于Linux 4.1.0 之前的版本采用BPF采集HTTP 1資料以及DNS解析請求，進行可觀測統計。
2.對于Linux4.1版本之後的監控
為了保證eBPF程式在各個linux核心版本之間的可移植性，我們編寫eBPF程式的時候采用了CORE技術,CORE技術目前隻有在 Linux 4.9.0 之後才會支援。
如果使用者核心版本低于4.9.0或者核心未開啟CO-RE, 我們能夠提供linux核心更新包。
BCC總結了kernel版本與eBPF功能的關系：https://github.com/iovisor/bcc/blob/master/docs/kernel-versions.md
二、權限安全要求
1.eBPF權限
需要具備root權限或CAP_SYS_ADMIN能力，這意味着隻有能夠加載核心子產品的使用者才能加載eBPF程式。
2.eBPF執行安全
在執行安全方面，eBPF 在加載之前會通過eBPF驗證器對要執行的位元組碼檔案進行校驗，包括但不限于以下方面：
- 程式不包含控制循環
- 程式不會執行超過核心允許的最大指令數
- 程式不包含任何無法到達的指令
- 程式不會跳轉到程式界限之外
三、uprobe 和 kprobe 差異
1.kprobe的優劣分析
優勢：
- 更簡單實作和更易維護。
- 不依賴于其他庫的具體實作細節
劣勢：
- 使用者程式可能會将單個請求分割成多個系統調用，重新組裝這些請求會帶來一些複雜性
- 與TLS不相容, 無法解包TLS
2.uprobe的優劣分析
優勢：
- 我們可以通路和捕獲應用程式上下文，如堆棧跟蹤
- 我們可以建構uprobes以在解析完成後捕獲資料，避免在跟蹤器中重複工作
- 可以比較容易捕獲https 請求,對TLS相容性較好
劣勢：
（1）對于使用的底層庫版本敏感。 無法在剝離了符号的二進制檔案上運作
（2）需要為每個庫實作不同的探針（每種程式設計語言可能都有自己的一組庫）
（3）會導緻額外的調用性能開銷
四、性能消耗
雖然核心社群已經對 eBPF 做了很多的性能調優，跟蹤使用者态函數（特别是鎖争用、記憶體配置設定之類的高頻函數）還是有可能帶來很大的性能開銷。是以，我們在使用 uprobe,kprobe 時，應該盡量避免長時間跟蹤高頻函數。
我們以監控一個Golang 程式HTTP 1通信過程為例子,在分别開啟uprobe和kprobe時候對該程式進行壓力測試：
從結果可以看出，如果HTTP延遲大于1毫秒，引入的開銷可以忽略不計，在大多數情況下隻是噪音。這對于kprobes和uprobes都是類似的，盡管我們重新解析了所有資料，但kprobes的性能稍微好一些。請注意，開銷有時是負值，這很可能隻是測量中的噪音。在這裡的關鍵要點是，如果您的HTTP處理程式正在進行任何實際的工作（大約1毫秒計算時間），引入的開銷基本上可以忽略不計。
五、能否追蹤所有使用者态/核心态函數（調用的入參和傳回值）
1.使用者态
eBPF可以追蹤指定函數調用入參和傳回值。hook點可以為指定函數名稱或者位址。 如果可執行檔案的符号被優化，則需要使用一些逆向手段定位指定函數的位址。
2.核心态
我們可以使用bpftrace -l了解可以hook的鈎子點。
bpftrace是通過讀取（下方代碼）擷取kernel層所有的可跟蹤點。
/sys/kernel/debug/tracing/available_filter_functions 六、是否有丢失事件的風險
1.kprobe和uprobe本身的事件觸發并不會丢失
kprobe是一種核心探測機制，它允許使用者在核心函數執行前或執行後插入代碼。uprobe是一種對使用者空間函數進行探測的機制，它允許使用者在使用者空間函數的入口或出口處插入代碼。
eBPF通過将使用者編寫的處理邏輯加載到核心中，在事件發生時執行此邏輯，以實作使用者級的觀察和處理。由于eBPF的虛拟機技術提供了一種安全可隔離的方式來在核心中執行使用者代碼，是以kprobe和uprobe事件不會丢失。
2.bpf_perf_event會有丢失事件的風險
核心态的eBPF代碼将收集到的事件寫入 bpf_perf_event 環形緩沖區,使用者态程式進行收集上報。當讀寫速度不比對時，就會丢失事件：
（1）寫速度過快：例如每個HTTP transaction都作為一個event寫入緩沖區，這樣比批量寫的風險更高。
（2）讀速度過慢：例如使用者态代碼沒有在專門線程中讀取緩沖區，或者系統負載過高。
3.bpf_map會有丢失事件的風險
eBPF map有大小限制，當map被寫滿的時，将無法寫入新的資料
（1）丢失資料：由于map已滿，新的寫入操作将無法成功，導緻資料丢失。這可能會影響到程式的正确性和完整性。
（2）性能下降：當map寫滿時，寫入操作将被阻塞，導緻系統的性能下降。這會影響到整體的系統響應時間和吞吐量。
寫在文末
随着eBPF的不斷發展和壯大，我們可以看到它在網絡和系統領域的巨大潛力。eBPF已經被證明是一種強大且高效的工具，可以用于實作各種進階網絡和系統功能。
在未來，我們有理由相信eBPF将繼續發展，并被越來越多的開發者群組織使用。随着eBPF功能的不斷擴充和完善，我們可以期待更多創新的網絡應用和系統工具的出現，進而推動整個行業向前發展。
總之，eBPF的前世今生令人振奮，它不僅繼承了BPF的優點，還擁有更強大和靈活的功能。我們期待看到eBPF為網絡和系統帶來更多的創新和改進，為我們的數字化世界帶來更強大的支撐。
互動一下：
關于eBPF，你有什麼想分享的？可以留言區探讨起來~
擎創科技，Gartner連續推薦的AIOps領域标杆供應商。公司專注于通過提升企業客戶對運維資料的洞見能力，為運維降本增效，充分展現科技運維對業務營運的影響力。
行業龍頭客戶的共同選擇