一、云原生時代的挑戰

一般來說，企業應用服務建設初期都是快速啟動、快速試錯，隨著業務規模擴大再從單體架構遷移傳統的SOA架構。隨著現在K8s的出現，微服務、容器化、服務網格等云原生的架構概念也逐漸在企業應用中流行。

圖片

架構的發展進程不是跳躍式的，而是不斷演進、新舊共存的。為了在云原生時代里避免單云的故障，同時不被單云綁定，我們更多采取多云、多區、多集群架構的方式。但在過渡到云原生時代的過程中，我們發現了以下挑戰：

1、多樣性：主要表現在異構語言、多云、多區、傳統與云原生共存；

2、動態化：容器化、服務快速部署和銷毀、彈性擴縮容；

3、大規模：數千個服務、萬級容器、億級指標；

在這三大挑戰下，我們如何建設好可觀測體系呢？

二、可觀測體系的建設思路

圖片

從我們SRE穩定性治理的全景來看，我們要降低故障頻次，同時在故障發生的時候，要盡量縮短故障時長MTTR，整體來說要做好故障預防、故障感知、故障定位、故障恢復和故障改造。

而建設可觀測性的重點，就是為穩定性治理提供故障感知和故障定位能力，核心或基礎就是做好采集、處理、存儲、關聯分析等。

可觀測性主要包含三大塊：Traces/Logs/Metrics，在這三塊能力建設的基礎上，我們的還多加了Events（事件）。我們從各種復雜、多變的資源中采集調用鏈、日志、指標、事件，然后對數據進行處理、存儲、關聯、智能分析。

單一的指標或事件分析的價值是不大的，只有以應用為中心去關聯數據，才能發揮數據的價值，從而打造我們的故障感知、故障定位能力。

三、建設過程中的問題與解決方案

1、建設以應用為中心的CMDB

云原生時代下，如何去管理多樣性、動態化的資源呢？

圖片

建設以應用為中心的CMDB經歷了以下幾個階段：

• CMDB 1.0：實現IT資源的數字化資產管理和數據查詢；
• CMDB 2.0：促進技術平臺化管理互通標準化、數據建模、配置自動發現；
• CMDB 3.0：以應用為中心、運維場景驅動，梳理和分析運維對象及關系，從面向資源轉為面向業務；
• CMDB 4.0：運維世界必不可少的數字地圖。

目前趣丸科技處于3.0的階段，前面提到我們建設可觀測性是以應用為中心去做關聯分析，這些關聯關系就是以CMDB 3.0為基礎的，運維場景需要將什么資源納入管理，我們就去管理什么資源；運維場景需要將什么資源關聯起來，我們就去實現自動關聯。

CMDB的下一個階段——CMDB 4.0，是運維世界必不可少的數字地圖，可以幫助運維人員快速找到他們需要的信息，理解IT環境的復雜性，能有效地進行事故管理、問題管理、變更管理等運維工作，是運維人員進行IT環境管理不可缺失的工具。同時CMDB4.0也是智能運維的基石，除了傳統的資產外，我們也會將指標、算法都放進CMDB進行管理，通過CMDB建立各種關聯關系，最終實現根因分析、影響分析、告警收斂等智能運維場景。

2、建設去中心化的采集和存儲能力

在做好CMDB的同時，我們同步還在建設去中心化的采集和存儲能力。在多云、多Region的背景下，如何管理大規模、海量的指標呢？

Prometheus當前基本成為了云原生監控的標準，包括我們運行基座K8S等多數的應用，都按照Prometheus的標準提供metries接口，來暴露自身的指標讓Prometheus去采集的。

但是，因為我們是多云、多Region，K8S集群也非常多，Prometheus單機部署又存在單點故障的風險，因此不能進行中心化。

圖片

因此，我們采用了Thanos+Prometheus的模式，實現指標采集存儲去中心化，讓各個云、各個集群通過它們自己的Prometheus去采集、存儲指標，實現自治；查詢指標時，Thanos通過Prometheus的sidecar去同時查詢數據，然后聚合去重，達到統一查詢入口、去中心采集和存儲的效果、這也是我們整個可觀測性體系的基礎。

圖片

在去中心化的采集模式下，資源分散在多云、多區，我們的Prometheus也一樣分散在各云各區，當前我們大概有150套Prometheus。

那么，我們的Prometheus如何發現資源？由哪個Prometheus去采集呢？基于這個問題，我們建立了一個資源發現和采集調試的組件——Solo（搜羅）。Solo通過與CMDB交互發現資源，然后根據資源屬性、所在區調度相應的Prometheus去采集，實現自動發現可監控資源，并自動補充指標的關鍵label，如區域、CMDB ID等。

