本文首發於 Erda 技術團隊知乎賬號，更多技術文章可點選 Erda 技術團隊
作者：劉浩楊，端點科技 PaaS 技術專家，微服務治理和監控平臺負責人，Apache SkyWalking PMC成員
原文連結：https://zhuanlan.zhihu.com/p/367779900
前言
Erda Cloud 是我們即將釋出的一站式開發者雲平臺，為企業開發團隊提供 DevOps (DevOps Platform, DOP )、微服務治理 (MicroService Platform，MSP )、多雲管理 (Cloud Management Platform，CMP ) 以及快資料管理 (FastData Platform，FDP ) 等雲原生服務。
作為 Erda Cloud 中的核心平臺，MSP 提供了託管的微服務解決方案，包括 API 閘道器、註冊中心、配置中心、應用監控和日誌服務等，來幫助使用者解決業務系統進行微服務化而帶來技術複雜度難題。伴隨著產品的升級，我們也全新設計了以服務觀測為中心的 APM (應用效能監控) 產品，探索可觀測性在應用監控領域中落地的最佳實踐。
為了讓大家更好的瞭解 MSP 中 APM 系統的設計實現，我們將編寫一個系列專題，深入 APM 系統的產品、架構設計和基礎技術。這是該專題的第一篇，將通過分享我們在可觀測性上的一些思考來開啟這個專題的序章。
從監控到可觀測性
隨著近年來雲原生概念和雲原生架構設計的流行，越來越多的開發團隊開始使用 DevOps 模式進行系統開發，並把大型系統拆解成一個個微小的服務模組，以便系統能更好的進行容器化部署。基於 DevOps、微服務、容器化等雲原生的能力，可以幫助業務團隊快速、持續、可靠和規模化地交付系統，同時也使得系統的複雜度成倍提升，由此帶來前所未有的運維挑戰，比如：
• 模組之間的呼叫從程式內的函式呼叫變為程式間的呼叫，而網路總是不可靠的
• 服務的呼叫路徑變長，使得流量的走向變得不可控，故障排查的難度增大
• 引入 Kubernetes、Docker、Service Mesh 等雲原生系統，基礎設施層對業務開發團隊來說變得更加黑盒
在傳統的監控系統中，我們往往會關注虛擬機器的 CPU、記憶體、網路、應用服務的介面請求量、資源使用率等指標，但在複雜的雲原生系統中，僅僅關注單點或者單個維度的指標，並不足以幫助我們掌握系統的整體執行狀況。在此背景下，對分散式系統的“可觀測性”應運而生。通常，我們認為可觀測性相對於過去監控，最大的變化就是系統需要處理的資料，從指標為主，擴充套件到了更廣的領域。綜合起來，大約有幾類資料被看作是可觀測性的支柱：
• Metrics
• Tracing
• Logging
為了統一可觀測性系統中的資料採集和標準規範，同時提供與供應商無關的介面，CNCF 把 OpenTracing 和 OpenCensus 合併成 OpenTelemetry 專案。OpenTelemetry 通過 Spec 規範了觀測資料的資料模型以及採集、處理、匯出方法，但對於資料如何去使用、儲存、展示和告警是不涉及的，官方目前的推薦方案是：
• 使用 Prometheus 和 Grafana 做 Metrics 的儲存和展示
• 使用 Jaeger 做分散式追蹤的儲存和展示
得益於雲原生開源生態的蓬勃發展，技術團隊可以輕而易舉建設一套監控體系，比如使用 Prometheus + Grafana 搭建基礎監控，使用 SkyWalking 或 Jaeger 搭建追蹤系統，使用 ELK 或 Loki 搭建日誌系統。但對於可觀測性系統的使用者來說，不同型別的觀測資料分散儲存在不同的後端，排查問題仍需要在多個系統之間跳轉，效率和使用者體驗都得不到保證。為解決可觀測性資料的融合儲存和分析，我們自研的統一儲存和查詢引擎，提供了指標、追蹤和日誌資料的無縫關聯分析。在本文的其他部分，將詳細介紹我們是如何提供針對服務的可觀測性分析能力。
觀測的入口：可觀測性拓撲
可觀測性提出了三種資料之間的關係，讓我們可以使用標籤關聯 Metrics 和 Tracing，使用請求上下文去打通 Tracing 和 Log。因此，通常可以使用下面的方法去定位線上應用系統的介面異常：使用 Metrics 和 告警發現問題，然後使用 Tracing 定位到可能發生異常的模組，最後使用 Logging 定位到錯誤根源。
雖然在大多數時間裡這個方法是行之有效的，但我們並不認為這是一個對系統進行觀測的最佳實踐：
• 雖然基於 Metrics 可以幫助我們及時發現問題，但往往我們發現的是大量單點問題，沒有一個全域性的視角來觀測整個系統的狀態
• 業務開發團隊需要去熟悉 Metrics、Tracing 和 Logging 系統的各種概念和使用。如果基於開源元件搭配的監控系統，還需要在各個系統之間不斷跳轉才能完成一次問題的排查，這在今天很多公司裡是經常見的
我們在不同領域使用者的監控需求的實踐中，發現拓撲可以天然的作為觀測系統的入口。不同於常見的分散式追蹤平臺，我們不僅僅把拓撲作為應用系統的執行時架構展示，在基於 100% 取樣的真實請求關係繪製出拓撲後，更進一步在拓撲節點上透出服務的請求和服務例項狀態（未來還會透出更多的觀測資料，比如流量比例、物理節點的狀態等）。
在拓撲頁面的佈局上，我們把頁面切分為左右兩欄，右邊的狀態列會顯示我們需要觀測的系統關鍵指標，如服務例項數、服務的錯誤請求、程式碼異常和告警次數等。當我們點選拓撲節點時，狀態列會檢測節點型別的不同而顯示不同的狀態資料。當前我們支援展示狀態的節點型別有 API Gateway、服務、外部服務和中介軟體。
當點選服務節點時，狀態列會顯示服務的狀態概覽、事務呼叫概覽和 QPS 折線圖
再進一步：如何觀測服務
基於可觀測拓撲，我們可以很容易在全域性的視角下觀察系統的整體狀態，同時我們還提供了一種從拓撲下鑽到服務以便快速定位服務故障的觀測方式。當發現服務異常時，我們允許連結到服務分析，在該頁面提供了事務、異常和程式三個維度的觀測分析。
拿上面提到的介面異常為例，我們的故障排查方式為：在事務分析頁查詢觸發異常的介面 */exception ，然後點選請求或延遲趨勢圖上的資料點關聯介面取樣到的慢事務追蹤和錯誤事務追蹤，在彈出的追蹤列表中檢視請求鏈路詳情和請求關聯的日誌定位錯誤根源。
找到故障的事務請求
自動關聯該請求的呼叫鏈路
為請求鏈路自動關聯日誌上下文
結語：我們要走向哪裡
基於本文篇幅的限制不再過多的去展示產品細節，我們藉助上面的場景拋磚引玉提出一個可觀測性 APM 產品設計的方向：基於系統和服務觀測的角度把不同資料在後端融合分析，而不是刻意強調系統支援可觀測性三種資料的分別查詢，在產品功能和互動邏輯上儘可能對使用者遮蔽 Metrics、Tracing、Logging 的割裂。除此之外，我們也將繼續探索程式碼級診斷、全鏈路分析和智慧運維在可觀測性領域的無限可能性。
附：專題目錄
產品篇
- 我們如何定義 APM
- 資料大盤，隨心所欲
- 你需要什麼樣的告警產品
- 徹底打通監控和日誌的邊界
基礎技術篇
- 詳解 Metrics , Tracing 和 Logging
- 剖析 Java Agent
- NodeJS 的自動探針實現
- 瀏覽器探針知多少
- 可擴充套件 Telegraf
- 容器化日誌採集的實踐
- 流訊息的處理利器: Kafka
- 基於 Flink 實現實時計算
- 為什麼我們需要時序資料庫
- ElasticSearch 在時序資料場景的應用
- 瞭解高效能NoSQL: Cassandra
架構設計篇
- 異構系統的可觀測資料採集架構設計
- 流分析和告警引擎架構設計
- 查詢計算和儲存分離的彈性監控架構設計