All in one：如何搭建端到端可觀測體系

​簡介：一文看懂可觀測！

作者：西傑 & 白玙

可觀測的前生今世

系統的可觀測與故障可分析作為系統運維中重要的衡量標准，隨着系統在架構、資源單位、資源獲取方式、通信方式演進過程，遇到了巨大挑戰。而這些挑戰，也在倒逼着運維相關技術發展。在正式開始今天的內容前，我們來講講可觀測的前世今生，縱觀整個運維監控發展歷程，監控與可觀測已經發展了近 30 年。

​

上世紀 90 年代末，隨着計算從大機（mainframe）逐漸轉移到桌面電腦，client-server 架構的應用開始盛行，大家開始關注網絡性能和主機資源。為了更好的監控這種 CS 的應用，第一代 APM 軟件誕生。運維團隊在這一時期看重與網絡性能、主機性能，因為此時的應用架構還非常簡單。此時，我們還稱這些工具為監控工具。

進入到 2000 年，互聯網飛速發展，瀏覽器成為新的用戶界面。應用演進成為基於瀏覽器的 Browser-App-DB 的三層架構，同時 Java 作為企業級軟件的第一編程語言開始盛行，編寫一次、到處運行（write once，run anywhere）的理念，極大的提升了代碼的生產力，然而 Java 虛擬機也屏蔽了代碼運行的細節，使得調優排錯變得愈加困難， 所以對於代碼級的跟蹤診斷和數據庫的調優成為新的關注點，從而誕生了新一代的監控工具 APM（應用性能監控）。

2005 年之后，分布式應用成為很多企業的第一選擇，像基於 SOA 架構、ESB 的應用大行其道。同時，虛擬化技術逐漸盛行，傳統服務器這個物理單位逐漸淡化，變成了看不見、摸不到的虛擬資源模式。像消息隊列、緩存這樣的三方組件也開始應用在生產環境中。在這樣的技術環境下，催生出新一代 APM 軟件，企業開始需要進行全鏈路追蹤，同時監控虛擬資源和三方組件監控，這樣就衍生出了新一代 APM 的核心能力。

到了 2010 年之后，隨着雲原生架構開始落地實踐，應用架構開始從單體系統逐步轉變為微服務，其中的業務邏輯隨之變成微服務之間的調用與請求。同時虛擬化更加徹底，容器管理平台被越來越多企業接受，三方組件也逐漸演變成雲服務，整個應用架構成為雲原生架構。服務的調用路徑變長，使得流量的走向變得不可控，故障排查的難度增大，需要一種全新的可觀測能力，通過覆蓋全棧的各種可觀測數據（指標，日志，鏈路，事件）在開發測試運維的全應用生命流程進行持續的分析。

可以看到，可觀測能力成為雲原生的基礎設施。整個可觀測能力從單純的運維態開始向測試開發態演進。可觀測的目的也從支撐業務正常運行進一步擴展到加速業務創新，讓業務快速迭代起來。

監控 & APM & 可觀測的認知同異

從上述歷程，我們可以看到從監控到 APM 到可觀測是個不斷演進的過程。接下來，我們講講這三者之間的具體關系。為了更好的講解，這里先引入一個經典認知模型。對於世界萬物，我們通常會按照“知不知道”（awareness）以及“理不理解”（understanding）兩個維度進行划分，即“感知”與“理解”。

​

那么，首先對於我們知道且能理解的事情，我們稱之為事實。落到剛才討論的話題中，這一部分對應的就是監控。比如進行運維工作時，一開始時候就會設計去監控服務器的 CPU 利用率，這個利用率不管是 80% 還是 90%，都是一個客觀事實。這就是監控解決的事情，即基於知道要監控什么，制定采集相應指標，並建立監控大盤。

接下來，就是我們知道但不理解的事情。比如監控到 CPU 利用率達到 90%，但是為什么會到這么高，是原因什么導致的，這就是一個查證的過程。通過APM可以采集並分析主機上的應用性能，發現在應用鏈路調用過程中某個高延時的 log 框架，從而引起了主機上的 CPU 利用率飆升。這就是借助 APM 通過應用層分析去發現 CPU 利用率高的背后原因。

然后，就是我們理解但不知道的事情。依舊是 CPU 利用率高這個場景案例，如果通過學習歷史數據和關聯事件預測到未來的某個時刻會出現 CPU 利用率飆升，就可以實現預警。

