入坑可觀測體系建設(shè)后，才發(fā)現(xiàn)會(huì)遇到這么多難題……

作者：陳成禧 2023-07-28 07:22:55

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

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

圖片

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

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

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

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

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

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

圖片

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

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

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

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

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

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

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

圖片

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

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

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

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

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

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

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

但是，因?yàn)槲覀兪嵌嘣啤⒍郣egion，K8S集群也非常多，Prometheus單機(jī)部署又存在單點(diǎn)故障的風(fēng)險(xiǎn)，因此不能進(jìn)行中心化。

圖片

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

圖片

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

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

3、如何解決高基指標(biāo)問題？

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

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

圖片

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

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

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

圖片

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

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

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

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

圖片

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

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

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

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

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

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

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

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

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

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

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

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

圖片

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

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

圖片

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

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

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

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

圖片

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

圖片

上面是SLO的燃盡圖，明確地展示我們當(dāng)前這個(gè)O離目標(biāo)還可以有多少時(shí)間可以消耗。

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

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

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

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

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

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

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

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

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

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

四、未來展望

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

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

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

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

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

eBPF是什么呢？

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

它的特性包括：

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

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

用戶體驗(yàn)層觀測

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

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

圖片

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

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