*作者：劉洋（炎尋）*

可觀測是為了解決問題，所以在聊可觀測之前，應先對問題排查的普適原則進行了解。

## 背景介紹

### 問題排查的原則

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/eb24b48197b74e40a404ed57b5fc7c8e~tplv-k3u1fbpfcp-zoom-1.image "1.png")

以排查系統問題為例，要理解系統，要先關注基礎知識，理解程式語言基本的電腦科學知識，關注系統大圖比如架構部署和重大流程，要關注執行細節，要對核心功能的演算法和資料結構瞭然於心，還要關注系統的運維工具，能夠了解發布、回滾和監控。

在理解的基礎上，還要能夠復現問題，主要關注問題發生的觸發條件以及問題發生時資料現場的保留，包含指標、鏈路、日誌、事件等。

有了現場再加之對於系統的，才可以定位問題。透過現場保留的資料，進行關聯分析；基於理解，可以快速用二分定位到根因。在定位的過程中，尤其要關注變更，因為有大量的系統問題是由變更導致的。

確定根因後再進行修復，既要治標也要治本，並且要充分驗證，確保不引入新的問題。

以上為問題排查的普適原則，它不僅適用於系統問題的排查，也可以應用到生活的方方面面。

而可觀測使得問題排查的過程更加高效、穩定、低成本。它能夠幫助我們理解系統，出現問題的時候能夠留下足夠多的現場，能夠使資料之間很方便地進行關聯，幫助我們做二分的關聯分析，最終還可以驗證修復是否正確。

### Kubernetes 可觀測挑戰

![2.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/963c003f635640d3a66153f9feb1be3e~tplv-k3u1fbpfcp-zoom-1.image "2.jpeg")

複雜度是恆定的，它不會消失，只會轉移。我們構建的程式語言、程式設計框架、容器作業系統都只是將複雜度關在合適的地方。如果一切執行正常，皆大歡喜；而一旦出現問題，就是災難。複雜度不斷下沉的趨勢使得可觀測面臨了很大的壓力。Kubernetes 的流行使得微服務架構十分普及，多語言、多通訊協議成為常態，這也在另一方面帶來了挑戰。

挑戰 1：端到端觀測複雜度上升，埋點成本居高不下。然而這只是冰山一角，有大量能力下沉到 Kubernetes 管控層、容器執行層、網路和作業系統層面，這些基礎設施能力的下沉帶來了很大挑戰。

挑戰 2：由於關注點的分離，使得應用問題與底層問題無法自頂向下形成關聯。

挑戰 3：雖然有很多工具，但是上下文缺失、資料散落，導致無法透過這些資料很好地理解應用，因為現場的缺失無法關聯，而使問題排查效率低下。

可觀測需要有統一的技術來解決自身的複雜度。

## 基於 eBPF 的可觀測實踐分享

### eBPF 介紹

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/14a73391c80d47358f57d2d54826998b~tplv-k3u1fbpfcp-zoom-1.image "3.png")

從一開始，核心就是可觀測的絕佳位置，然而由於效率和安全問題一直無法實現。經過多年發展，eBPF 技術為可觀測開啟了新的大門。

eBPF 是一項可以安全地在核心中執行沙盒程式的技術，無需修改程式碼即可在核心使用者態程式事件發生時執行。它具備以下特性：

**無侵入特性**：觀測成本極低，應用無需修改任何程式碼，也無需重啟程式。

**動態可程式設計性**：無需重啟探針，動態下發 eBPF 指令碼即可修改探針側的邏輯。

**高效能**：自帶 JIT 編譯，使探針能夠獲得核心本地執行的效率。

**安全**：verifier 機制限制了 eBPF 指令碼能夠訪問的核心函式，保證核心執行的穩定。

除了這些令人振奮的特性外，eBPF 的使用流程也非常方便。以監控、應用、效能為例，只需要載入編譯 eBPF 程式監聽網路的核心事件，解析網路協議，然後聚合成指標，輸出 Trace 即可。

eBPF 得到了很多大公司的支援，發展十分迅猛。過去一年，阿里雲可觀測團隊基於 eBPF 技術構建了統一可觀測平臺。其架構如下圖：

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e135235bf86349f7803bd53a6170799a~tplv-k3u1fbpfcp-zoom-1.image "4.png")

基於 eBPF 的統一可觀測平臺架構

最底層是資料採集層，主要採用 Tracepoints、Kprobre、eBPF 函式抓取相關係統呼叫，關聯程式容器資訊，形成原始事件，並透過 eBPF 和 sysdig 的結合支援多核心版本。同時為了解決事件爆炸的問題，引入了事件過濾和高效能事件傳輸機制。

往上是資料處理層。使用者態獲取到原始事件後，首先進行協議的解析，生成指標、鏈路、日誌等資料，過程中也會對資訊做收斂。然後填充元資訊，比如 K8s 資訊填充或自定義應用資訊填充，最後監控資料會透過 OpenTelemetry Collector 輸出。引入 OpenTelemetry Collector 主要為了支援多種資料型別以及多資料傳輸通道，支援將監控資料寫入使用者指定的儲存。

