可觀測性是一種了解和解釋應用當前狀態(tài)的能力，也是一種知道何時出現(xiàn)問題的方法。隨著在 Kubernetes 和 OpenShift 上以微服務形式進行云部署的應用程序越來越多，可觀察性受到了廣泛關注。許多應用程序都有嚴格的承諾，比如在停機時間、延遲和吞吐量方面的 SLA，因此網絡層面的可觀測性是一項非常必要的功能。網絡層面的可觀測性由不同的編排器提供，有的是內置支持，有的是通過插件和 operator 提供。

最近，eBPF（擴展的伯克利數(shù)據包過濾器）因其性能和靈活性成為在終端主機內核實現(xiàn)可觀察性的熱門選擇。通過這種方法，可以在網絡數(shù)據路徑的某些點（如套接字、TC 和 XDP）上掛接自定義程序。目前已發(fā)布了多個基于 eBPF 的開源插件和 operator，每個插件和 operator 都可插入終端主機節(jié)點，通過云上的編排器提供網絡可觀察性。

現(xiàn)有的可觀測性工具

可觀測性模塊的核心部分是如何以非侵入方式收集必要數(shù)據。為此，使用代碼埋點統(tǒng)計，我們研究了 eBPF 如何影響目標被觀測模塊的性能。測量方法和工具是開源的，你可以在我們的?Git倉庫 （ https://github.com/netobserv/ebpf-research/tree/main/ebpf-measurements?）?中找到。在設計可擴展的高性能 eBPF 監(jiān)控數(shù)據路徑時，我們還能為您提供一些有用的見解。

以下是現(xiàn)有的開源工具，可用于在網絡和主機的上下文中實現(xiàn)可觀察性：

Skydive

Skydive?是一款網絡拓撲和流量分析器。它將探針下放到節(jié)點，以收集流量級信息。使用 PCAP、AF_Packet、Open vSwitch 等方式連接探針。Skydive 使用 eBPF 捕獲流量指標，而不是捕獲整個數(shù)據包。連接到套接字 Hook 點的 eBPF 實現(xiàn)使用哈希映射來存儲流量頭和指標（數(shù)據包、字節(jié)和方向）。

libebpfflow

Libebpfflow 是一個使用 eBPF 提供網絡可見性的網絡庫。它 Hook 主機堆棧中的多個點，如 kernel probes（inet_csk_accept、tcp_retransmit_skb）和 tracepoints（net:netif_receive_skb、net:net_dev_queue），以分析 TCP/UDP 流量狀態(tài)、RTT 等。此外，它還為所分析的流量提供進程和容器映射。其 eBPF 實現(xiàn)使用 perf event buffer 將 TCP 狀態(tài)變化事件通知用戶空間。對于 UDP，它連接到網絡設備隊列的跟蹤點，并結合使用 LRU 哈希映射和 perf event buffer 來存儲 UDP 流量指標。

eBPF Exporter

Cloudflare 的?eBPF Exporter?提供了用于插入自定義 eBPF 代碼的 API，以記錄感興趣的自定義指標。它需要將整個 eBPF C 代碼（以及掛鉤點）附加到 YAML 文件中以進行部署。

Pixie

Pixie?使用 bpftrace 來跟蹤系統(tǒng)調用。它使用 TCP/UDP 狀態(tài)消息來收集必要的信息，然后將其發(fā)送到 Pixie Edge Module (PEM)。在PEM中，根據檢測到的協(xié)議解析數(shù)據并存儲以供查詢。

Inspektor

Inspektor?是用于 Kubernetes 集群調試的工具集合。它有助于低級內核原語與 Kubernetes 資源的映射。它作為 daemonset 添加到集群的每個節(jié)點上，以使用 eBPF 收集syscall 等事件的跟蹤。這些事件被寫入 perf 環(huán)形緩沖區(qū)。最后，當發(fā)生故障時（例如，Pod 崩潰時），環(huán)形緩沖區(qū)會被追溯消耗。

