隨著大量云原生技術(shù)的應(yīng)用，IT系統(tǒng)日益復(fù)雜，主動感知、預(yù)測故障并迅速定位、排障的難度變得越來越大，傳統(tǒng)監(jiān)控方式已無法跟上需求，由此應(yīng)運而生的可觀測性，被視為未來云環(huán)境生產(chǎn)部署不可或缺的技術(shù)支撐。

目前大多數(shù)傳統(tǒng)企業(yè)對可觀測性仍處于初步了解階段，不少互聯(lián)網(wǎng)公司在可觀測性建設(shè)上也是起步不久。因此，圍繞“從監(jiān)控到可觀測性應(yīng)如何轉(zhuǎn)變與升級”這一話題，本期dbaplus話題接力專欄，特別采訪到知乎全鏈路可觀測系統(tǒng)和接入層網(wǎng)絡(luò)負(fù)責(zé)人-熊豹、虎牙直播SRE平臺研發(fā)團(tuán)隊負(fù)責(zé)人-匡凌軒、好大夫基礎(chǔ)架構(gòu)部高級工程師-方勇三位老師，希望能通過他們在可觀測性領(lǐng)域的研究心得和實踐經(jīng)驗，幫助廣大技術(shù)從業(yè)者準(zhǔn)確認(rèn)識可觀測性、給企業(yè)搭建適配自身發(fā)展的可觀測體系提供建議和啟發(fā)。

Q1監(jiān)控與可觀測性是什么關(guān)系？有什么區(qū)別？可否從兩者的關(guān)注點、應(yīng)用場景、作用、局限性等方面進(jìn)行解析？

熊豹

“正在發(fā)生什么 與 為什么會這樣”

監(jiān)控是常見的運維手段，一般是指以觀測系統(tǒng)的外部資源使用情況和接口表現(xiàn)來推測系統(tǒng)運行狀態(tài)，即感知到“正在發(fā)生什么”。

可觀測性是一種屬性，是指在可以感知系統(tǒng)當(dāng)前運行狀態(tài)的性質(zhì)，提升系統(tǒng)的可被觀測的性質(zhì)有助于我們了解“正在發(fā)生什么”以及“為什么會這樣”。

云原生架構(gòu)在業(yè)內(nèi)逐步落地，給穩(wěn)定性建設(shè)帶來了更多新的挑戰(zhàn)：迭代發(fā)布更迅速、業(yè)務(wù)系統(tǒng)更龐大、網(wǎng)絡(luò)鏈路更復(fù)雜、運行環(huán)境更動態(tài)。在這樣的混沌系統(tǒng)中僅僅只是知道問題發(fā)生是不夠的，在這樣紛繁復(fù)雜的環(huán)境下赤手空拳的我們很難去進(jìn)行問題的追蹤和溯源。我們要依托分層、多維度的觀測數(shù)據(jù)來構(gòu)建更立體和智能的診斷系統(tǒng)，以更多樣的視角來觀察和解讀系統(tǒng)。

匡凌軒

“可觀測性更多是對業(yè)務(wù)應(yīng)用系統(tǒng)自身的要求”

我認(rèn)為監(jiān)控是可觀測性能力的一部分，初期監(jiān)控主要是外部對業(yè)務(wù)應(yīng)用系統(tǒng)的主動行為，運維是傳統(tǒng)監(jiān)控的使用主體，如：通過業(yè)務(wù)進(jìn)程狀態(tài)、系統(tǒng)資源等監(jiān)控數(shù)據(jù)的分析和告警來發(fā)現(xiàn)問題。而現(xiàn)在可觀測性更多是對業(yè)務(wù)應(yīng)用系統(tǒng)自身的要求，如何設(shè)計去暴露出更多可被觀測的應(yīng)用運行時的數(shù)據(jù)，并為這些數(shù)據(jù)之間建立關(guān)聯(lián)，如：微服務(wù)框架在請求處理和RPC調(diào)用時提供一些AOP擴(kuò)展的設(shè)計，可以更方便地對請求進(jìn)行Metric度量和Trace追蹤，以及異常情況的上下文關(guān)聯(lián)。

方勇

“從局部到全局可用性視角的延伸”

兩者的關(guān)系：監(jiān)控和可觀測性都旨在輔助建設(shè)高可用的服務(wù)，縮短故障處理時長，兩者往往是密切協(xié)作的，界限相對模糊。

