01

可觀測的前生今世

Cloud Native

系統(tǒng)的可觀測與故障可分析作為系統(tǒng)運維中重要的衡量標(biāo)準(zhǔn)，隨著系統(tǒng)在架構(gòu)、資源單位、資源獲取方式、通信方式演進過程，遇到了巨大挑戰(zhàn)。而這些挑戰(zhàn)，也在倒逼著運維相關(guān)技術(shù)發(fā)展。在正式開始今天的內(nèi)容前，我們來講講可觀測的前世今生，縱觀整個運維監(jiān)控發(fā)展歷程，監(jiān)控與可觀測已經(jīng)發(fā)展了近 30 年。

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

進入到 2000 年，互聯(lián)網(wǎng)飛速發(fā)展，瀏覽器成為新的用戶界面。應(yīng)用演進成為基于瀏覽器的 Browser-App-DB 的三層架構(gòu)，同時 Java 作為企業(yè)級軟件的第一編程語言開始盛行，編寫一次、到處運行（write once，run anywhere）的理念，極大的提升了代碼的生產(chǎn)力，然而 Java 虛擬機也屏蔽了代碼運行的細(xì)節(jié)，使得調(diào)優(yōu)排錯變得愈加困難， 所以對于代碼級的跟蹤診斷和數(shù)據(jù)庫的調(diào)優(yōu)成為新的關(guān)注點，從而誕生了新一代的監(jiān)控工具 APM（應(yīng)用性能監(jiān)控）。

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

到了 2010 年之后，隨著云原生架構(gòu)開始落地實踐，應(yīng)用架構(gòu)開始從單體系統(tǒng)逐步轉(zhuǎn)變?yōu)槲⒎?wù)，其中的業(yè)務(wù)邏輯隨之變成微服務(wù)之間的調(diào)用與請求。同時虛擬化更加徹底，容器管理平臺被越來越多企業(yè)接受，三方組件也逐漸演變成云服務(wù)，整個應(yīng)用架構(gòu)成為云原生架構(gòu)。服務(wù)的調(diào)用路徑變長，使得流量的走向變得不可控，故障排查的難度增大，需要一種全新的可觀測能力，通過覆蓋全棧的各種可觀測數(shù)據(jù)（指標(biāo)，日志，鏈路，事件）在開發(fā)測試運維的全應(yīng)用生命流程進行持續(xù)的分析。

可以看到，可觀測能力成為云原生的基礎(chǔ)設(shè)施。整個可觀測能力從單純的運維態(tài)開始向測試開發(fā)態(tài)演進。可觀測的目的也從支撐業(yè)務(wù)正常運行進一步擴展到加速業(yè)務(wù)創(chuàng)新，讓業(yè)務(wù)快速迭代起來。

02

監(jiān)控 & APM & 可觀測的認(rèn)知同異

Cloud Native

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

.

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

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

然后，就是我們理解但不知道的事情。依舊是 CPU 利用率高這個場景案例，如果通過學(xué)習(xí)歷史數(shù)據(jù)和關(guān)聯(lián)事件預(yù)測到未來的某個時刻會出現(xiàn) CPU 利用率飆升，就可以實現(xiàn)預(yù)警。

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

簡單總結(jié)一下，在監(jiān)控領(lǐng)域我們關(guān)注指標(biāo)，這些指標(biāo)可能集中在基礎(chǔ)架構(gòu)層，比如說機器、網(wǎng)絡(luò)的性能指標(biāo)。然后基于這些指標(biāo)建立相應(yīng)看板以及告警規(guī)則去監(jiān)測已知范圍里的事情。在監(jiān)控發(fā)現(xiàn)了問題之后，APM 通過基于應(yīng)用層面的鏈路以及內(nèi)存和線程等診斷工具，去定位監(jiān)控指標(biāo)異常的根因。

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

03

建設(shè)可觀測體系關(guān)鍵要點

Cloud Native

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

可觀測數(shù)據(jù)采集

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

1）全棧覆蓋

基礎(chǔ)層、容器層、上方組建云服務(wù)應(yīng)用，以及用戶終端相應(yīng)可觀測數(shù)據(jù)以及與之對應(yīng)的指標(biāo)、鏈路、事件都需要被采集。

2）統(tǒng)一標(biāo)準(zhǔn)
整個業(yè)界都在推進標(biāo)準(zhǔn)統(tǒng)一，首先是指標(biāo)（metrics），Prometheus作為云原生時代的指標(biāo)數(shù)據(jù)標(biāo)準(zhǔn)已經(jīng)形成了共識；鏈路數(shù)據(jù)的標(biāo)準(zhǔn)也隨著 OpenTracing 和 OpenTelemetry 的推行而逐漸占據(jù)主流；在日志領(lǐng)域雖然其數(shù)據(jù)的結(jié)構(gòu)化程度較低難以形成數(shù)據(jù)的標(biāo)準(zhǔn)，但在采集存儲和分析側(cè)也涌現(xiàn)了 Fluentd，Loki 等開源新秀；另一方面，Grafana 作為各種可觀測數(shù)據(jù)的展示標(biāo)準(zhǔn)也愈加明朗。

