大家都有對線上系統(tǒng)排障的經(jīng)驗，我一直認(rèn)為查找bug是計算機(jī)行業(yè)中最神秘、最有創(chuàng)造性的一項活動，眾多老手能夠憑借自己豐富的經(jīng)驗以神乎其技的方式迅速找到問題根源，事后無論是本人還是旁觀者似乎都很難系統(tǒng)性的描述查找bug的思路，仿佛是靈感一現(xiàn)，模模糊糊覺得是哪里的問題，于是便動手去查。這給計算機(jī)行業(yè)添加了一些藝術(shù)成分，但也暗示著這種方式很難復(fù)制。

這好比醫(yī)學(xué)，各種現(xiàn)代化的手段比如CT、B超、核磁共振能夠清晰的反映我們身體的內(nèi)部結(jié)構(gòu)，醫(yī)生再以這些信息作為依據(jù)，為病人進(jìn)行診斷，這些可視化工具幫助現(xiàn)代醫(yī)學(xué)以更加科學(xué)的方式進(jìn)步。計算機(jī)世界的基礎(chǔ)是0和1，更應(yīng)該以確定性為基礎(chǔ)，其上運(yùn)行的系統(tǒng)應(yīng)該像現(xiàn)代醫(yī)學(xué)一樣，能夠通過一些工具直觀地反映內(nèi)部運(yùn)行狀態(tài)，如果生病能夠反映病灶，如果不那么健康能夠預(yù)警，如果非常健康也能達(dá)到體檢的效果。

對云原生有了解的讀者對于CNCF這個組織肯定不會陌生，CNCF提供的全景圖中，有一塊區(qū)域列舉了可觀測性領(lǐng)域相關(guān)的眾多項目，可觀測性作為一種觀察系統(tǒng)的理念，不同于基于固定模式的監(jiān)控，它強(qiáng)調(diào)更加深入了解系統(tǒng)，了解系統(tǒng)的指標(biāo)、拓?fù)?、性能瓶頸、請求鏈路等細(xì)粒度信息，通過對數(shù)據(jù)的挖掘發(fā)現(xiàn)問題的答案，并簡化信息的訪問。

隨著微服務(wù)的發(fā)展，一個線上應(yīng)用可能包含數(shù)十個甚至上百個微服務(wù)，數(shù)量眾多的服務(wù)如何治理是大家最先看到的問題，但面對如此規(guī)模的系統(tǒng)，很難有一個人能夠完整全面的了解系統(tǒng)的每一個組件，如何監(jiān)控以及觀測系統(tǒng)也比以往任何時候更加重要。

可觀測性應(yīng)該做什么

研發(fā)人員更愿意花費精力在Day0/Day1環(huán)節(jié)，這是一個系統(tǒng)的早期方案確定以及研發(fā)階段，因為這個環(huán)節(jié)更加充滿創(chuàng)造性，非常適合富有挑戰(zhàn)精神的開拓者；但這一現(xiàn)象的反面是，Day2 環(huán)節(jié)往往被忽視，在這個環(huán)節(jié)需要真正部署應(yīng)用，并監(jiān)控、維護(hù)、優(yōu)化、再迭代這個線上業(yè)務(wù)，直到整個應(yīng)用生命周期的終點，這是一個長期且相對不那么有創(chuàng)造性的階段，本文聚焦在Day2階段的可觀測性這一主題，結(jié)合云原生以及Serverless場景，強(qiáng)調(diào)它的價值。

前文有描述一個老手排查線上問題的例子，可觀測性目的是將整個系統(tǒng)更加透明化，不再依賴個體經(jīng)驗去猜測系統(tǒng)的細(xì)節(jié)邏輯。但可觀測性也不是“銀彈”，能夠代替工程師定位bug，它更像是一種理念，尤其在微服務(wù)以及云原生時代下，這種理念的價值在于能夠應(yīng)對系統(tǒng)日益復(fù)雜，難于觀測，難于控制的挑戰(zhàn)。

