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

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

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

熊豹

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

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

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

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

匡凌軒

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

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

方勇

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

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

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

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

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

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

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

熊豹

“要把可觀測性理念貫穿到架構和程序設計中”

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

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

匡凌軒

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

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

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

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

方勇

“職責分工、認知意識、排障效率的轉變和升級”

個人認為主要變化有以下幾個方面：

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

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

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

Q3可觀測性的核心方法論/關鍵技術有哪些？

熊豹

“數據的采集、存儲、分析是核心關注點”

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

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

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

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

匡凌軒

“采集數據，建立關聯(lián)，設計模型”

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

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

以上可指導我們針對不同的業(yè)務應用系統(tǒng)進行合理抽象，建設更標準的可觀測性能力。

方勇

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

常用方法論：

1、SLI選擇：

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

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

關鍵技術：

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

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

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

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

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

熊豹

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

我們已知的有兩類方式：

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

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

匡凌軒

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

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

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

方勇

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

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

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

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

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

Q5可觀測性工具如何選型？有通用的標準嗎？

熊豹

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

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

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

匡凌軒

“是否基于業(yè)界標準且方便擴展”

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

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

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

方勇

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

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

工具選型：

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

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

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