兩者的區(qū)別：監(jiān)控往往關(guān)注告警觸發(fā)的瞬時狀態(tài)，一般圍繞告警事件展開，涉及從告警事件的產(chǎn)生到應(yīng)急響應(yīng)等一系列動作。關(guān)注的視角一般是局部可用性，關(guān)注每個具體的監(jiān)控項，如CPU負(fù)載、剩余內(nèi)存等。監(jiān)控是個老生常談的話題，最常見的場景是系統(tǒng)資源監(jiān)控、進(jìn)程或服務(wù)狀態(tài)的粗粒度監(jiān)控。對定制化的業(yè)務(wù)指標(biāo)監(jiān)控不太友好，另外傳統(tǒng)的監(jiān)控體系對云原生的支持、對微服務(wù)體系監(jiān)控的支持也不太友好。

可觀測性可以看作是監(jiān)控的一種延續(xù)，涉及面較廣，包括全鏈路分析（APM）、業(yè)務(wù)服務(wù)質(zhì)量（SLA）、業(yè)務(wù)容量等，聚焦服務(wù)的整體可用性。關(guān)注的視角一般是全局可用性，會忽略不影響服務(wù)質(zhì)量的一些指標(biāo)，如CPU負(fù)載高，服務(wù)整體時延波動不大就會忽略這個CPU負(fù)載指標(biāo)。

可觀測性的應(yīng)用場景一般與業(yè)務(wù)能力相綁定，通過可視化聚合展示影響SLA的相關(guān)指標(biāo)（SLI），再配合監(jiān)控告警，通過可觀測性看板下鉆分析異常根因。另外可觀測性打通Metrics/Traces/Logs后可主動識別出服務(wù)的潛在風(fēng)險，能先于用戶發(fā)現(xiàn)問題。

可觀測性也有所局限，由于需要收集業(yè)務(wù)數(shù)據(jù)，對業(yè)務(wù)具有一定的侵入性，加上打造可視化平臺投入成本較高。另外可觀測性整體處于初期階段，很多工具鏈還不太完善，價值預(yù)期其實是被高估了。

Q2從監(jiān)控到可觀測性都有哪些變化？對運維、開發(fā)、架構(gòu)師等崗位人員分別提出了怎樣的新要求？

熊豹

“要把可觀測性理念貫穿到架構(gòu)和程序設(shè)計中”

目標(biāo)不一樣了，除了要知道“正在發(fā)生什么”，還要嘗試解釋“為什么會這樣”。我們需要把可觀測性的理念貫穿到架構(gòu)和程序設(shè)計中，而不是到事發(fā)或事后再來補(bǔ)救。我們需要有意識地設(shè)計一些機(jī)制來觀察業(yè)務(wù)指標(biāo)的關(guān)聯(lián)變化、系統(tǒng)架構(gòu)的數(shù)據(jù)漏斗模型、程序內(nèi)邏輯分支的運行開銷、外部資源依賴的健康狀態(tài)，還要暴露程序內(nèi)的一些資源并發(fā)度、池的填充率和命中率、運行時的狀態(tài)等情況，當(dāng)運行錯誤時也要在錯誤信息中攜帶足量的上下文信息。

運維同學(xué)要為可觀測場景提供更堅實的工具基礎(chǔ)，在上述龐大的數(shù)據(jù)壓力下，保障和解決數(shù)據(jù)存儲和查詢的性能、資源開銷、集群的拓展性和穩(wěn)定性等問題。

匡凌軒

“從被動監(jiān)控向主動發(fā)現(xiàn)與定位問題的轉(zhuǎn)變”

我認(rèn)為最大的變化是應(yīng)用系統(tǒng)自身角色的轉(zhuǎn)變，從被動監(jiān)控轉(zhuǎn)向主動發(fā)現(xiàn)與定位問題，在設(shè)計應(yīng)用系統(tǒng)架構(gòu)之初就需要考慮到系統(tǒng)自身的可觀測性建設(shè)。運維、開發(fā)、架構(gòu)師都是各環(huán)節(jié)設(shè)計的參與者，在協(xié)作方式也有一定的改變：

• 運維：深入熟悉產(chǎn)品業(yè)務(wù)和應(yīng)用服務(wù)，定義并關(guān)聯(lián)業(yè)務(wù)指標(biāo)、應(yīng)用服務(wù)指標(biāo)、系統(tǒng)資源指標(biāo)等。
• 開發(fā)：在框架層設(shè)計和實現(xiàn)對分布式應(yīng)用服務(wù)運行時的Metric、Trace、Log數(shù)據(jù)采集。
• 架構(gòu)師：業(yè)務(wù)應(yīng)用系統(tǒng)和可觀測性系統(tǒng)的整體架構(gòu)設(shè)計，需要關(guān)注無侵入式采集上報、多維度量聚合、錯誤尋根分析、整體海量數(shù)據(jù)處理和存儲等。