再往上是資料儲存層，預設情況下，指標會使用 influxDB 儲存在 Prometheus，鏈路和日誌使用 SLS 儲存在 Trace。

最上是資料服務層，透過 ARMS 的前端以及 Grafana 最終呈現給使用者多種多樣的可觀測服務。

### 如何進行無侵入式多語言的協議解析

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/4285bdc3034a42e1821941254491a411~tplv-k3u1fbpfcp-zoom-1.image "5.png")

ARMS 可觀測團隊關注 eBPF 在應用層的應用，透過監聽網路核心呼叫，構建連線跟蹤，將傳輸的網路包進行協議分析，得到應用層面的請求響應，最終得以無侵入式地支援多語言場景下請求數、響應時間、錯誤數、黃金指標的監控。

目前我們支援 HTTP、 Redis 、DNS、Kafka、MySQL、gRPC 、http2 等協議，支援的協議列表也在不斷擴充中。

### 線上問題與解決方法

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e19818db69de4c79bf8283ac72e1a9ce~tplv-k3u1fbpfcp-zoom-1.image "6.png")

經過一年多的生產實踐，遇到最多的問題主要有以下四個：

第一，**核心版本適配問題**。eBPF 在核心版本 4.14 以上才有較為成熟的支援。但是線上依然存在很多老的核心版本，這部分需要使用 sysdig 進行支援。高版本在 core 不成熟的情況下，使用動態下載核心圖檔案以及動態編譯的方式進行支援。

第二，**核心事件爆炸**。傳統的監聽 Tracepoints、Kprobre 會產生巨大的事件，給探針的效能造成巨大壓力。為了解決這個問題，我們引入了事件過濾機制，只處理網路呼叫事件，同時最佳化事件傳輸序列化，達到高效能事件傳輸的目的。

第三，在事件的消費側，**協議解析效率低下**。為此我們最佳化了高效能解析演算法，比如可以減少分析的位元組數，最佳化更多的匹配演算法提升解析的效率。同時還使用了多執行緒記憶體複用等工程手段提升協議解析效率。

第四，**指標時間線爆炸**。所有事件最終都會聚合為指標、鏈路和日誌，其中指標方面由於個別維度發散，會對儲存的穩定性造成極大的影響。因此，我們支援在寫指標的時候進行維度收斂，比如每個維度的基數不得超過 100，超過後將收斂成星號，代表通用的收斂標記。此外，還在查詢側進行了最佳化，主要做了精度的降級。

## 統一可觀測互動介面

### 統一告警

![7.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bb568ab5e0c94b77b10ad95fa82889ba~tplv-k3u1fbpfcp-zoom-1.image "7.jpeg")

eBPF 技術的無侵入性以及多語言支援的特性使得開箱即用成為了可能。基於此，阿里雲可觀測團隊開始構建統一可觀測介面。

首先是統一告警。接入阿里雲 eBPF 監控，我們設計了一套預設的告警模板，涵蓋了應用層、 K8s 管控層、基礎設施層和雲服務層，提供了開箱即用的幫助使用者發現問題的能力。

### 統一的關聯分析邏輯

![8.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8b56d7bd3e8c4a52b6bc347f6875eac0~tplv-k3u1fbpfcp-zoom-1.image "8.png")

有了 eBPF 儲存現場資料，加上告警系統告知存在問題，後續應如何統一進行關聯分析，找到根因？

我們認為需要有一個介面來承載關聯分析邏輯。它應當目標明確，比如要解決容量規劃問題、成本消耗問題還是應用效能問題；它應當內容豐富，包含解決問題需要的所有內容，比如指標、鏈路、日誌、事件、問題的影響面、關聯關係等；它應當具備非常清晰的使用路徑，能夠回答當前是否有問題，未來是否有問題、問題的影響是什麼、問題的根因是什麼、使用者能做什麼等，以此一步步引導使用者解決問題。

### 統一 Grafana 大盤

![9.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/fbee022cb8cb4b0ca25694bb703d6bbd~tplv-k3u1fbpfcp-zoom-1.image "9.png")

基於以上設想，我們推出了統一的 Grafana 大盤。它符合關聯分析邏輯，無論是全域性還是特定實體都有總覽，能夠發現問題細節，能夠排查問題；它包含日誌、事件、指標等多資料來源，以告警異常閾值為驅動，整個大盤可以互動、點選跳轉，可以定位根因，涵蓋了 K8s 叢集最核心的資源型別。

### 統一拓撲圖

![10.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c4c4705aebf7458bb82b97c5e0043120~tplv-k3u1fbpfcp-zoom-1.image "10.png")

我們也推出了統一的拓撲大圖，它具備拓撲感知、依賴分析、流量監控、上下文關聯等特性，可以按維度篩選節點和邊，構建業務語義化的檢視。

### Demo 演示：基於 eBPF 的統一互動頁面

![11.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c980736631e34004ab402e5acf3530b4~tplv-k3u1fbpfcp-zoom-1.image "11.png")

在容器服務 ACK 進入一個叢集后，點選運維管理，進入叢集拓撲功能頁面。如果沒有安裝 eBPF 探針則會提示安裝，安裝完成後開箱即用，可以獲得整個叢集的流量拓撲。

