*作者：* *井軼*

## 為什麼要進行可觀測性建設

可觀測性並不是一個新詞，該詞來源於控制理論，是指系統可以由其外部輸出推斷其其內部狀態的程度，隨著 IT 行業幾十年的發展，IT 系統的監控，告警，問題排查等領域的逐漸成熟，IT 行業也將其抽象形成了一整套可觀測性工程體系。而之所以該詞在這幾年愈發火熱，很大程度是因為雲原生，微服務模式，DevOps 等技術的不斷流行，對可觀測性提出了更大的挑戰。

雲原生架構所倡導的微服務、DevOps 模式，同時帶來了效率、可用性的提升， 但同時也極大程度增加了系統的複雜度， 也因此增強可觀測性成了降低複雜度的唯一手段。

這裡需要特別注意的是可觀測性並不是監控，傳統監控僅僅能夠做到問題被動發現，可觀測性的核心是基於對事先未定義的屬性和模式的探索， 其不僅僅單純是發現問題，更著重於對系統在執行時提供對其理解、探查以及排程的能力。

可觀測性的基石指標、日誌、事件、鏈路資料能夠幫助我們更好的理解執行的系統，為事前預防、事中處理、事後覆盤提供了重要決策依據， 同時可觀測性體系也能夠加速應用的持續交付，這就是為什麼我們需要進行可觀測性建設的原因。

## 如何針對閘道器場景進行可觀察性建設

### 確定可觀測性體系建設的目標

在沒有監控或是監控混亂的狀態下，開發者衡量系統的執行狀態，都是靠一些不成體系的零散指標，盲人摸象，看不到全域性。發生問題時，多是靠一些元老級開發者透過自己經驗，從多個指標裡模糊構建出業務全域性狀態，這個經驗往往是不可複用的。

因此我們需要是透過技術手段建立系統的可觀測性，可以清晰地“看見”系統執行的全面詳細狀態，降低經驗門檻和不確定性，做出及時有效的決策。可觀測性解決方案應當實現如下目標：

-   透過可觀測性體系能夠決定是否實施服務降級或者服務中斷
-   當服務不可用、服務降級、失敗時，能夠快速發現。
-   在服務不可用，失敗時，能夠幫助除錯。
-   確定容量規劃和業務目標的長期趨勢。
-   揭示更改或新增的功能的意外副作用。

### 構建閘道器通用可觀測性指標

可觀測性體系構建的目標是清晰的，但是僅僅只是使用了某些工具，加了某些監控並不足以實現目標，基於不同的業務場景需要有的放矢，不同經驗的工程師可能會用不同型別的監控體系,  但核心是可觀測性體系使用的監控體系能夠正確反應系統的真實情況。

在閘道器可觀測性體系的構建中，將主要的監控分為黑盒監控與白盒監控

-   黑盒監控:  一種基於取樣的方法。黑盒系統將監控負責使用者請求的同一系統。最常用的是使用撥測模擬使用者正常請求來訪問業務。

-   白盒監控: 監控和可觀測性依賴於從處於監控的工作負載傳送到監控系統中的訊號。這通常可以採用三個最常見元件的形式：指標、日誌和 trace

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

白盒監控中，指標的選擇是件相對主觀的事情，選擇的指標能否準確體現系統的真實情況嚴重影響到整體可觀測性體系目標的實現。

這裡我們不妨回到閘道器最基礎的功能，正是由於閘道器的代理功能，閘道器會天然沉澱通用邏輯如鑑權等，但本質仍然是對流量進行轉發。

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

在這裡我們將請求發起方稱為閘道器的下游，請求轉發的目的服務成為稱為上游,  下游請求者是最能感知整體系統情況的，因此我們將閘道器服務型別指標的下游的成功率，請求量，RT 作為衡量整個閘道器的核心指標。

當然，這三個指標在多數系統中都是核心指標。在確定核心指標後，我們需要確定系統的路徑指標,  即核心指標發生變化的時候，我們透過檢視路徑指標，能夠快速定位問題的原因所，比如 CPU 佔用百分比不斷飆高時閘道器的耗時會同比增加，因此我們將系統指標(CPU， 記憶體，網路流量，連線數)，服務指標中的上下游依賴(例如後端服務的端點變化情況)作為閘道器的二級指標。

透過上面的指標我們就基本確定了閘道器的可觀測性指標，但是閘道器本身只是業務系統的一環，業務完整的可觀測性需要結合業務場景去進行構建，例如使用閘道器日誌記錄業務側狀態碼構建業務指標。

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

## 基於雲原生閘道器的可觀測性建設最佳實踐

