作者：夏明（涯海）

## OPLG 是什麼

隨著雲原生架構的興起，可觀測的邊界與分工被重新定義，傳統的容器/應用/業務分層監控邊界被打破，Dev、Ops、Sec 的分工逐漸模糊。大家意識到 IT 系統作為一個有機的整體，對 IT 系統狀態的監測與診斷也需要一體化的方案。經過近幾年的摸索與實踐，基於 OPLG 的新一代雲原生可觀測體系，逐步成為了社群與企業的熱門選擇。

OPLG 是指將 (O)penTelemetry Traces、(P)rometheus Metrics、(L)oki Logs 透過 (G)rafana Dashboards 進行統一展示，滿足企業級監控與分析的大部分場景，如下圖所示（圖片來源於 Youtobe Grafana Labs）。基於 OPLG 體系可以快速構建一套覆蓋雲原生應用全棧的統一可觀測平臺，全面監測基礎設施、容器、中介軟體、應用及終端使用者體驗，將鏈路、指標、日誌、事件有機整合，更高效的達成穩定性運維與商業化分析目標。

## OPLG 自建方案

小明加入了一家潮牌買手公司，專門幫助年輕人尋找優質潮牌好貨。隨著業務規模的不斷擴大，系統穩定性及商業化分析對全域性可觀測的要求也“水漲船高”，底層系統故障直接了影響業務營收與客戶滿意度。為此，小明所在的 IT 部門透過 OPLG 體系構建了一套全新的可觀測平臺，具備“快速接入、靈活擴充套件、無縫遷移、異構融合”等優勢。

###  OPLG 優勢
• **快速接入**：由於 OpenTelemetry 和 Prometheus 社群提供的大量成熟的開源 SDK/Agent/Exporter，無需大量程式碼改造，即可快速接入主流元件與框架的鏈路追蹤與指標監控。
• **靈活擴充套件**：基於 PromQL/LogQL 靈活的查詢語法，與 Grafana 豐富的大盤定製功能，可以滿足各個業務線或運維團隊的個性化可觀測需求。
• **無縫遷移**：考慮到資料安全性及未來海外業務發展規劃，可觀測平臺沉澱的元件埋點、自定義大盤能夠在不同雲服務商之間無縫遷移。相比於商業化大盤深度鎖定使用者，Grafana 可以整合多種資料來源，真正實現“端到端遷移自由”。
• **異構融合**：Java、Go、Node.js 等不同語言的應用，以及多雲環境的可觀測資料能夠互聯互通，統一展示。

###  OPLG 挑戰

雖然 OPLG 體系具有多種優勢，但是企業自建也會面臨多重挑戰，特別是在深度使用的過程中，許多規模化運維、效能、成本等非功能性問題將逐漸凸顯。

• **元件規模化升級與配置**：客戶端探針的規模化管理幾乎是運維團隊的“夢魘”，探針異常引發的各種故障也是屢見不鮮。此外，動態配置下推與功能降級這類“保命大招”，通常也需要企業自建配置中心，自行開發與管理。

• **Traces 全量採集與儲存成本**：中大型企業生產系統的日均呼叫量可以達到上億級別，呼叫鏈全量上報和儲存的成本是個不小的開銷，對哪些鏈路進行取樣成本最優？鏈路取樣導致的指標監控與告警不准問題又該如何解決？

• **Metrics 大體量查詢效能**：一次查詢掃描的指標數越多，查詢效能越差。當查詢時間範圍超過一週或者一個月時，經常會遇到查詢卡頓甚至於無法查詢出結果。此外，APM Metrics 還會經常遇到 URL / SQL 發散導致的指標線過多，打爆儲存與查詢層。

• **海量告警排程時延與效能**：每一條告警規則都代表著一個定期輪詢任務，當告警規則超過千級別，甚至萬級別時，經常會遇到告警延遲傳送，甚至無法傳送的情況，錯失了故障排查的最佳時機。

• **元件容災能力弱**：多地域/可用區容災，是保障服務高可用的重要手段。但是，由於容災能力建設，需要技術與資源的雙重投入，很多企業自建系統都不具備容災能力。
上述問題都是企業自建可觀測體系過程中會遇到的經典問題，這些由於規模帶來的效能及可用性問題，需要投入大量研發和時間進行沉澱，大幅增加了企業運維成本。因此，越來越多的企業選擇將可觀測服務端託管給雲服務商，在享受開源方案技術紅利的同時，也能得到持續、穩定的服務保障。

## OPLG 託管方案

為了降低運維成本，更穩定的提供可觀測服務，小明所在的 IT 部門決定採用由阿里雲 ARMS 提供的 OPLG 託管方案，該方案在保留開源方案優勢的基礎上，提供了高效能、高可用、免運維的後端服務，幫助小明團隊解決了海量資料場景下的規模化運維難題。此外，透過 eBPF 網路探測、Satellite 邊緣計算和 Insights 智慧診斷，進一步提升了可觀測資料的覆蓋度和整合度，如下圖所示。

**• 高效能**：支援無損統計，資料壓縮，連線最佳化，發散指標自動收斂，DownSample 等技術，大幅降低海量資料場景下的效能開銷。

**• 高可用**：客戶端支援資源限額與自動限流保護，保證高壓場景下的叢集穩定性；後端服務支援彈性水平擴容，多地域/多可用區容災，盡最大可能保障服務可用性。

**• 靈活易用**：JavaAgent、OT Collector、Grafana Dashboard Template 託管升級，自動適配更新，無需使用者管理；支援動態配置下推，實時調整流量開關，呼叫鏈取樣率，介面過濾與收斂規則等引數。