3、如何解決高基指標問題？

在微服務、云原生架構下，我們還會面臨高基指標問題。

什么是高基？高基就是高基數，即同一個指標、標簽的總體數值的計數，即每個標簽的值范圍相成的總數。

圖片

如上圖是Istio的一個指標，這個指標是用來統計請求耗時的，就是平常類似于P99、P90的指標。經過指標統計，我們發現這里面有56個標簽，單單抽取幾個重要的指標，它的指標基數是50*50*3*5*50*20（結果是3750萬個基數）。一般情況下，一個指標有1萬個基數就認為是高基了，但是現在我們可能達到了千萬級別。

需要注意的是，高基指標會導致監控變慢，還可能會無法加載甚至崩潰，計算資源開銷也會變得非常大，經常出現OOM問題。

那么，如何解決高基問題呢？

圖片

總的來說，就是降基數、降維度。

這里我們引用了VictoriaMetrics的流計算能力。當然，用Flink也可能做到，但需要人工寫很多邏輯處理，而victoriaMetrics的vmagnet組件自帶這個功能，只需要配置即可。同時，我們使用的是VM社區版，不支持集群方式，因此我們自研了VM網關，去調整后面的各個vmagent。

整個流程就是指標先到Promethues，然后遠程寫到路由網關，由網關調度分析任務，再經過VM進行流計算集群處理，生成新指標再寫回Prometheus中。

效果：之前在P99等請求耗時的指標里，我們有時15分鐘內的數據都無法查詢，現在基本上能在500ms查詢出來，1小時內的數據1s內就可以查詢出來，極大利用了流計算的能力。

圖片

在采用VM流計算能力之前，我們的方案是引用了列式數據庫ClickHouse，利用不一樣的存儲方式，同時通過CK的物化視圖進行預聚合，構建流計算能力，整個查詢性能效果也更加明顯、整體處理流程也更加簡潔，這也是我們可觀測性平臺在用的另一種方案。

4、建設告警能力

在解決指標的采集、存儲，及高基指標問題后，我們還需要打造最基礎的告警能力、主動感知能力，基于告警我們做了以下幾個實踐：

1）告警網關（告警系統的開放能力）：提升API給業務調用，實現它們的自定義告警，同時用來作為云商告警的回調。接收到云商告警之后，再將這些告警轉化為內部的告警，方便我們進行統一管理、分析。

2）告警處理器：告警信息通過告警網關后，我們的告警處理器會通過CMDB找到資源負責人，誰負責的資源和應用，誰就會收到告警，不需要主動去訂閱。同時，我們還做了告警抑制，實現有效標記、認領等功能。

3）告警通知：我們目前將告警推送到飛書上，但因為飛書機器人有頻率控制，因此，我們增加了一個智能調度功能，每個告警群會增加多個飛書機器人，通過調度器決定哪個飛書機器人去發送告警，解決了頻控問題。

4）告警升級：主要補充飛書告警信息被忽略或長時間未解決告警問題，進行電話升級，如果15分還沒有人介入處理，告警會自動通過電話通知服務開發人員和業務運維，如超過一定時間沒處理好的問題，則會自動電話通知再上一級的負責人。

5）告警收斂：主要目的是減少大量的冗余告警，讓運維人員更快地定位和解決問題，當前我們這塊做得也還不是很深入，業界常用的一些收斂做法包括：

• 告警聚合：把一些關聯的告警聚合在一起處理。比如同時出現的網絡故障和服務器崩潰，可以合并為一條告警進行處理；
• 時間窗口：在一定的時間窗口內，將連續發生的同一類型的告警合并為一條，避免造成告警風暴；
• 根源問題分析：快速定位故障原因并解決，避免重復的警告；
• 學習模式以及人工智能：使用機器學習和人工智能來學習監控數據的模式，從而可以減少不必要的告警，例如通過智能預測系統故障。

5、建設以應用為中心的觀測平臺

構建好故障感知能力之后，如何構建故障定位能力，實現快速定位問題呢？

我們認為，核心還是要提升關聯分析能力。因此，我們做了一個以應用為中心的可觀測性平臺，以應用為視角去關聯數據庫、緩存、消息隊列等中間件，同時還支持多觀測視角，服務端視角、客戶端視角、服務實例視角、服務接口視角、服務拓撲等，當某個服務有告警時，可以從不同視角快速發現是某個實例的問題，還是單個接口的問題，還是依賴下游服務的問題。

圖片

6、建設SLA、SLO體系