可觀測性最初以谷歌發(fā)布的Dapper論文為理論基礎(chǔ)，使用三種遙測數(shù)據(jù)：日志、指標(biāo)和請求軌跡作為組成部分。

• 日志能夠攜帶完整的上下文信息，能提供最為完備的原始信息，方便后續(xù)進(jìn)行信息的二次加工，但是缺點是數(shù)據(jù)的傳輸以及存儲開銷巨大。

  
  

• 指標(biāo)數(shù)據(jù)能夠提供更加抽象的統(tǒng)計信息，開銷相對固定，方便監(jiān)控以及告警。

  
  

• 請求軌跡信息能夠從單個請求的角度描述系統(tǒng)的拓?fù)?，如果對每個請求都進(jìn)行記錄，開銷依然非常大。

日志以及指標(biāo)信息能夠很好的描述系統(tǒng)中的單個服務(wù)，而請求軌跡描述了系統(tǒng)處理請求時的跨服務(wù)的整體信息。

近幾年為了更好滿足系統(tǒng)可觀測性，誕生出了OpenTelemtry、Prometheus、Fluentd、Elastic等非常優(yōu)秀的項目，簡單介紹一下OpenTelemetry：

OpenTelemetry is a collection of tools, APIs, and SDKs. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior.

OpenTelemetry 和一些可觀測性后臺（比如Jaeger或者Prometheus）不同，主要提供的是一組API以及SDK規(guī)范，規(guī)范了Logs、Metrics、Trace數(shù)據(jù)的格式，不提供后端服務(wù)（比如存儲、查詢、可視化等），支持插件化的Exporter，以規(guī)范化收集和發(fā)送遙測數(shù)據(jù)為目的。

OpenTelemtry對于可觀測性的價值就像Kubernetes對于容器編排的價值一樣，OpenTelemetry擁有強(qiáng)大的社區(qū)支持，基于這個標(biāo)準(zhǔn)，各個系統(tǒng)模塊能提供強(qiáng)大的互操作性，用戶能夠自然而然的享受到最新的可觀測性工具，降低學(xué)習(xí)以及遷移成本。

Kubernetes環(huán)境下的可觀測性

OpenTelemetry 能夠很好的解決云計算虛擬化時代的可觀測性問題，但是Kubernetes環(huán)境下的可觀測性不同于虛擬機(jī)環(huán)境。

Kubernetes 的組件不是中心化部署

Kubernetes組件是分布式部署的，它們之間通過聲明式語義協(xié)作，以周期性調(diào)諧方式推進(jìn)流程。在Kubernetes環(huán)境下的可觀測性并不只是簡單采集應(yīng)用維度的數(shù)據(jù)，還需要收集各個組件的數(shù)據(jù)，這種高度抽象的以應(yīng)用為中心的API對于開發(fā)者而言非常便捷，但卻給可觀測性帶來了巨大的挑戰(zhàn)。

Kubernetes 環(huán)境下應(yīng)用負(fù)載的高度動態(tài)特性

在Kubernetes環(huán)境下，有一個經(jīng)典的比喻，將應(yīng)用劃分為“寵物”以及“牲口”，Kubernetes 能夠很好的支持無狀態(tài)應(yīng)用，計算存儲分離之后，無狀態(tài)應(yīng)用也是 Kubernetes 生態(tài)下最為主流的應(yīng)用負(fù)載。無狀態(tài)應(yīng)用的工作負(fù)載就類比于“牲口”，容器實例會因為工作節(jié)點上的資源緊缺、調(diào)度優(yōu)先級、節(jié)點宕機(jī)等原因被隨時遷移，“牲口”一詞想表達(dá)的含義是保持?jǐn)?shù)量不變，但是個體是可以替換的。傳統(tǒng)基礎(chǔ)架構(gòu)并不會這么“動態(tài)”，虛擬機(jī)不會頻繁的重啟，各種可觀測性數(shù)據(jù)都能夠長期在一個穩(wěn)定的節(jié)點上采集。這也使得Kubernetes環(huán)境下可觀測性更加困難。