• **網路探測**：透過 eBPF 無侵入地分析網路請求，自動解析網路協議，構建網路拓撲，展示特定容器之間或容器與特定雲產品例項之間的網路效能。

**• 邊緣計算**：透過 Satellite（OpenTelemetry Collector）實現了可觀測資料在使用者叢集內的邊緣採集與計算能力，規範資料格式，統一資料標籤，有效提升 Trace/Metrics/Logs 資料之間的關聯度。

**• 智慧診斷**：結合多年沉澱的領域知識庫和演算法模型，對常見線上故障問題（如慢SQL、流量不均）進行定期巡檢，自動給出具體的根因分析與建議。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/add04337a7c84c6fb05dfdc539fb0eeb.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

##  ARMS for OpenTelemetry Satellite

近兩年 OpenTelemetry 和 SkyWalking 等社群都在大力研發邊緣採集與計算 Satellite 方案。ARMS for OpenTelemetry Satellite（簡稱ARMS Satellite）是一套基於 OpenTelemetry Collector 開發的可觀測資料（Traces、Metrics、Logs）邊緣側統一採集與處理平臺，具備安全、可靠、易用等特性，適合生產環境接入。

ARMS Satellite 透過邊緣側的資料採集、處理、快取與路由，可以實現多源異構資料的標準化；增強 Traces、Metrics、Logs 可觀測資料間的關聯性；支援無損統計，降低資料上報和持久化儲存成本等。

### 適用場景一：全景監控資料一鍵採集與分析（容器環境）

ARMS Satellite 在容器服務 ACK 環境下，深度整合了阿里雲 Kubernetes 監控元件與 Prometheus 監控元件，一鍵安裝完成後，會自動採集 Kubernetes 容器資源層和網路效能資料。結合使用者上報的應用層資料（只需修改 Endpoint，無程式碼改造）與自動預聚合指標，全部上報至全託管的服務端資料中心，再透過 Grafana 進行統一展示。最終實現覆蓋應用、容器、網路、雲元件的全景監控資料採集與分析。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/d3ae057a892a4b648ebe0c9bf0c0189f.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

### 適用場景二：多雲/混合雲網路，異構 Tracing 框架資料關聯與統一展示

在多雲/混合雲架構下，不同叢集或應用間的鏈路追蹤技術選型可能存在差異，比如 A 採用了 Jaeger，B 採用了 Zipkin，不同鏈路追蹤協議上報的資料格式互不相容，無法串聯，大幅降低了全鏈路診斷效率。

透過 ARMS Satellite 可以將不同來源的鏈路統一轉化為 OpenTelemetry Trace 格式，並上報至統一的服務端進行處理和儲存，使用者可以輕鬆實現跨網路或異構鏈路框架的聯合資料查詢與分析。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/408172fa917249d7adabac57d487fa8b.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

### 適用場景三：鏈路取樣+無損統計，低成本實現應用監控告警精準統計

生產系統的日均呼叫量可以達到億級別，呼叫鏈全量上報和儲存的成本是個不小的開銷，對呼叫鏈執行取樣儲存是個不錯的選擇。然而，傳統的鏈路取樣會導致鏈路統計指標的準確性大幅下降，比如一百萬次真實呼叫經過 10% 取樣後保留的十萬次呼叫，對其統計得到的結果會產生明顯的“樣本傾斜”，最終導致監控告警誤報率過高，基本處於不可用狀態。

ARMS Satellite 支援 Trace 資料無損統計，對接收到的 Trace 資料自動進行本地預聚合，得到精準的統計結果後再執行鏈路取樣上報，這樣在降低網路開銷和持久化儲存成本的同時，保證了應用監控與告警指標的準確性。預設整合的 Satellite APM Dashboard 如下圖所示。

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/76d2807f483d485ab153b76dc7e7a941.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA6Zi_6YeM5be05be05LqR5Y6f55Sf,size_20,color_FFFFFF,t_70,g_se,x_16)

## 總結

OPLG 體系擁有成熟且富有活力的開源社群生態，同時也經過了大量企業生產環境的實踐檢驗，是當下建設新一代雲原生統一可觀測平臺的熱門選擇。但是，OPLG 只是提供了一個技術體系，如何靈活運用，解決實際問題，沉澱出通用行業或場景的最佳實踐，還需要大家一起來探索。

## 相關連結
[1] OpenTelemetry
https://opentelemetry.io/

[2] Prometheus
https://prometheus.io/

[3] Grafana Loki
https://grafana.com/oss/loki/

[4] Grafana Labs
https://grafana.com/

[5] ARMS for OpenTelemetry Satellite —— 助力邊緣可觀測
https://help.aliyun.com/document_detail/418462.html

[6] 阿里雲 Prometheus 監控
https://help.aliyun.com/document_detail/195983.html

[7] 阿里雲 Kubernetes 監控
https://help.aliyun.com/document_detail/260777.html

[8] 阿里雲 Grafana 服務
https://help.aliyun.com/document_detail/311928.html

### 推薦社群
【穩定大於一切】打造國內穩定性領域知識庫，**讓無法解決的問題少一點點，讓世界的確定性多一點點。**

• GitHub 專欄地址 (https://github.com/StabilityMan/StabilityGuide)
• 釘釘交流群號：30000312
• 如果閱讀本文有所收穫，歡迎分享給身邊的朋友，期待更多同學的加入！

點選[此處](https://www.aliyun.com/activity/middleware/observability?spm=a2c6h.12873639.article-detail.14.4e16bb9cchjT2S)，瞭解阿里雲可觀測更多資訊！

OPLG：新一代雲原生可觀測最佳實踐

相關文章