如何量化整體服務水平？如何管理和持續改進服務質量？如何提升業務方的滿意度？帶著這幾個問題，我們建設了SLA、SLO體系。

圖片

首先，我們從業務模塊和服務的監控指標中抽取核心、關鍵的指標形成SLI，并為這些關鍵指標設定合理組合閾值，組成一個SLO，以分鐘為粒度，根據SLI是否達標來反映當時整體SLO是否可用，并為其設置了三個9之類的整體可用性目標，還會根據設置的目標進行承諾，并與業務方簽訂協議，生成我們的SLA。

我們建設SLA體系的整體方向是，通過量化目標，制定承諾去推進質量持續改進，整體提升用戶滿意度。

現在SLA體系上線才一個季度，整體的落地效果十分顯著。我們劃分了27個業務場景，選取422多個SLI，暫時設定了46個SLO，大部分SLO有30%-100%的改善，我們還會通過SLA周會，對齊每周的服務質量情況，持續推進優化改善。

下面是我們落地的產品圖：

圖片

上面展示我們如何定制一個SLO，可以由多個SLI或多個下級SLO組合成一個新的O。

圖片

上面是SLO的燃盡圖，明確地展示我們當前這個O離目標還可以有多少時間可以消耗。

7、產品化治理

在可觀測平臺建設的初期，遇到了監控系統不好用、需求響應慢甚至不響應等問題。造成這些問題的原因我認為有三方面：

1）閉門造車：只埋頭做自己認為好用、有用的功能；

2）需求管理混亂：用戶提了需求后缺少跟蹤管理；

3）重功能、輕運營：只關注完成開發，不重視后續的產品維護。

針對研發階段，我們進行了產品化的治理，其中包括：

1）規劃階段治理：定期做競品分析、更新產品藍圖，及時確定產品路線、管理產品需求、確認研發優先級等；

2）研發階段治理：增加需求、技術方案、任務管理評審環節等；

3）運營階段管理：增加產品培訓，強調使用說明等。

經過階段性的治理工作后，我們整個可觀測性平臺的用戶滿意度得到了較大的提升，因此，實施產品化管理，是工具平臺建設成功的關鍵。

四、未來展望

未來，我們需要去重點關注的問題是：如何覆蓋更多觀測面？如何更高效、更準確地感知故障和定位問題？

1、如何覆蓋更多觀測面？

以前，兩個服務間的調用經過兩個主機網絡就可以了。但是在云原生環境下，應用間的調用越來越復雜，需要經過容器網格、sidecar、Node節點等。

所以如果遇到服務性能問題，如何分析是服務本身的問題還是網絡問題？以及服務偶爾抖動如何定位根因？pod的性能不達標，如何確定是受哪個異常網絡流量的pod影響？

如果單純依靠手動埋點插入統計代碼的方式，對開發人員來說，工作量是非常大的，因此未來我們會引入eBPF技術。

eBPF是什么呢？

Linux內核中的一種虛擬機和框架，允許用戶在內核中編寫安全高效的程序，用于網絡包過濾、系統調用跟蹤和內核事件監控等用途。

它的特性包括：

• 動態加載：無需重啟服務和服務器；
• 可編程性：可以根據我們的各種需求，在這一層進行編程；
• 高性能：主要體現在這里的代碼在內核中高效執行；
• 安全性：eBPF采用沙箱機制，確保在內核中運行的用戶程序不會破壞系統的穩定性和安全性。

這里給大家推薦兩個完整度非常高的開源項目：一個是國內的deepflow（https://deepflow.io/）,另一個是國外的pixie（https://px.dev/）,我們也在基于這兩個項目做一些實踐，大家有興趣的一起研究探討。

用戶體驗層觀測

當前我們大部分觀測工作都圍繞著后端服務進行，而用戶體驗層即客戶端，才能更敏感、更準確地感知服務質量和影響范圍（比如從客戶端到服務端中間的網絡問題、DNS問題），單純從服務端是無法感知的，因此我們正在建設客戶端的監控。

2、如何更高效、更準確地感知故障和定位問題？

圖片

以往我們設置告警閥值、排查問題，都是依靠個人經驗去判定。未來，我們要形成故障感知和故障定位能力，將經驗驅動向AI驅動發展，大量應用AIOps等相關技術提升可觀測性能力。

陳成禧趣丸科技 SRE平臺資深架構師

• 具有十多年研發經驗，在過去幾年?直致力于研究服務穩定性建設和可觀測性方面的問題，積累了豐富經驗。曾在多家公司主導設計和開發監控相關系統

圖片