3）數(shù)據(jù)質(zhì)量

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

1）橫縱關(guān)聯(lián)

在目前的可觀測體系里，應(yīng)用是非常好的分析切入角度。首先，應(yīng)用與應(yīng)用之間是相互關(guān)聯(lián)，可以通過調(diào)用鏈關(guān)聯(lián)起來。其中包括微服務(wù)之間是如何調(diào)用，應(yīng)用與云服務(wù)以及三方組件如何調(diào)用，都可以通過鏈路進行關(guān)聯(lián)。同時，應(yīng)用與容器層、資源層也可進行垂直映射。以應(yīng)用為中心，通過橫向縱向形成全局可觀測數(shù)據(jù)關(guān)聯(lián)。當(dāng)出現(xiàn)問題需要進行定位時，能夠從應(yīng)用角度進行統(tǒng)一分析。
2）領(lǐng)域知識

面對海量數(shù)據(jù)，如何更快速的發(fā)現(xiàn)問題，更準(zhǔn)確定位問題。除了通過以應(yīng)用為中心的數(shù)據(jù)關(guān)聯(lián)，還需要去定位分析問題的領(lǐng)域知識。對于可觀測工具或產(chǎn)品而言，最重要的就是不斷累積最佳排查路徑、常見問題定位、根因的決策鏈路方法，并把相關(guān)經(jīng)驗固化下來。這相當(dāng)于為運維團隊配備經(jīng)驗豐富的運維工程師，去快速發(fā)現(xiàn)問題，定位根因。這個也是不同于傳統(tǒng)的 AIOps 能力。
3
可觀測價值輸出

1）統(tǒng)一展現(xiàn)

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

2）協(xié)作處理

在統(tǒng)一展現(xiàn)以及統(tǒng)一告警之后，如何借助像釘釘、企業(yè)微信等協(xié)作平臺能夠更加高效地進行問題發(fā)現(xiàn)并處理跟蹤的 ChartOps，也逐漸成為剛需。
3）云服務(wù)聯(lián)動

可觀測能力成為云原生的基礎(chǔ)設(shè)施，當(dāng)可觀測平臺在發(fā)現(xiàn)并定位問題之后，需要與各種云服務(wù)快速聯(lián)動，迅速進行擴縮容或負(fù)載均衡，從而更快的解決問題。
04

Prometheus + Grafana 實踐

Cloud Native

得益于云原生開源生態(tài)的蓬勃發(fā)展，我們可以輕而易舉地建設(shè)一套監(jiān)控體系，比如使用 Prometheus + Grafana 搭建基礎(chǔ)監(jiān)控，使用 SkyWalking 或 Jaeger 搭建追蹤系統(tǒng)，使用 ELK 或 Loki 搭建日志系統(tǒng)。但對運維團隊而言，不同類型可觀測數(shù)據(jù)分散存儲在不同后端，排查問題仍需在多系統(tǒng)之間跳轉(zhuǎn)，效率得不到保證?；谝陨希⒗镌埔矠槠髽I(yè)提供了一站式可觀測平臺 ARMS（應(yīng)用的實時監(jiān)控服務(wù)）。ARMS 作為產(chǎn)品家族，包含了不同可觀測場景下的多款產(chǎn)品，比如：

• 針對于基礎(chǔ)架構(gòu)層，Prometheus 監(jiān)控服務(wù)對包括 ECS、VPC、容器在內(nèi)的各類云服務(wù)以及三方中間件進行監(jiān)控。

• 針對應(yīng)用層，基于阿里云自研 Java 探針的應(yīng)用監(jiān)控全面滿足應(yīng)用監(jiān)控需求。相較于開源工具，在數(shù)據(jù)質(zhì)量等方面非常大的提升。并通過鏈路追蹤，即使使用開源 SDK 或探針，也可以將數(shù)據(jù)上報到應(yīng)用監(jiān)控平臺。

• 針對用戶體驗層，通過移動監(jiān)控、前端監(jiān)控、云撥測等模塊，全面覆蓋用戶在不同終端上的體驗與性能。

• 統(tǒng)一告警，對于各層采集的數(shù)據(jù)、告警信息進行統(tǒng)一告警以及根因分析，直接通過Insight呈現(xiàn)發(fā)現(xiàn)結(jié)果。

• 統(tǒng)一界面，不管是ARMS、Prometheus的上報數(shù)據(jù)，還是日志服務(wù)、ElasticSearch、MongoDB 等各種數(shù)據(jù)源，都可以通過全托管 Grafana 服務(wù)進行統(tǒng)一的數(shù)據(jù)可觀測數(shù)據(jù)呈現(xiàn)，建立統(tǒng)一的監(jiān)控大盤，并與阿里云各種云服務(wù)進行聯(lián)動，提供 CloudOps 能力。