雖然相比虛擬機(jī)環(huán)境，在Kubernetes環(huán)境下做可觀測性更加困難，但依然有許多方案可供選擇。

• Logs

一些開源項目比如LogsStash、Fluentd 都可以收集日志，它們以DaemonSet的方式部署在每個節(jié)點之上，能兼容多種輸出格式，對于輸出到標(biāo)準(zhǔn)輸出的日志，這些方案能夠確保日志被妥善保存到后端日志采集系統(tǒng)中。如果更進(jìn)一步，采用類似ElasticStack的整體方案，能夠提供日志收集、檢索、展示一系列功能。

• Metrics

Kubernetes 暴露了三種API用于支持Metrics，基礎(chǔ)監(jiān)控 metrics.k8s.io，用戶自定義 mtrics custom.metrics.k8s.io，外部組件 metrics external.metrics.k8s.io，Metrics Server實現(xiàn)了基礎(chǔ)監(jiān)控API，Prometheus Adapter實現(xiàn)了后面兩種API，這些指標(biāo)數(shù)據(jù)后續(xù)都可以作為HPA的彈縮指標(biāo)。

• Trace

基于Mesh方案能夠在Kubernetes環(huán)境下，做到無侵入的trace收集，但有一定的性能損耗；對于動態(tài)語言，比如java，可以通過類似java agent的方式以兼容OpenTelemetry標(biāo)準(zhǔn)的方式上報trace數(shù)據(jù)，同樣也是無侵入的；對于其他語言，也有非常豐富的SDK支持以O(shè)penTelemetry標(biāo)準(zhǔn)上報Trace數(shù)據(jù)。

Serverless環(huán)境下的可觀測性

云原生給企業(yè)帶來的價值是降本增效，期望為企業(yè)提供按需使用、隨時擴(kuò)展、按量計費的一種資源交付方式，這種特性經(jīng)常被比作云原生時代的水和電。

https://blogs.vmware.com/vov/2018/08/07/how-technology-powers-our-cloud-native-development-environment/

上圖列舉了云原生時代各種服務(wù)形態(tài)，從傳統(tǒng)時代需要自建機(jī)房管理風(fēng)火水電，然后到IaaS的不需要管理風(fēng)火水電，到最后FaaS時代只需要關(guān)心業(yè)務(wù)以及數(shù)據(jù)，很明顯能看到一個趨勢，讓業(yè)務(wù)能夠更加專注于業(yè)務(wù)。

Serverless技術(shù)因為屏蔽了服務(wù)器的各種運(yùn)維復(fù)雜度，比如資源申請，環(huán)境搭建，擴(kuò)縮容等等細(xì)節(jié)都由平臺來進(jìn)行維護(hù)，能夠讓業(yè)務(wù)更加專注于業(yè)務(wù)。所以Serverless技術(shù)成為企業(yè)上云的一種新的方式。

Gartner最近發(fā)布了他們對于2022技術(shù)趨勢的一個預(yù)測報告，其中有一個條目叫做Cloud-Native Platform，它所表達(dá)的這一類平臺會向他的用戶提供一種“可擴(kuò)展的彈性的”服務(wù)，也就是用戶能夠直接使用，而不需要關(guān)心細(xì)節(jié)。這就非常符合Serverless的核心觀念，也就很好地證明了Serverless是未來的一種趨勢。

Cloud-Native Platforms (CNPs)

To truly deliver digital capabilities anywhere and everywhere, enterprises must turn away from the familiar “l(fā)ift and shift” migrations and toward CNPs. CNPs use the core capabilities of cloud computing to provide scalable and elastic IT-related capabilities “as a service” to technology creators using internet technologies, delivering faster time to value and reduced costs.

---《Gartner Identifies the Top Strategic Technology Trends for 2022》