總體來說，需要各角色有更多跨技術(shù)領(lǐng)域的知識儲備、業(yè)務(wù)思維和模型抽象能力。

方勇

“職責(zé)分工、認(rèn)知意識、排障效率的轉(zhuǎn)變和升級”

個人認(rèn)為主要變化有以下幾個方面：

• 職責(zé)分工的轉(zhuǎn)變，研發(fā)關(guān)注服務(wù)質(zhì)量后，部分職責(zé)從運維側(cè)開始遷移到研發(fā)側(cè)。研發(fā)上線后不再當(dāng)甩手掌柜，開始對自己的服務(wù)負(fù)責(zé)。
• 認(rèn)知意識的提高，從被動響應(yīng)告警到主動提升服務(wù)質(zhì)量。
• 排障效率的提升，從原先的黑盒排障模式逐漸朝可視化發(fā)展。

對不同崗位人員也有新的要求：

• 運維，需要擺脫傳統(tǒng)監(jiān)控的意識枷鎖，擁抱云原生監(jiān)控體系，同時和其他崗位人員達(dá)成共識，共建高可用服務(wù)。
• 開發(fā)，接棒部分運維職責(zé)，聚焦服務(wù)可用性，需要有MDD（Metrics-Driven Developmen）的思想，建設(shè)具有高韌性的服務(wù)。
• 架構(gòu)師，在架構(gòu)設(shè)計的過程中需要暴露可觀測性的指標(biāo)，同時需要提升數(shù)據(jù)分析的能力，建模分析Metrics/Traces/Logs數(shù)據(jù)，識別服務(wù)中潛在的風(fēng)險。圍繞可觀測性打造相應(yīng)的工具鏈及服務(wù)治理平臺。

Q3可觀測性的核心方法論/關(guān)鍵技術(shù)有哪些？

熊豹

“數(shù)據(jù)的采集、存儲、分析是核心關(guān)注點”

可觀測性建設(shè)的核心關(guān)注點還是在數(shù)據(jù)的采集、存儲、分析環(huán)節(jié)。

數(shù)據(jù)采集的覆蓋可以以多種角度來看：可嘗試梳理完整的數(shù)據(jù)鏈路，來覆蓋從終端發(fā)起、網(wǎng)關(guān)、業(yè)務(wù)、基礎(chǔ)設(shè)施中間的每一層組件；可以不同的觀測視角進(jìn)行覆蓋，比如Metrics、Traces、Logs、Exception Collection、Profiler、Debuger、Changelog等類別的數(shù)據(jù)或能力都已建設(shè)齊備；可以多種維度來觀察系統(tǒng)，比如業(yè)務(wù)維度、資源瓶頸、關(guān)聯(lián)組件等維度進(jìn)行覆蓋的建設(shè)。

數(shù)據(jù)存儲環(huán)節(jié)要關(guān)注多種類型數(shù)據(jù)的存儲和查詢系統(tǒng)選型。最為常見的是Metrics、Traces、Logs相關(guān)的存儲系統(tǒng)，這三者都有非常廣泛的基礎(chǔ)軟件選型。其中相對棘手的是指標(biāo)維度爆炸、日志和Trace存儲成本及性能相關(guān)的問題，一般需要搭配預(yù)聚合、前采樣和后采樣、存儲分級等策略來解決。

數(shù)據(jù)分析環(huán)節(jié)要關(guān)聯(lián)不同數(shù)據(jù)源的元信息，糅合以多維視角來構(gòu)建查詢界面。同時，我們也要關(guān)注如何在海量的原始數(shù)據(jù)中找到一些突出和異常的數(shù)據(jù)，一般需要建設(shè)一些流式檢測和聚類分析的能力。

匡凌軒

“采集數(shù)據(jù)，建立關(guān)聯(lián)，設(shè)計模型”

可觀測性的核心思考：需要采集什么數(shù)據(jù)、如何建立關(guān)聯(lián)、如何設(shè)計模型，我們以應(yīng)用服務(wù)場景為例：

• 采集：請求量、耗時、錯誤和容量等，以及線程池、隊列、連接池等資源指標(biāo)。
• 關(guān)聯(lián)：縱向關(guān)聯(lián)請求上下游鏈路和調(diào)用棧，橫向關(guān)聯(lián)請求和處理請求所消耗的應(yīng)用資源。
• 模型：數(shù)據(jù)采集和關(guān)聯(lián)、異常定義和分析、全鏈路錯誤尋根三方面統(tǒng)一的模型化設(shè)計。