上述提到 ARMS 作為一站式產(chǎn)品，具備非常多的能力。目前企業(yè)已自建部分與ARMS類似能力，或采用 ARMS 中的部分產(chǎn)品，比如應(yīng)用監(jiān)控、前端監(jiān)控。但完整的可觀測系統(tǒng)對于企業(yè)而言，依舊至關(guān)重要，并希望基于開源去構(gòu)建符合自身業(yè)務(wù)需求的可觀測系統(tǒng)。在接下來的示例中，我們著重講解 Prometheus + Grafana 如何去構(gòu)建可觀測系統(tǒng)。
1
數(shù)據(jù)快速接入

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

2
預(yù)置數(shù)據(jù)大盤

在數(shù)據(jù)完成接入后，Grafana 自動幫大家創(chuàng)建好相應(yīng)數(shù)據(jù)大盤。以應(yīng)用監(jiān)控以及容器監(jiān)控大盤舉例，像黃金三指標(biāo)、接口變化等基礎(chǔ)數(shù)據(jù)都將默認(rèn)提供。

可以看到，Grafana 雖然幫助大家把各種數(shù)據(jù)看板搭建起來，但看到的依舊是零散大盤。在日常運維過程中，還需要基于業(yè)務(wù)域或基于應(yīng)用創(chuàng)建統(tǒng)一大盤，能夠?qū)⒒A(chǔ)架構(gòu)層、容器層、應(yīng)用層、用戶終端層的數(shù)據(jù)都放到同一個大盤中進行展現(xiàn)，從而實現(xiàn)整體監(jiān)控。

3
全棧統(tǒng)一大盤

在建立全棧統(tǒng)一大盤時，我們按照用戶體驗、應(yīng)用性能、容器層、云服務(wù)、底層資源等維度進行準(zhǔn)備。

1）用戶體驗監(jiān)控
常見的 PV、UV 數(shù)據(jù)、JS 錯誤率、首次渲染時間、API 請求成功率、TopN 頁面性能等關(guān)鍵數(shù)據(jù)都會在第一時間呈現(xiàn)。

3）容器層監(jiān)控
各個 Pod 的性能、使用情況，同時也列出這些應(yīng)用上跑的由哪些 department 創(chuàng)建的。這些 deployment 相關(guān)的 Pod 性能信息都呈現(xiàn)在這一塊。

4）云服務(wù)監(jiān)控
此外，就是相關(guān)的云服務(wù)監(jiān)控，這里以消息隊列 Kafka 舉例，像消息服務(wù)常見的相關(guān)數(shù)據(jù)指標(biāo)如消費量堆積、消費量等數(shù)據(jù)。

5）主機節(jié)點監(jiān)控
針對整個主機節(jié)點，CPU、所運行的 Pod 等數(shù)據(jù)。

這樣子，這張大盤就覆蓋了從用戶體驗層到應(yīng)用層到基礎(chǔ)架構(gòu)容器層的整體性能監(jiān)測情況。更加重要的是整個大盤包含著所有微服務(wù)的相關(guān)數(shù)據(jù)。當(dāng)切某個服務(wù)，服務(wù)相關(guān)聯(lián)的性能數(shù)據(jù)都將獨立展現(xiàn)出來。在容器、應(yīng)用、云服務(wù)等不同層面都進行過濾。這里稍微提一下是怎么做到的，當(dāng) Prometheus 監(jiān)控去采集這些云服務(wù)時，會順帶把云服務(wù)上的 tag 都采集下來。通過對 tag 進行打標(biāo)，就可以把這些云服務(wù)基于不同業(yè)務(wù)維度或不同應(yīng)用進行區(qū)分。在做我們統(tǒng)一大盤的時候，一定會遇到非常多的數(shù)據(jù)源管理問題。這里我們提供了 globalview 能力，把這個用戶名下所有的 Prometheus 實例都匯聚到一起，統(tǒng)一進行查詢。不管是應(yīng)用層的信息，還是云服務(wù)的信息。

借助上面的場景，我們拋磚引玉提出可觀測性平臺設(shè)計方向：基于系統(tǒng)和服務(wù)觀測的角度把不同數(shù)據(jù)在后端融合分析，而不是刻意強調(diào)系統(tǒng)支持可觀測性三種數(shù)據(jù)的分別查詢，在產(chǎn)品功能和交互邏輯上盡可能對用戶屏蔽 Metrics、Tracing、Logging 的割裂。建立完整可觀測閉環(huán)，從事故前異常發(fā)現(xiàn)、事故中故障排查到事故后的主動預(yù)警監(jiān)控，為業(yè)務(wù)持續(xù)監(jiān)控、優(yōu)化服務(wù)性能提供一體化平臺。