最后，就是我們不知道且不理解的事情。還是上面的例子，如果通過監控發現 CPU 使用率飆升，通過 APM 發現應用日志框架所致。但進一步，如果分析這一時間段內用戶的訪問數據，發現在上海地域，通過蘋果終端訪問的請求，相比其他的情況響應時長要高 10 倍，而這種類型的請求由於日志框架的配置產生了海量的 Info 日志，導致了某些機器的 CPU 飆升。這就是一個可觀測的過程。可觀測是需要去解決你事先不知道（來自上海的蘋果終端訪問性能問題）也不理解的事情(錯誤配置日志框架產生海量 info 日志）

簡單總結一下，在監控領域我們關注指標，這些指標可能集中在基礎架構層，比如說機器、網絡的性能指標。然后基於這些指標建立相應看板以及告警規則去監測已知范圍里的事情。在監控發現了問題之后，APM 通過基於應用層面的鏈路以及內存和線程等診斷工具，去定位監控指標異常的根因。

可觀測以應用為中心，通過將日志、鏈路、指標、事件等各種可觀測數據源進行關聯、分析，更加快速、直接地找出根因。並提供一個可觀測界面，讓用戶可以靈活自由的在這些可觀測數據中進行探索與分析。與此同時，可觀測能力與雲服務打通，即時強化應用的彈性擴縮容、高可用等能力，在發現問題時能夠更加快地解決相關問題，恢復應用服務。

建設可觀測體系關鍵要點

可觀測能力帶來了巨大業務價值的同時，也帶來了不小的系統建設挑戰。這不僅僅是工具或技術的選型，更是一種運維理念。這其中包括可觀測數據的采集、分析以及價值輸出三個部分。

​

可觀測數據采集

目前業界廣泛推行的可觀測數據包含三大支柱：日志事件（Logging）、鏈路追蹤（Tracing）、指標監控（Metrics），其中存在一些共性需要關注。

​

1）全棧覆蓋

基礎層、容器層、上方組建雲服務應用，以及用戶終端相應可觀測數據以及與之對應的指標、鏈路、事件都需要被采集。

2）統一標准

整個業界都在推進標准統一，首先是指標（metrics），Prometheus作為雲原生時代的指標數據標准已經形成了共識；鏈路數據的標准也隨着 OpenTracing 和 OpenTelemetry 的推行而逐漸占據主流；在日志領域雖然其數據的結構化程度較低難以形成數據的標准，但在采集存儲和分析側也涌現了 Fluentd，Loki 等開源新秀；另一方面，Grafana 作為各種可觀測數據的展示標准也愈加明朗。

3）數據質量

數據質量作為容易忽視的重要部分，一方面，不同監控系統的數據源需要進行數據標准的定義，確保分析的准確性。另一方面，同個事件可能導致大量重復指標、告警、日志等。通過過濾、降噪和聚合，把具備分析價值的數據進行分析，保證數據質量的重要組成部分。這也往往是開源工具與商業化工具差距相對較大的地方。舉個簡單例子，當我們采集一條應用的調用鏈路，到底采集多深？調用鏈路采樣的策略是什么樣的？發生錯、慢時是不是能夠全部采下來？是不是能夠基於一定規則對采樣策略進行動態調整等等，都決定了可觀測數據采集的質量。

可觀測數據分析

1）橫縱關聯

在目前的可觀測體系里，應用是非常好的分析切入角度。首先，應用與應用之間是相互關聯，可以通過調用鏈關聯起來。其中包括微服務之間是如何調用，應用與雲服務以及三方組件如何調用，都可以通過鏈路進行關聯。同時，應用與容器層、資源層也可進行垂直映射。以應用為中心，通過橫向縱向形成全局可觀測數據關聯。當出現問題需要進行定位時，能夠從應用角度進行統一分析。

2）領域知識

面對海量數據，如何更快速的發現問題，更准確定位問題。除了通過以應用為中心的數據關聯，還需要去定位分析問題的領域知識。對於可觀測工具或產品而言，最重要的就是不斷累積最佳排查路徑、常見問題定位、根因的決策鏈路方法，並把相關經驗固化下來。這相當於為運維團隊配備經驗豐富的運維工程師，去快速發現問題，定位根因。這個也是不同於傳統的 AIOps 能力。

可觀測價值輸出

1）統一展現

上面提到可觀測需要覆蓋各個層次，每層都有相應可觀測數據。但目前可觀測相關工具非常零散，如何將這些工具產生的數據統一展現出來，成了比較大挑戰。可觀測數據的統一其實是相對較難的事情，包括格式、編碼規則、字典值等問題。但數據結果統一呈現是可以做到的，目前主流的解決方案是使用 Grafana，搭建像統一監控大盤。

​

2）協作處理

在統一展現以及統一告警之后，如何借助像釘釘、企業微信等協作平台能夠更加高效地進行問題發現並處理跟蹤的 ChartOps，也逐漸成為剛需。

3）雲服務聯動

可觀測能力成為雲原生的基礎設施，當可觀測平台在發現並定位問題之后，需要與各種雲服務快速聯動，迅速進行擴縮容或負載均衡，從而更快的解決問題。

Prometheus + Grafana 實踐

得益於雲原生開源生態的蓬勃發展，我們可以輕而易舉地建設一套監控體系，比如使用 Prometheus + Grafana 搭建基礎監控，使用 SkyWalking 或 Jaeger 搭建追蹤系統，使用 ELK 或 Loki 搭建日志系統。但對運維團隊而言，不同類型可觀測數據分散存儲在不同后端，排查問題仍需在多系統之間跳轉，效率得不到保證。基於以上，阿里雲也為企業提供了一站式可觀測平台 ARMS（應用的實時監控服務）。ARMS 作為產品家族，包含了不同可觀測場景下的多款產品，比如：

• 針對於基礎架構層，Prometheus 監控服務對包括 ECS、VPC、容器在內的各類雲服務以及三方中間件進行監控。
• 針對應用層，基於阿里雲自研 Java 探針的應用監控全面滿足應用監控需求。相較於開源工具，在數據質量等方面非常大的提升。並通過鏈路追蹤，即使使用開源 SDK 或探針，也可以將數據上報到應用監控平台。
• 針對用戶體驗層，通過移動監控、前端監控、雲撥測等模塊，全面覆蓋用戶在不同終端上的體驗與性能。
• 統一告警，對於各層采集的數據、告警信息進行統一告警以及根因分析，直接通過Insight呈現發現結果。
• 統一界面，不管是ARMS、Prometheus的上報數據，還是日志服務、ElasticSearch、MongoDB 等各種數據源，都可以通過全托管 Grafana 服務進行統一的數據可觀測數據呈現，建立統一的監控大盤，並與阿里雲各種雲服務進行聯動，提供 CloudOps 能力。

上述提到 ARMS 作為一站式產品，具備非常多的能力。目前企業已自建部分與ARMS類似能力，或采用 ARMS 中的部分產品，比如應用監控、前端監控。但完整的可觀測系統對於企業而言，依舊至關重要，並希望基於開源去構建符合自身業務需求的可觀測系統。在接下來的示例中，我們着重講解 Prometheus + Grafana 如何去構建可觀測系統。

數據快速接入

在 ARMS 中，我們可以快速建立一個 Grafana 獨享實例，ARMS Prometheus、SLS日志服務、CMS 雲監控數據源都可以非常便捷的進行數據同步。打開 Configuration，可以快速查看相應數據源。在時間快速接入各種數據源的同時，盡可能降低日常數據源管理的工作量。

​

​

預置數據大盤

在數據完成接入后，Grafana 自動幫大家創建好相應數據大盤。以應用監控以及容器監控大盤舉例，像黃金三指標、接口變化等基礎數據都將默認提供。

​

​

可以看到，Grafana 雖然幫助大家把各種數據看板搭建起來，但看到的依舊是零散大盤。在日常運維過程中，還需要基於業務域或基於應用創建統一大盤，能夠將基礎架構層、容器層、應用層、用戶終端層的數據都放到同一個大盤中進行展現，從而實現整體監控。

全棧統一大盤

在建立全棧統一大盤時，我們按照用戶體驗、應用性能、容器層、雲服務、底層資源等維度進行准備。

1）用戶體驗監控

常見的 PV、UV 數據、JS 錯誤率、首次渲染時間、API 請求成功率、TopN 頁面性能等關鍵數據都會在第一時間呈現。

​

2）應用性能監控

以黃金三指標為代表的請求量、錯誤率、響應時間。並根據不同應用、不同服務進行區分。

​

3）容器層監控

各個 Pod 的性能、使用情況，同時也列出這些應用上跑的由哪些 department 創建的。這些 deployment 相關的 Pod 性能信息都呈現在這一塊。

​

4）雲服務監控

此外，就是相關的雲服務監控，這里以消息隊列 Kafka 舉例，像消息服務常見的相關數據指標如消費量堆積、消費量等數據。

​

5）主機節點監控

針對整個主機節點，CPU、所運行的 Pod 等數據。

​

這樣子，這張大盤就覆蓋了從用戶體驗層到應用層到基礎架構容器層的整體性能監測情況。更加重要的是整個大盤包含着所有微服務的相關數據。當切某個服務，服務相關聯的性能數據都將獨立展現出來。在容器、應用、雲服務等不同層面都進行過濾。這里稍微提一下是怎么做到的，當 Prometheus 監控去采集這些雲服務時，會順帶把雲服務上的 tag 都采集下來。通過對 tag 進行打標，就可以把這些雲服務基於不同業務維度或不同應用進行區分。在做我們統一大盤的時候，一定會遇到非常多的數據源管理問題。這里我們提供了 globalview 能力，把這個用戶名下所有的 Prometheus 實例都匯聚到一起，統一進行查詢。不管是應用層的信息，還是雲服務的信息。

​

借助上面的場景，我們拋磚引玉提出可觀測性平台設計方向：基於系統和服務觀測的角度把不同數據在后端融合分析，而不是刻意強調系統支持可觀測性三種數據的分別查詢，在產品功能和交互邏輯上盡可能對用戶屏蔽 Metrics、Tracing、Logging 的割裂。建立完整可觀測閉環，從事故前異常發現、事故中故障排查到事故后的主動預警監控，為業務持續監控、優化服務性能提供一體化平台。

原文鏈接
本文為阿里雲原創內容，未經允許不得轉載。 

​