雲原生閘道器是阿里雲微服務引擎(MSE)下的一款託管型別閘道器產品，其將傳統的流量閘道器與微服務閘道器進行了整合，作為雲上產品他無縫支援來雲上的可觀測性產品 ARMS、SLS，力爭對客戶零門檻，同時立足開源，閘道器也相容了 zipkin, skywalking, prometheus 等可觀測開源產品。下面基於前文所講述的可觀測體系構建的思路，基於雲上產品來構建可觀測性體系，並以實際場景說明閘道器場景的可觀測性使用。

### 灰度釋出場景中的可觀測性

我們以服務新版本釋出的場景作為雲原生閘道器可觀測性的具體例子 。

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

在上圖的釋出過程中，最前端的流量會在服務 v1 和 v2 之間進行切換，在這個場景中，我們的核心是可觀測效能夠及時保證應用釋出過程中應用釋出導致的異常能夠及時被觀測到。

在新應用部署前，我們應當首先將閘道器預設提供的可觀測效能力開啟， 首先開啟閘道器的基礎指標監控(cpu, 記憶體, 整體成功率)， 並針對該場景在告警配置中開啟服務級別監控，以便在 httpbin 服務的成功率下降時能夠及時發現。

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

在開始之前我們已經部署了 httpbin v1 版本。

之後我們開始正式在阿里雲 ACK 叢集中部署 httpbin v2 版本的應用，該叢集之前已經部署過 httpbin v1 的應用。

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

並在閘道器的服務詳情中，為 go-httpbin 服務增加 v2 的子版本。

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

並透過修改路由配置將 go-httpbin 服務 v2 的流量切為 10%，此時使用 http 請求呼叫閘道器，可以檢視到閘道器流量在版本之間的分佈。

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

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

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

雲原生閘道器路由介面內建的監控能夠有效幫助我們觀測新版本與舊版本的執行狀態，告警也能夠在新服務釋出有問題時及時發現異常。

### 使用 ARMS 撥測來檢驗真實環境下的業務

在真實的環境中，閘道器自身的執行指標並不能完全確認整個業務的執行狀態，DNS 劫持，網路故障等問題很有可能造成部分使用者的完全無法使用，在這種情況下我們需要完全模擬使用者使用黑盒指標來驗證系統的穩定性，在這裡我們使用 ARMS 提供的雲撥測產品用來觀測業務的真實情況。

在阿里雲建立定時撥測任務, 透過設定不同的觀測點來觀測不同地域的使用者訪問業務的真實情況。

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

間隔一段時間後，我們就可以得到撥測的結果詳情。

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

### 結合閘道器的可觀測性體系構造業務的可觀測性體系

由於不同業務區別的區別，閘道器只能提供了閘道器自身的可觀測能力，但透過閘道器提供的擴充能力，我們可以將閘道器的可觀測能力與業務的結合起來，用來構建業務自身的可觀測性體系。

例如一個書城服務，我們在閘道器層去監控不同使用者的訪問呢？這裡我們可以利用結構化日誌和 SLS 提供的日誌消費來實現。閘道器可以透過自定義請求頭將必要的資訊提取出來，並投遞到日誌服務。

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

在實際應用中，我們最常見的就是將在請求 header 中的使用者 id 提取到日誌中，從而實現 userId 和閘道器請求的關聯，在開啟自定義日誌個時候，我們可以對投遞的日誌使用日誌服務的資料加工對原始日誌進行提取。

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

透過該方式我們不僅能夠將有意義的業務資訊與閘道器進行關聯，同時可以將不必要的訪問資訊進行丟棄，從而減少成本

## 總結與展望

本文主要介紹了基於雲原生閘道器構造可觀測效能力的最佳實踐，並透過介紹的三種實踐覆蓋了白盒觀測，黑盒觀測，基於閘道器構造業務可觀測性等方面，針對可觀測，雖然目前使用者可以基於目前的可觀測體系來快速發現,定位問題， 但我們目前能做的還有很多。

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

配合業界的發展方向，接下來雲原生閘道器在可觀測領域主要有如下規劃：

-   就可觀測性的三大資料支柱來說，為了解決部署上的跨平臺方案冗雜以及資料不互通問題，Metrics、Logs、Traces 大一統的可觀測性採集框架發展是大勢所趨，支援 opentelemetry 等統一的可觀測性框架是接下來的首要工作 
-   在根因分析方面我們也在關注行業最先進演算法的動態，持續的探索進行智慧根因分析的實踐。

MSE 雲原生閘道器預付費、MSE 註冊配置預付費首購 8 折，首購 1 年及以上 7 折。點選[此處](https://www.aliyun.com/product/aliware/mse)，即享優惠！

基於雲原生閘道器的可觀測性最佳實踐

相關文章