L3AF

L3AF?提供了一組 eBPF 包，可使用 tail-calls 將其打包并串聯(lián)起來。它提供了一個網絡可觀察性工具，可根據流標識將流量鏡像到用戶空間代理。此外，它還通過在 eBPF 數(shù)據路徑中的hash map 上存儲流量記錄，提供了一個 IPFIX 流量導出器。

Host-INT

Host-INT 擴展了帶內網絡遙測支持，以支持主機網絡堆棧的遙測。從根本上說，INT 將每個數(shù)據包產生的切換延遲嵌入到數(shù)據包的 INT 標頭中。Host-INT 對兩個主機之間的主機網絡堆棧執(zhí)行相同的操作。Host-INT 有兩個數(shù)據路徑組件：基于 eBPF 的源和接收器。源運行在發(fā)送方主機接口的 TC Hook 上，接收器運行在接收方主機接口的 XDP Hook 上。從源上來說，它使用 hash map 來存儲流量統(tǒng)計信息。此外，它還添加了帶有入口/出口端口、時間戳等的 INT 標頭。在接收器處，它使用 perf array 在每個數(shù)據包到達時將統(tǒng)計信息發(fā)送到接收器用戶空間程序，并將數(shù)據包發(fā)送到內核。

Falco

Falco 是一個云原生運行時安全項目。它使用 eBPF 探測器監(jiān)控系統(tǒng)調用，并在運行時對其進行解析。Falco 可對使用特權容器進行特權訪問、讀寫內核文件夾、添加用戶、更改密碼等活動配置警報。Falco 包括一個用戶空間程序（作為 CLI 工具）和一個基于 libscap 和 libsinsp 庫的 falco 驅動程序，前者用于指定警報和獲取解析后的系統(tǒng)調用輸出。對于系統(tǒng)調用探測，falco 使用 eBPF ring buffers。

Cilium

Cilium 的可觀測性是通過 eBPF 實現(xiàn)的。Hubble 是一個在集群的每個節(jié)點上運行 eBPF 鉤子的平臺。它有助于深入了解相互通信的服務，從而構建服務依賴關系圖。它還有助于第 7 層監(jiān)控，例如分析 HTTP 調用和 Kafka 主題，以及通過 TCP 重傳率進行第 4 層監(jiān)控等。

Tetragon

Tetragon 是 Cilium 中用于安全和可觀察性的可擴展框架。Tetragon 的底層驅動程序是 eBPF，使用環(huán)形緩沖區(qū)存儲數(shù)據，但在監(jiān)控 eBPF 的同時，還利用 eBPF 執(zhí)行跨越虛擬文件系統(tǒng)（VFS）、命名空間、系統(tǒng)調用等各種內核組件的策略。

Aquasecurity Tracee

Tracee?是一款事件跟蹤工具，用于調試通過 eBPF 構建的行為模式。Tracee 在 tc、kprobes 等處有多個掛鉤點，用于監(jiān)控和跟蹤網絡流量。在 tc 鉤子點，它使用環(huán)形緩沖區(qū)（perf）向用戶空間提交數(shù)據包級事件。

重新審視 Flow metric agent 的設計

雖然不同工具的動機和實現(xiàn)方式各不相同，但所有可觀測性工具的共同核心部分是用于收集可觀測性指標的數(shù)據結構。雖然不同的工具采用不同的數(shù)據結構來收集指標，但目前還沒有進行性能測量，以了解用于收集和存儲可觀測性指標的數(shù)據結構的影響。為了彌補這一差距，我們使用不同的數(shù)據結構實施模板 eBPF 程序，從主機流量中收集相同的流量指標。我們使用 eBPF 中的以下數(shù)據結構（稱為 “地圖”）來收集和存儲指標：

• Ring Buffer

• Hash

• Per-CPU Hash

• Array

• Per-CPU Array

Ring Buffer

