作者：西傑 & 白璵
可觀測的前生今世
系統的可觀測與故障可分析作為系統運維中重要的衡量標準，隨著系統在架構、資源單位、資源獲取方式、通訊方式演進過程，遇到了巨大挑戰。而這些挑戰，也在倒逼著運維相關技術發展。在正式開始今天的內容前，我們來講講可觀測的前世今生，縱觀整個運維監控發展歷程，監控與可觀測已經發展了近 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 的割裂。建立完整可觀測閉環，從事故前異常發現、事故中故障排查到事故後的主動預警監控，為業務持續監控、優化服務效能提供一體化平臺。
點選此處，回看精彩視訊演講，瞭解更多可觀測實戰乾貨 ！