Serverless平臺除開k8s固有的組件分布式、調(diào)度黑盒、標(biāo)準(zhǔn)不統(tǒng)一這些因素之外，還有額外一些阻礙可觀測性的困難。其中最重要的一點就是可觀測性和Serverless的哲學(xué)相違背，Serverless提供的是基礎(chǔ)設(shè)施免運(yùn)維的語義，那么為什么還需要提供一套可觀測性的工具讓用戶去關(guān)注底層？用戶獲取這些信息之后并不能干預(yù)底層資源的調(diào)度和運(yùn)作，這些信息有什么意義嗎？

Serverless環(huán)境下可觀測性的價值

面對這些困惑，各大廠商Serverless產(chǎn)品依然提供了可觀測性的支持，這里的原因與可觀測性的目的相關(guān)，正如前文介紹，可觀測性更像是一種白盒方式觀察系統(tǒng)的手段，不同于監(jiān)控，監(jiān)控是以發(fā)現(xiàn)故障并及時響應(yīng)為目的。對于一個完全正常運(yùn)行的應(yīng)用，可觀測性也有它的價值，比如發(fā)現(xiàn)系統(tǒng)的拓?fù)?、獲得某個請求的上下文、發(fā)現(xiàn)系統(tǒng)中可能存在的瓶頸、以及發(fā)現(xiàn)可以進(jìn)一步優(yōu)化的模塊等，這些都是可觀測性在Serverless平臺的價值。

再比如，基于 OpenTelemetry 采集的指標(biāo)數(shù)據(jù)后續(xù)可以用于實時、基于預(yù)測的彈縮，或者AIOps等場景，這在Serverless場景下對于縮短冷啟動延遲有很大價值。

除開技術(shù)層面的收益，可觀測性還有一些“軟性”價值。以騰訊云TEM為例，提供面向應(yīng)用的 Serverless 服務(wù)形態(tài)，這對于很多客戶是一個比較新的事物，客戶從自己熟悉的VM環(huán)境遷移到 Serverless 平臺，碰到問題往往會懷疑是平臺的問題，需要平臺協(xié)助排查，這在客戶數(shù)量比較少的時候，平臺可以做到貼身服務(wù)客戶，但一旦用戶量上來，這不是一種可持續(xù)的方式。如何將令人信服信息展示給用戶，甚至協(xié)助客戶發(fā)現(xiàn)以及定位問題，這就是可觀測性對于一個 Serverless 平臺提供的“軟性”價值——增強(qiáng)用戶信心、節(jié)省平臺人力成本。

具體如何做 Serverless 平臺的可觀測性呢？在平臺建設(shè)初期，可以依照 Kubernetes 可觀測性的做法提供包含Logs、Metrics、Trace信息的數(shù)據(jù)，并隨著平臺的不斷成熟，再逐漸豐富 Serverless 平臺特有的一些可觀測性數(shù)據(jù)，以騰訊云的TEM為例，可以從以下幾個方面去豐富可觀測性的支持。

鏡像構(gòu)建過程的可觀測性

面向應(yīng)用的Serverless平臺以jar/war程序包或者鏡像作為輸入，其中程序包需要經(jīng)過鏡像構(gòu)建環(huán)節(jié)才能運(yùn)行在資源底座上，整個構(gòu)建過程各個環(huán)節(jié)是否成功、耗時多少都是需要展現(xiàn)的信息，這些信息能夠幫助用戶進(jìn)一步優(yōu)化鏡像。

以下這段信息就是一個jar包在TEM上構(gòu)建成鏡像的日志信息，其中不僅包含結(jié)果信息，還把每一個環(huán)節(jié)的耗時展現(xiàn)出來，方便用戶整體觀察構(gòu)建性能。

應(yīng)用發(fā)布可觀測性

