一、云原生時代的挑戰(zhàn)

一般來說，企業(yè)應(yīng)用服務(wù)建設(shè)初期都是快速啟動、快速試錯，隨著業(yè)務(wù)規(guī)模擴大再從單體架構(gòu)遷移傳統(tǒng)的SOA架構(gòu)。隨著現(xiàn)在K8s的出現(xiàn)，微服務(wù)、容器化、服務(wù)網(wǎng)格等云原生的架構(gòu)概念也逐漸在企業(yè)應(yīng)用中流行。

圖片

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

1、多樣性：主要表現(xiàn)在異構(gòu)語言、多云、多區(qū)、傳統(tǒng)與云原生共存；

2、動態(tài)化：容器化、服務(wù)快速部署和銷毀、彈性擴縮容；

3、大規(guī)模：數(shù)千個服務(wù)、萬級容器、億級指標；

在這三大挑戰(zhàn)下，我們?nèi)绾谓ㄔO(shè)好可觀測體系呢？

二、可觀測體系的建設(shè)思路

圖片

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

而建設(shè)可觀測性的重點，就是為穩(wěn)定性治理提供故障感知和故障定位能力，核心或基礎(chǔ)就是做好采集、處理、存儲、關(guān)聯(lián)分析等。

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

單一的指標或事件分析的價值是不大的，只有以應(yīng)用為中心去關(guān)聯(lián)數(shù)據(jù)，才能發(fā)揮數(shù)據(jù)的價值，從而打造我們的故障感知、故障定位能力。

三、建設(shè)過程中的問題與解決方案

1、建設(shè)以應(yīng)用為中心的CMDB

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

圖片

建設(shè)以應(yīng)用為中心的CMDB經(jīng)歷了以下幾個階段：

• CMDB 1.0：實現(xiàn)IT資源的數(shù)字化資產(chǎn)管理和數(shù)據(jù)查詢；
• CMDB 2.0：促進技術(shù)平臺化管理互通標準化、數(shù)據(jù)建模、配置自動發(fā)現(xiàn)；
• CMDB 3.0：以應(yīng)用為中心、運維場景驅(qū)動，梳理和分析運維對象及關(guān)系，從面向資源轉(zhuǎn)為面向業(yè)務(wù)；
• CMDB 4.0：運維世界必不可少的數(shù)字地圖。

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

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

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

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

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

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

圖片

因此，我們采用了Thanos+Prometheus的模式，實現(xiàn)指標采集存儲去中心化，讓各個云、各個集群通過它們自己的Prometheus去采集、存儲指標，實現(xiàn)自治；查詢指標時，Thanos通過Prometheus的sidecar去同時查詢數(shù)據(jù)，然后聚合去重，達到統(tǒng)一查詢?nèi)肟?、去中心采集和存儲的效果、這也是我們整個可觀測性體系的基礎(chǔ)。

圖片

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

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

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

在微服務(wù)、云原生架構(gòu)下，我們還會面臨高基指標問題。

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

圖片

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

需要注意的是，高基指標會導(dǎo)致監(jiān)控變慢，還可能會無法加載甚至崩潰，計算資源開銷也會變得非常大，經(jīng)常出現(xiàn)OOM問題。

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

圖片

總的來說，就是降基數(shù)、降維度。

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

整個流程就是指標先到Promethues，然后遠程寫到路由網(wǎng)關(guān)，由網(wǎng)關(guān)調(diào)度分析任務(wù)，再經(jīng)過VM進行流計算集群處理，生成新指標再寫回Prometheus中。

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

圖片

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

4、建設(shè)告警能力

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

1）告警網(wǎng)關(guān)（告警系統(tǒng)的開放能力）：提升API給業(yè)務(wù)調(diào)用，實現(xiàn)它們的自定義告警，同時用來作為云商告警的回調(diào)。接收到云商告警之后，再將這些告警轉(zhuǎn)化為內(nèi)部的告警，方便我們進行統(tǒng)一管理、分析。

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

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

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

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

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

5、建設(shè)以應(yīng)用為中心的觀測平臺

構(gòu)建好故障感知能力之后，如何構(gòu)建故障定位能力，實現(xiàn)快速定位問題呢？

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

圖片

6、建設(shè)SLA、SLO體系

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

圖片

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

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

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

下面是我們落地的產(chǎn)品圖：

圖片

上面展示我們?nèi)绾味ㄖ埔粋€SLO，可以由多個SLI或多個下級SLO組合成一個新的O。

圖片

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

7、產(chǎn)品化治理

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

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

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

3）重功能、輕運營：只關(guān)注完成開發(fā)，不重視后續(xù)的產(chǎn)品維護。

針對研發(fā)階段，我們進行了產(chǎn)品化的治理，其中包括：

1）規(guī)劃階段治理：定期做競品分析、更新產(chǎn)品藍圖，及時確定產(chǎn)品路線、管理產(chǎn)品需求、確認研發(fā)優(yōu)先級等；

2）研發(fā)階段治理：增加需求、技術(shù)方案、任務(wù)管理評審環(huán)節(jié)等；

3）運營階段管理：增加產(chǎn)品培訓(xùn)，強調(diào)使用說明等。

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

四、未來展望

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

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

以前，兩個服務(wù)間的調(diào)用經(jīng)過兩個主機網(wǎng)絡(luò)就可以了。但是在云原生環(huán)境下，應(yīng)用間的調(diào)用越來越復(fù)雜，需要經(jīng)過容器網(wǎng)格、sidecar、Node節(jié)點等。

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

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

eBPF是什么呢？

Linux內(nèi)核中的一種虛擬機和框架，允許用戶在內(nèi)核中編寫安全高效的程序，用于網(wǎng)絡(luò)包過濾、系統(tǒng)調(diào)用跟蹤和內(nèi)核事件監(jiān)控等用途。

它的特性包括：

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

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

用戶體驗層觀測

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

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

圖片

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

陳成禧趣丸科技 SRE平臺資深架構(gòu)師

• 具有十多年研發(fā)經(jīng)驗，在過去幾年?直致力于研究服務(wù)穩(wěn)定性建設(shè)和可觀測性方面的問題，積累了豐富經(jīng)驗。曾在多家公司主導(dǎo)設(shè)計和開發(fā)監(jiān)控相關(guān)系統(tǒng)

圖片