01

可觀測(cè)的前生今世

Cloud Native

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

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

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

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

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

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

02

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

Cloud Native

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

.

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

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

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

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

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

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

03

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

Cloud Native

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

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

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

1）全棧覆蓋

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

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

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

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

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

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

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

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

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

2）協(xié)作處理

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

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

Prometheus + Grafana 實(shí)踐

Cloud Native

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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