以上可指導(dǎo)我們針對不同的業(yè)務(wù)應(yīng)用系統(tǒng)進(jìn)行合理抽象，建設(shè)更標(biāo)準(zhǔn)的可觀測性能力。

方勇

“MDD思想主張指標(biāo)驅(qū)動開發(fā)”

常用方法論：

1、SLI選擇：

• 參考Google VALET（Volume、Available、Latency、Error、Ticket）模型。
• Netflix的USE方法，USE是Utilization（使用率）、Saturation（飽和度）、Error（錯誤）。
• Weave Cloud的RED方法，Request-Rate（每秒接收的請求數(shù)）/Request-Errors（每秒失敗的請求數(shù)）/Request-Duration（每個請求所花費的時間，用時間間隔表示）。

2、MDD（Metrics-Driven Development）思想：MDD主張整個應(yīng)用開發(fā)過程由指標(biāo)驅(qū)動，通過實時指標(biāo)來驅(qū)動快速、精確和細(xì)粒度的軟件迭代。指標(biāo)驅(qū)動開發(fā)的理念，不但可以讓程序員實時感知生產(chǎn)狀態(tài)，及時定位并終結(jié)問題，還可以幫助產(chǎn)品經(jīng)理和運維人員一起關(guān)注相關(guān)的業(yè)務(wù)指標(biāo)。

關(guān)鍵技術(shù)：

1、數(shù)據(jù)收集：如果是基于Prometheus生態(tài)，有豐富的Exporte可用，還可以自研相應(yīng)的Exporter。如果基于文件日志收集，可考慮Flume、Fluentd等等。

2、數(shù)據(jù)分析：可基于Clickhouse SQL分析提煉日志指標(biāo)，如果是Prometheus體系，也有豐富的PromQL可用來分析相關(guān)指標(biāo)。針對Traces、Logs分析一般采用自研分析引擎，并與Metrics打通。

3、數(shù)據(jù)存儲：Prometheus本身就是一款很好的時序數(shù)據(jù)庫，但不支持分布式存儲。一般采用遠(yuǎn)程存儲引擎搭配使用，常用Clickhouse、InfluxDB等。Traces和Logs一般可采用Elasticsearch存儲。

4、數(shù)據(jù)展示：數(shù)據(jù)最終呈現(xiàn)形式，需要契合可視化設(shè)計規(guī)劃，支持上卷/下鉆。大部分需求可采用Grafana呈現(xiàn)，Grafana提供了豐富的插件，支持豐富的數(shù)據(jù)庫類型，也可基于Echarts自研。如果托管公有云，可充分利用公有云自有的體系，不過有些需要單獨付費。

Q4如何將Metrics、Traces、Logs三者打通并發(fā)揮最大價值？

熊豹

“基于時間范圍內(nèi)的統(tǒng)計關(guān)系或Label和TraceID關(guān)聯(lián)”

我們已知的有兩類方式：

1、基于時間范圍內(nèi)的統(tǒng)計關(guān)系：一般的使用習(xí)慣是在Metric異常的時間區(qū)間里去找到對應(yīng)時間區(qū)間出現(xiàn)異常行為的Traces和Logs，這種方式會依賴對Traces和Logs的聚類分析能力。

2、基于Label和TraceID關(guān)聯(lián)：基于OpenTelemetry Collector可觀測數(shù)據(jù)采集的框架，我們可以以插件的形式、以Trace Span元數(shù)據(jù)Label來生成訪問指標(biāo)，也同時將TraceID攜帶記錄到日志的元信息中，這樣就能以同樣的TraceID或Label維度進(jìn)行關(guān)聯(lián)查看了。另外當(dāng)前Prometheus實現(xiàn)了一個exemplar特性可以將Metric與TraceID關(guān)聯(lián)存儲，這個設(shè)計也挺有意思的。

匡凌軒

“全鏈路錯誤尋根是三者打通的最大價值”

三者打通最大的價值是能做到全鏈路錯誤尋根，即從發(fā)現(xiàn)請求Metric指標(biāo)異常，通過指標(biāo)關(guān)聯(lián)分析，并逐層下鉆到明細(xì)Trace追蹤和具體Error Log，全流程自動化從宏觀到明細(xì)的錯誤發(fā)現(xiàn)和根因定位。