環(huán)形緩沖區(qū)是 eBPF 數(shù)據路徑和用戶空間之間的共享隊列，其中 eBPF 數(shù)據路徑是生產者，用戶空間程序是消費者。它可用于向用戶空間發(fā)送每個數(shù)據包的“明信片”，以匯總流量指標。雖然這種方法既簡單又能提供準確的結果，但由于它按數(shù)據包發(fā)送“明信片”，用戶空間程序一直處于繁忙的循環(huán)中，因此無法擴展。

Hash and Per-CPU Hash map

（每 CPU）Hash map 可用于 eBPF 數(shù)據路徑，通過對流標識（例如 5 元組：IP、端口、協(xié)議）進行散列來聚合每個流的指標，并在流完成/未激活時將聚合信息驅逐到用戶空間。雖然這種方法克服了環(huán)形緩沖區(qū)的缺點，每個流而不是每個數(shù)據包只發(fā)送一次明信片，但它也有一些缺點。

首先，多個流量有可能被散列到同一個條目中，從而導致流量指標匯總不準確。其次，對于內核 eBPF 數(shù)據路徑來說，散列映射的內存必然有限，因此可能會被耗盡。因此，用戶空間程序必須執(zhí)行驅逐邏輯，以便在超時時不斷驅逐流量。

Array-based map

（每 CPU）基于數(shù)組的映射也可用于在逐出用戶空間之前臨時存儲每數(shù)據包明信片，盡管這不是一個明顯的選擇。使用數(shù)組有一個優(yōu)勢，即在數(shù)組中存儲每個數(shù)據包的信息，直到數(shù)組已滿，然后僅在數(shù)組已滿時才刷新到用戶空間。這樣，與使用每個數(shù)據包的環(huán)形緩沖區(qū)相比，它可以改善用戶空間的忙循環(huán)周期。另外，它不存在 Hash map 的哈希沖突問題。然而，實現(xiàn)起來很復雜，因為當主數(shù)組將其內容刷新到用戶空間時，需要多個冗余數(shù)組來存儲每個數(shù)據包的明信片。

Measurements

到目前為止，我們已經研究了可用于使用多種數(shù)據結構實現(xiàn)流度量收集的選項?，F(xiàn)在是時候研究每種方式的性能了。為此，我們實施了代表性的 eBPF 程序來收集流量指標。為此，我們實施了具有代表性的 eBPF 程序來收集流量指標。我們使用的代碼可在我們的?Git 倉庫?中找到。此外，我們還在 PcapPlusPlus 的基礎上定制了基于 UDP 的數(shù)據包生成器，通過發(fā)送流量進行測量。

該圖描述了實驗設置：

(Kannan/Naik/Lev-Ran, CC BY-SA 4.0)

觀察代理是執(zhí)行流度量收集的 eBPF 數(shù)據路徑，掛接到發(fā)送方的 tc hook 點。我們使用兩臺通過 40G 鏈路連接的裸機服務器。數(shù)據包生成是使用 40 個獨立的 core 完成的。為了正確看待這些測量結果，基于 libpcap 的 Tcpdump 可用于收集類似的流量信息。

Single Flow

我們最初使用單流 UDP 幀運行測試。單流測試可以向我們展示觀察代理可以容忍的單流流量突發(fā)量。如下圖所示，沒有任何觀察代理的本機性能約為 4.7 Mpps（每秒百萬數(shù)據包），而運行?tcpdump?時，吞吐量降至約 2 Mpps。使用 eBPF，我們觀察到性能從 1.6 Mpps 到 4.7 Mpps 不等，具體取決于用于存儲流指標的數(shù)據結構。使用 HashMap 等共享數(shù)據結構，我們觀察到單流性能下降最顯著，因為每個數(shù)據包都會寫入映射中的相同條目，而不管其源自哪個 CPU。