TEM提供白屏化面向應(yīng)用運(yùn)維 Serverless 平臺，幫助用戶聚焦業(yè)務(wù)開發(fā)，屏蔽底層基礎(chǔ)設(shè)施運(yùn)維細(xì)節(jié)，在提供 Serverless 價值的同時，我們也希望通過發(fā)布可觀測性讓用戶更加了解其中的發(fā)布細(xì)節(jié)。

這些信息包含原生kubernetes運(yùn)行日志以及TEM控制面調(diào)度信息，Kubernetes運(yùn)行日志能夠幫助用戶排查各種難以預(yù)見的細(xì)節(jié)問題，比如：鏡像不存在、配額不足、參數(shù)不合法等。提供發(fā)布環(huán)節(jié)的一些細(xì)粒度信息，方便用戶自我排查簡單問題，也能夠增強(qiáng)用戶對發(fā)布過程的認(rèn)知。

• 灰度發(fā)布：小批量驗證新版本是否符合預(yù)期；
• 分批發(fā)布：提供分批次先擴(kuò)后縮語義的滾動發(fā)布，批次間可以采用自動或者手動方式觸發(fā)；
• 原地升級：同樣提供分批次先擴(kuò)后縮語義的滾動發(fā)布，但是保證舊實例ID以及IP不變，并且升級效率更高。

聯(lián)動云上產(chǎn)品提供應(yīng)用維度可觀測性

TEM能夠聯(lián)接云上各個產(chǎn)品，提供應(yīng)用維度的可觀測性能力，真正做到博取各家所長。

Logs：基于騰訊云CLS提供應(yīng)用維度的一站式的日志數(shù)據(jù)解決方案，用戶只需要關(guān)聯(lián)已有的CLS實例，無需關(guān)注擴(kuò)縮容等資源問題，即可享受從日志采集、日志存儲到日志內(nèi)容搜索、統(tǒng)計分析等穩(wěn)定可靠的日志服務(wù)。輕松解決業(yè)務(wù)問題定位，指標(biāo)監(jiān)控、安全審計等日志問題。

Metrics：TEM結(jié)合云監(jiān)控以及APM，基于實時的多語言應(yīng)用探針全量采集技術(shù)，提供豐富的指標(biāo)數(shù)據(jù)，包括基礎(chǔ)監(jiān)控、應(yīng)用監(jiān)控、接口監(jiān)控以及JVM監(jiān)控。幫助用戶監(jiān)控系統(tǒng)健康度，或者對接運(yùn)維告警。

Trace：TEM結(jié)合應(yīng)用性能觀測管理平臺，通過java-agent方式，無侵入的協(xié)助業(yè)務(wù)接入Trace上報能力，使得整個請求的生命周期完整呈現(xiàn)。幫助用戶從請求維度了解整個系統(tǒng)拓?fù)湟约皡f(xié)助排查線上問題。

總結(jié)

微服務(wù)、容器化、云原生這些技術(shù)帶給現(xiàn)代系統(tǒng)更加優(yōu)秀的理念，但伴隨而來的復(fù)雜度也比以往任何時候更加困難，如何治理數(shù)量眾多的微服務(wù)、如何進(jìn)一步提高資源利用率等一些問題已經(jīng)被人們充分討論并引起足夠的重視，但本文聚焦在云原生環(huán)境下 Day 2 的可觀測性這一部分，不僅僅因為這一部分較少被關(guān)注，也因為如果想做好一個產(chǎn)品，Day 2 的工作會是占比更大也是更加重要的一部分。

參考文獻(xiàn)：

https://www.infoq.cn/news/2017/11/observability-monitoring/

https://copyconstruct.medium.com/monitoring-in-the-time-of-cloud-native-c87c7a5bfa3e

https://www.infoq.com/news/2017/11/observability-monitoring/

https://www.observeinc.com/resources/observability-in-kubernetes/

https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/

https://lumigo.io/blog/understanding-serverless-observability/

掃描下方二維碼關(guān)注本公眾號，

了解更多微服務(wù)、消息隊列的相關(guān)信息！

解鎖超多鵝廠周邊！