虎牙為三者統(tǒng)一設(shè)計了應(yīng)用監(jiān)控模型，包括應(yīng)用服務(wù)的透明零成本SDK接入，三者數(shù)據(jù)自動采集和關(guān)聯(lián)，以及在虎牙大型分布式系統(tǒng)充分實踐的全鏈路錯誤尋根算法。就整體實踐經(jīng)驗來說，最終業(yè)務(wù)價值在于幫助研發(fā)和運維提高了應(yīng)用服務(wù)的排障和治理效率。

方勇

“打通后可立體、全息分析整個服務(wù)的可用性”

從投入成本（CapEx）、運維成本（OpEx）、響應(yīng)能力（Reaction）、查問題的有效程度（Investigation）幾個方面分析。Metrics、Logs、Traces具有以下特征：

Logs和Traces一般采用trace_id打通，trace_id一般在端入口生成，貫穿整個請求的生命周期，業(yè)務(wù)記錄Logs的時候可記錄當(dāng)前的trace_id，這樣Logs和Traces就能打通了。

與Metrics打通一般是采用標(biāo)簽Tags模式，如某個服務(wù)servername產(chǎn)生的metrics可與Traces中的servername關(guān)聯(lián)。

打通后可以服務(wù)名的維度，立體、全息分析整個服務(wù)的可用性。

Q5可觀測性工具如何選型？有通用的標(biāo)準(zhǔn)嗎？

熊豹

“高可用、可伸縮、降成本、易運維”

我們關(guān)注可觀測工具系統(tǒng)的這些特性：

• 高可用：可觀測系統(tǒng)作為穩(wěn)定性的守衛(wèi)者，本身要求更高的可靠性。
• 可伸縮：我們關(guān)注存儲寫入和查詢能力的可拓展性，以支持更大的數(shù)據(jù)量級。
• 降成本：觀測類數(shù)據(jù)會隨著時間的推移逐漸失去價值，歷史數(shù)據(jù)最好能低成本地失效或能對存儲介質(zhì)進(jìn)行降級。
• 易運維：擁有一定的自動化能力或者本身架構(gòu)足夠簡單。

匡凌軒

“是否基于業(yè)界標(biāo)準(zhǔn)且方便擴(kuò)展”

虎牙主要是基于OpenTracing標(biāo)準(zhǔn)進(jìn)行的深度自研和擴(kuò)展，通過業(yè)界標(biāo)準(zhǔn)來做會有充分的開源代碼和社區(qū)支持，可以節(jié)省很多基礎(chǔ)代碼的工作，讓我們更關(guān)注自身的業(yè)務(wù)系統(tǒng)特性和模型設(shè)計。現(xiàn)在OpenTelemetry對Metrics、Traces、Logs三者提供了統(tǒng)一標(biāo)準(zhǔn)，開源社區(qū)熱度也比較大，是個值得去研究和實踐的方向。

可觀測性工具選型建議可考慮兩個方面：

1. 是否基于業(yè)界標(biāo)準(zhǔn)，有更多社區(qū)和廠商支持。
2. 是否方便擴(kuò)展，更容易把共性和個性結(jié)合，最終在此基礎(chǔ)上建設(shè)符合自身業(yè)務(wù)特性的可觀測性系統(tǒng)。

方勇

“根據(jù)已有技術(shù)棧按需選擇，不必盲從主流”

可觀測性分析整個技術(shù)?？蓞⒖既缦聢D：

工具選型：

• Metrics：常用Zabbix、Nagios、Prometheus，及相關(guān)高可用部署方案如Prometheus-operator、Thanos。
• Logging：ELK Stack、Fluentd、Loki等。
• Traceing：常用Jaeger、SkyWalking、Pinpoint、Zipkin、Spring Cloud Sleuth等。
• 可視化：Grafana。

其實技術(shù)選型沒什么特定的標(biāo)準(zhǔn)，每個企業(yè)不同階段可能有不同的選擇，適合自己的才是最好的，這里總結(jié)幾點心得：

• 控制成本預(yù)算，企業(yè)一般需要從自身的發(fā)展階段實際情況考慮，不必一上來就整全鏈路可觀測性，也許初期只用傳統(tǒng)的Zabbix就滿足需求了。理性按需選擇，大可不必盲從主流。
• 擁抱開源，初期一般采用開源產(chǎn)品，開箱即用，搭順風(fēng)車。另外，選型時還需要考慮周邊生態(tài)的豐富度。
• 根據(jù)團(tuán)隊技術(shù)棧選擇，中間件、業(yè)務(wù)服務(wù)、云原生、物理機(jī)監(jiān)控等選型都要貼合團(tuán)隊已有的技術(shù)棧。