頁面包含了 deployment、deamonset、和 statfulset 之間的流量關係。點選節點可以看到它對外提供的應用效能，也可以檢視節點的上下游。透過上下游的檢視，可以快速檢查它是否按照預定的架構執行。

此外，也可以點選邊進行檢視，比如可以看到 MySQL 的 QPS 以及響應時間等。

![12.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bb907d35c97f4ce7ad6989e258ffe17d~tplv-k3u1fbpfcp-zoom-1.image "12.png")

除了檢視指標，還可以檢視詳情，比如檢視 SQL 語句以及網路耗時，比如請求發到對端用了多久、對端處理用了多久、響應的內容下載耗時多久等，可以快速定位問題所在。同時還提供了節點過濾的能力，可以快速過濾出使用者感興趣的節點，同時也可以搜尋對應的節點。

![13.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dd023cc574664fbe8630fc35426724fa~tplv-k3u1fbpfcp-zoom-1.image "13.png")

Grafana 統一的大盤為 1+N 的模式。1是指叢集的全域性大盤提供了整個叢集最核心的資源總覽，包含事件，可以快速檢視各類事件的個數及詳情，可以檢視節點是否健康、無狀態應用 deployment 是否健康以及有狀態應用、deamonset 等。

![14.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/c40df0b83b2f406db19b2610515ae1d4~tplv-k3u1fbpfcp-zoom-1.image "14.png")

每一個特定資源總覽的結構也是一致的，包含“總”和“分”。“總”是對整個叢集進行概括的總結，可以快速透過閾值確認是否有問題，有問題的閾值會用鮮豔的顏色標出。比如上圖可以看出有 1 個節點的 CPU 請求率過高，而具體哪一個節點的請求率過高，則由“分”負責查詢，透過請求率排序，快速找到問題節點。

![15.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/112b864e39814f7ea12e3bfec2e7c17f~tplv-k3u1fbpfcp-zoom-1.image "15.png")

上圖顯示叢集級別有兩個 Pod 不是 ready 狀態。透過對 phase 進行排序快速獲取兩個處於 pending 狀態的 Pod。也可以看到有 15 個 Pod 在過去 24 小時存在重啟行為，進行排序後即可快速找到這些 Pod。

![16.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/722be67bebac4714b111bfadf4c98f56~tplv-k3u1fbpfcp-zoom-1.image "16.png")

可以點選具體節點，檢視其 CPU 請求率的 top 10 ，點選檢視詳情後可在系統資源裡進行檢視，以判斷請求量是否合理，並進行修正。

由此可見，Grafana 大盤具備很強的互動能力和邏輯。

![17.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/674e1200af8b4bc390d95268aadebbcb~tplv-k3u1fbpfcp-zoom-1.image "17.png")

前端應用的每一個 deployment 或資源詳情頁也具備排查邏輯。概覽中展示了管控層、CPU、網路、記憶體等情況，一眼便能知曉系統是否存在問題，可以快速檢視問題所在。

![18.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/72cfc57f801d4b68868ad5ad7dd61bfd~tplv-k3u1fbpfcp-zoom-1.image "18.png")

與此同時，大盤還整合了日誌以及 7 層的應用性。

以上能力全部是基於 eBPF 的無侵入性提供的開箱即用的能力。

## 總結與展望

### 總結

![19.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/5979835e1b3f49408ba94a7787535101~tplv-k3u1fbpfcp-zoom-1.image "19.png")

阿里雲可觀測團隊構建了 kubernetes 統一監控，無侵入式地提供多語言、應用效能黃金指標，支援多種協議，結合 Kubernetes 管控層與網路系統層監控，提供全棧一體式的可觀測體驗。透過流量拓撲、鏈路、資源的關係，可進行關聯分析，進一步提升在 Kubernetes 環境下排查問題的效率。

### 展望

![20.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/13535d18955c406b8f52f997ab0a16bd~tplv-k3u1fbpfcp-zoom-1.image "20.png")

未來，阿里雲可觀測團隊將進一步挖掘 eBPF 全覆蓋、無侵入、可程式設計的特性，在以下三個方面持續發力：

第一，可擴充套件 APM，簡稱 eAPM。圍繞 APM 不斷擴充套件邊界，解決其侵入每種語言都需要單獨埋點的問題，解決在應用層面看不到的底層黑盒問題，包括以下幾個方面：

1. 無侵入式的多語言效能監控。

2. 無侵入式的分散式鏈路追蹤。

3. 應用請求粒度的系統與網路分析。

第二，提供工具，針對包括 tracing、profiling、動態網路包跟蹤以及核心事件在使用者態進行處理的開發框架進行最佳化。

第三， 實現 eBPF 增強的內建指標、鏈路和日誌，主要包括對應用協議更多的支援以及高階的系統指標和網路指標。

![21.jpeg](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/b8780507963c4bfe93089862e5ade597~tplv-k3u1fbpfcp-zoom-1.image "21.jpeg")

基於 eBPF 的 Kubernetes 可觀測實踐

相關文章