對于單個流突發(fā)，Ringbuffer 的性能比單個 HashMap 稍好。使用每 CPU 哈希映射，我們觀察到吞吐量性能顯著提高，因為來自多個 CPU 的數(shù)據包不再爭用相同的映射條目。然而，在沒有任何觀察代理的情況下，性能仍然是本機性能的一半。 （請注意，此性能未處理哈希沖突和驅逐。）

使用（每個 CPU）陣列，我們看到單個流的吞吐量顯著增加。我們可以將此歸因于以下事實：數(shù)據包之間實際上不存在爭用，因為每個數(shù)據包逐漸占用數(shù)組中的不同條目。然而，我們實現(xiàn)中的主要缺點是我們不處理數(shù)組滿時的刷新，而它以循環(huán)方式執(zhí)行寫入。因此，它存儲在任何時間點觀察到的最后幾個數(shù)據包記錄。盡管如此，它為我們提供了通過在 eBPF 數(shù)據路徑中適當應用數(shù)據結構來實現(xiàn)的一系列性能提升。

(Kannan/Naik/Lev-Ran, CC BY-SA 4.0)

Multi-Flow

我們現(xiàn)在測試具有多個流的 eBPF 觀察代理的性能。我們通過檢測數(shù)據包生成器生成了 40 個不同的 UDP 流（每個核心 1 個流）。有趣的是，對于多個流，我們觀察到與單個流相比，每 CPU 哈希和哈希映射的性能存在明顯差異。這可能歸因于單個散列條目的爭用減少。然而，我們沒有看到 ringbuffer 有任何性能改進，因為無論流量如何，爭用通道（即 ringbuffer ）都是固定的。數(shù)組在多個流中的性能稍好一些。

學到了啥

根據我們的研究，我們得出以下結論：

• 基于 ringbuffer 的每個數(shù)據包的處理不可擴展，并且會影響性能。

• Hash map 限制了數(shù)據流的突發(fā)流量，即每秒處理的數(shù)據包數(shù)量。每個 CPU 的 hash map 性能表現(xiàn)稍好。

• 考慮到數(shù)組可以存儲 10 個或 100 個數(shù)據包的記錄，使用數(shù)組映射來存儲每個數(shù)據包的明信片是處理數(shù)據流內數(shù)據包短時突發(fā)的一個不錯選擇。這將確保觀察代理可以承受短時間的突發(fā)，而不會降低性能。

在我們的研究中，我們分析了云中多個主機之間的數(shù)據包級和流級信息的監(jiān)控。我們首先假設可觀察性的核心特征是如何以非侵入性方式收集數(shù)據。帶著這種展望，我們調查了現(xiàn)有工具，并測試了從 eBPF 數(shù)據路徑中觀察到的數(shù)據包中以流量指標的形式收集可觀測性數(shù)據的不同方法。我們研究了用于收集流指標的數(shù)據結構如何影響流的性能。

理想情況下，為了最大限度地降低主機流量因可觀測代理的開銷而導致的性能下降，我們的分析表明，可以混合使用每 CPU 數(shù)組和每 CPU 哈希數(shù)據結構。這兩種數(shù)據結構可以一起使用，通過使用數(shù)組和每 CPU 哈希映射聚合來處理流量中的短時間突發(fā)。我們目前正在設計可觀察性代理（?https://github.com/netobserv/netobserv-ebpf-agent ），并計劃在未來發(fā)布一篇文章，介紹設計細節(jié)和與現(xiàn)有工具的性能分析。

翻譯自：https://opensource.com/article/22/8/ebpf-network-observability-cloud

擴展閱讀：

• 方法論：面向故障處理的可觀測性體系建設?(https://flashcat.cloud/blog/construction-of-observability-system-for-fault-processing/)

• 白皮書：事件 OnCall 中心建設方法?(https://download.flashcat.cloud/flashduty-white-paper-v1.pdf)

• 好工具：FlashDuty - 一站式告警處理平臺：告警降噪、排班OnCall（https://flashcat.cloud/product/flashduty/）