隨著 Prometheus 逐漸成為云原生時(shí)代的可觀測(cè)事實(shí)標(biāo)準(zhǔn)，那么今天為大家?guī)碓谖⒎?wù)架構(gòu)下基于 Prometheus 構(gòu)建一體化監(jiān)控平臺(tái)的最佳實(shí)踐和一些相關(guān)的思考，內(nèi)容主要包括以下幾個(gè)部分：

• 微服務(wù)、容器化技術(shù)演進(jìn)的監(jiān)控之痛
• 云原生時(shí)代，為什么是 Prometheus
• 阿里云 Prometheus 在微服務(wù)場(chǎng)景的落地實(shí)踐
• 大規(guī)模落地實(shí)踐挑戰(zhàn)和解決方案
• 云原生可觀測(cè)性的發(fā)展趨勢(shì)和展望

一、微服務(wù)、容器化技術(shù)演進(jìn)的監(jiān)控之痛

1.第一個(gè)挑戰(zhàn)：監(jiān)控對(duì)象動(dòng)態(tài)化

容器化部署使得我們的監(jiān)控對(duì)象變得動(dòng)態(tài)化。隨著 K8s 這種服務(wù)編排框架大規(guī)模落地，應(yīng)用部署單元從原來的主機(jī)變成一個(gè) Pod。Pod 在每次發(fā)布時(shí)銷毀重建，IP 也發(fā)生變化。在微服務(wù)體系下，我們講究快速迭代、持續(xù)集成，這使得發(fā)布變得愈發(fā)頻繁，Pod 生命周期變得非常短暫。據(jù)統(tǒng)計(jì)，平均每個(gè) Pod 的生命周期只有兩三天，然后就會(huì)被銷毀，再去重建。而且隨著 DevOps 普及，負(fù)責(zé)應(yīng)用發(fā)布的角色發(fā)生變化，應(yīng)用發(fā)布變得弱管控和更加敏捷，一個(gè)應(yīng)用會(huì)不斷的進(jìn)行滾動(dòng)發(fā)布，從而達(dá)成快速迭代的目標(biāo)。

所以說，隨著軟件生產(chǎn)流程的變化和相關(guān)技術(shù)的成熟，我們的監(jiān)控對(duì)象處于一個(gè)不斷頻繁變化的狀態(tài)之中。

2.第二個(gè)挑戰(zhàn)：監(jiān)控層次/對(duì)象多樣化

首先，Kubernetes 相關(guān)的 kube 組件以及容器層是我們必須要監(jiān)控的新對(duì)象。其次，微服務(wù)拆分之后，以及行業(yè)在中間件，DB 等領(lǐng)域的精細(xì)化發(fā)展使我們發(fā)現(xiàn)依賴的 PaaS 層組件越來越多樣化，對(duì)這些應(yīng)用強(qiáng)依賴的 PaaS 組件也需要進(jìn)行監(jiān)控。最后就是多語言。當(dāng)微服務(wù)拆分之后，每個(gè)團(tuán)隊(duì)都可以選擇自己擅長的語言去進(jìn)行應(yīng)用開發(fā)。這就造成一個(gè)問題，即這些應(yīng)用的監(jiān)控指標(biāo)需要支持各種語言的 client library 才能去生產(chǎn)和暴露。

3.第三個(gè)挑戰(zhàn)：監(jiān)控內(nèi)容復(fù)雜化

監(jiān)控內(nèi)容復(fù)雜化來源于以下幾點(diǎn)，第一個(gè)是復(fù)雜的應(yīng)用依賴。第二個(gè)是在高度分布式環(huán)境下，我們需要非常復(fù)雜，細(xì)顆粒度的指標(biāo)才能描繪整個(gè)系統(tǒng)狀態(tài)。

上面這張圖我們可以更直觀的感受到以上挑戰(zhàn)是如何產(chǎn)生的，左邊是傳統(tǒng)單體應(yīng)用的部署架構(gòu)，右邊是微服務(wù)部署的架構(gòu)。原來只需監(jiān)控一個(gè)應(yīng)用對(duì)象，現(xiàn)在變成了幾十、上百個(gè)且不停的動(dòng)態(tài)的發(fā)布，IP 地址不停變化。傳統(tǒng)監(jiān)控工具可能會(huì)采用靜態(tài)配置的方式去發(fā)現(xiàn)這些監(jiān)控目標(biāo)。但在微服務(wù)場(chǎng)景下，這種方式已經(jīng)無法實(shí)施。原來單體應(yīng)用可能只需要依賴 MySQL 就可以了。但現(xiàn)在依賴的組件越來越多。傳統(tǒng)監(jiān)控工具是沒有辦法全面支持這種龐大的監(jiān)控需求，且傳統(tǒng)監(jiān)控工具缺乏在容器層的監(jiān)控能力。

為了解決上述問題，我們發(fā)現(xiàn) Prometheus 或許是一個(gè)理想的解決方案。

二、云原生時(shí)代，為什么是 Prometheus

• 動(dòng)態(tài)化：Prometheus 具有先發(fā)優(yōu)勢(shì)。在 Kubernetes 誕生之初，標(biāo)配監(jiān)控工具就是 Prometheus，天然契合 Kubernetes 的架構(gòu)與技術(shù)特征，可以去自動(dòng)發(fā)現(xiàn)監(jiān)控目標(biāo)。在大規(guī)模、監(jiān)控目標(biāo)不停變化的監(jiān)控場(chǎng)景下，根據(jù)實(shí)踐經(jīng)驗(yàn)，主動(dòng)拉取采集是一種比較好的實(shí)現(xiàn)方式，可以避免監(jiān)控目標(biāo)指標(biāo)漏采，監(jiān)控目標(biāo)需要解決維護(hù)采集點(diǎn)配置以及 push 模式實(shí)現(xiàn)成本較大等一系列問題。其次，動(dòng)態(tài)化的容器指標(biāo)通過 Kubernetes 的 Kubelet/VK 組件采集，它們天然采用 Prometheus 格式生產(chǎn)和暴露指標(biāo)數(shù)據(jù)。
• 多樣化：因?yàn)?Kubernetes 有很多的控制面組件，比如 API server 等組件，也是天然通過 Prometheus 數(shù)據(jù)格式來暴露監(jiān)控指標(biāo)，這使得 Prometheus 采集這些組件的監(jiān)控指標(biāo)非常標(biāo)準(zhǔn)和簡(jiǎn)單。其次，Prometheus 是一個(gè)開放性社區(qū)，有 100+ 個(gè)官方或非官方 exporter 可以供大家使用。比如，你想監(jiān)控?cái)?shù)據(jù)庫、消息隊(duì)列、分布式存儲(chǔ)、注冊(cè)中心、網(wǎng)關(guān)，各種各樣的 exporter 開箱即用，可以把原組件非 Prometheus 標(biāo)準(zhǔn)的數(shù)據(jù)格式轉(zhuǎn)化成 Prometheus 的數(shù)據(jù)格式供采集器進(jìn)行采集。再者，Prometheus 支持 go、Python、Java 等 20 多種語言，可以非常簡(jiǎn)單的為應(yīng)用生成和暴露監(jiān)控的 metric。最后，Prometheus 可擴(kuò)展性非常強(qiáng)，如果上面都滿足不了應(yīng)用需求，它也有強(qiáng)大的工具可以幫助業(yè)務(wù)方輕松的寫出自己的 exporter。
• 復(fù)雜化：Prometheus 定義了一個(gè)多維模型。多維模型可以簡(jiǎn)單理解為我可以給任何事情都打上標(biāo)簽，通過標(biāo)簽的方式來描述對(duì)象的系統(tǒng)狀態(tài)。多維模型聽起來比較簡(jiǎn)單，但很多監(jiān)控工具最開始無法用這種方式去描述它的監(jiān)控目標(biāo)。通過多維模型，我們可以很容易刻畫出整個(gè)監(jiān)控目標(biāo)的復(fù)雜狀態(tài)，還可以刻畫出應(yīng)用之間的依賴關(guān)系。

其次，Prometheus 實(shí)現(xiàn)了一種稱為 PromQL 的查詢語言，非常強(qiáng)大，可以將復(fù)雜的指標(biāo)進(jìn)行過濾、聚合、計(jì)算。它內(nèi)置有 20-30 種計(jì)算函數(shù)和算子，包括常見的累加，差值，平均值、最大最小值，P99，TopK 等，可以基于這些計(jì)算能力直接繪制指標(biāo)視圖和配置告警，這可以省去原本需要的代碼開發(fā)工作，非常容易的得到想要的業(yè)務(wù)結(jié)果。

可以看到上圖中一個(gè)真實(shí)的 PromQL 語句，http_request_duration_seconds_bucket 是一個(gè) Histogram 類型的指標(biāo)，它有多個(gè) bucket，通過上面的 PromQL 語句，不用編寫任何代碼就可以計(jì)算出 RT 超過 500ms 和 1200ms 的請(qǐng)求占比，從而得出 Apdex Score，評(píng)價(jià)某個(gè)接口的服務(wù)能力。

三、Prometheus 落地實(shí)踐方案

接下來，我們看一個(gè)完整的落地實(shí)踐方案。其核心就是如何圍繞 Prometheus 來構(gòu)建可觀測(cè)平臺(tái)，也就是如何把描述系統(tǒng)狀態(tài)的各個(gè)層次的指標(biāo)數(shù)據(jù)都匯聚到 Prometheus 數(shù)據(jù)監(jiān)控?cái)?shù)據(jù)平臺(tái)上。

之前我們幾乎是不可能完成這種將各類指標(biāo)進(jìn)行匯聚的工作的。因?yàn)槊總€(gè)監(jiān)控工具專注的領(lǐng)域不一樣，數(shù)據(jù)格式不一樣，工具之間的數(shù)據(jù)無法打通，即使匯聚在一起也無法產(chǎn)生 1+1>2 的效果。

但通過 Prometheus 可以把 IaaS、PaaS 層的各種組件的監(jiān)控指標(biāo)都匯聚在一起。如果需要采集一些業(yè)務(wù)指標(biāo)、應(yīng)用的健康狀態(tài)、云上應(yīng)用所依賴的云產(chǎn)品是否正常，Kubernetes 組件有沒有在正常運(yùn)行，容器的 CPU，內(nèi)存水位是否符合預(yù)期，Node 節(jié)點(diǎn) tcp 連接數(shù)分配有沒有風(fēng)險(xiǎn)，或者需要將 tracing 轉(zhuǎn)成 metric，log 轉(zhuǎn)成 metric，甚至一些 CI/CD 事件想要和核心監(jiān)控視圖關(guān)聯(lián)起來，從而快速發(fā)現(xiàn)到底監(jiān)控視圖的數(shù)據(jù)異常是不是由某次變更引起的。我們都有成熟的工具以將以上描述我們系統(tǒng)運(yùn)行狀態(tài)的指標(biāo)采集到 Prometheus 平臺(tái)。

另外，我們還可以把一些把無意義的計(jì)算單元，通過標(biāo)記的方式標(biāo)記成有意義的業(yè)務(wù)語義，然后把這些指標(biāo)也匯聚到 Prometheus 上面來。

所以這里的核心思想就是打破數(shù)據(jù)邊界，把所有能夠真實(shí)反映我們當(dāng)前運(yùn)行系統(tǒng)狀態(tài)的指標(biāo)匯聚在一起，無代碼編寫成本，就可以將這些數(shù)據(jù)關(guān)聯(lián)，生產(chǎn)出有效的監(jiān)控視圖和告警。在具體實(shí)施方面我們總結(jié)出三個(gè)層次，以便更好的實(shí)施。

第一個(gè)層次：從業(yè)務(wù)視角定義核心目標(biāo)

首先，我們需要定義核心目標(biāo)，這些監(jiān)控的指標(biāo)一定是為業(yè)務(wù)服務(wù)，指標(biāo)本身并無實(shí)際意義，只是一個(gè)數(shù)值，只有確定的業(yè)務(wù)目標(biāo)才能賦予這些指標(biāo)生命力。

第二個(gè)層次：聚焦核心指標(biāo)&提供角色視圖

在制定核心目標(biāo)后，我們需要確定核心目標(biāo)可以被量化。需要特別注意，核心指標(biāo)一定是動(dòng)態(tài)變化的，因?yàn)槲⒎?wù)的特點(diǎn)就是要不?？焖俚?。今天可能還沒有依賴某組件，可能下個(gè)迭代就依賴了，如果你沒有被依賴組件的指標(biāo)，會(huì)非常痛苦。因?yàn)闆]有辦法通過這些核心指標(biāo)去完整映射核心目標(biāo)到底有沒有異常。另外，需要根據(jù)角色去提供視圖，一個(gè)組織里不同角色關(guān)心的視圖是不一樣的，當(dāng)出現(xiàn)問題時(shí)，角色視圖可以幫助更快地排查問題。

第三個(gè)層次：全量收集&提前定義&提前聚合/過濾

想要實(shí)現(xiàn)上面兩層的核心基礎(chǔ)其實(shí)就是是全量收集，即能采集的指標(biāo)一定要應(yīng)采盡采。全量采集的技術(shù)基礎(chǔ)是 metric 指標(biāo)的存儲(chǔ)成本是相對(duì)于 log 還有 trace 而言最小，即使全量采集也不會(huì)讓成本膨脹太多，卻能讓你的核心目標(biāo)度量效果即使在快速迭代的過程也不受損。

在全量采集前提下，我們要盡早去聚合或過濾掉高基數(shù)的 label。高基數(shù)問題是時(shí)序場(chǎng)景常遇到的問題，我們會(huì)看到采集的容器層指標(biāo)帶一些 Pod ID，但這種 label 是沒有實(shí)際業(yè)務(wù)意義，再比如 URL path 會(huì)發(fā)散，帶上了 uid 或者 order id 之類的業(yè)務(wù) id，我們可能關(guān)心的是整個(gè)接口的健康狀態(tài)，而不是某一個(gè) path 的，這時(shí)就需要把 path 聚合一下，通過這種聚合可以減少存儲(chǔ)成本，提升存儲(chǔ)穩(wěn)定性，也不會(huì)影響核心目標(biāo)的達(dá)成。

另外，在我們采集指標(biāo)時(shí)，盡量找出多層之間有關(guān)聯(lián)關(guān)系的 label。比如在采集一些應(yīng)用指標(biāo)時(shí)，我們可以通過 Prometheus relabel 的功能把 pod name 一起采集過來，這樣就可以直接建立應(yīng)用和容器層的關(guān)聯(lián)視圖，在排查問題時(shí)通過關(guān)聯(lián)分析減少 MTTD 時(shí)間。

接下來，我們講一下如何利用 Tag 細(xì)化監(jiān)控范圍。Pod 本身是沒有實(shí)際的業(yè)務(wù)語義的，但打上一些標(biāo)簽后，比如 某個(gè) Pod 屬于登錄服務(wù)還是支付服務(wù)，屬于生產(chǎn)環(huán)境還是測(cè)試、預(yù)發(fā)環(huán)境。就使得 Pod 這個(gè)計(jì)算單元有了實(shí)際業(yè)務(wù)語義。當(dāng)有了業(yè)務(wù)語義之后，就可以配置出低噪音的告警。比如當(dāng)我們支付成功率低于三個(gè) 9 的時(shí)候，認(rèn)為核心目標(biāo)已經(jīng)受損了，需要馬上告警出來。告警之后通過 Tag，就可以迅速定位到底是生產(chǎn)環(huán)境還是測(cè)試環(huán)境的問題。

如果是生產(chǎn)環(huán)境就要馬上去處理，可以定位到底在北京哪個(gè)可用區(qū)，告警的原因到底是因?yàn)槟膫€(gè)服務(wù)的接口出現(xiàn)了異常。所以說告警的有效性也非常重要，因?yàn)槲覀冊(cè)趯?shí)踐中都知道，如果告警一直是處于流量轟炸狀態(tài)，告警最后就會(huì)變得沒有意義。

通過 Tag，我們可以提供場(chǎng)景化的視圖，假設(shè)老板想要去撈取生產(chǎn)環(huán)境下支付服務(wù) CPU 利用率 Top5 的 Pod 列表，通過 Tag 加上 PromQL 語言，我們一條語句就可以把這個(gè)視圖馬上撈取出來。

講一個(gè)真實(shí)的電商場(chǎng)景如何通過 Prometheus 構(gòu)建統(tǒng)一監(jiān)控平臺(tái)的。從圖中看到，電商系統(tǒng)的主體已經(jīng)遷移到阿里云上，分兩部分，一部分是在 Kubernetes 集群，另一部分是在 ECS 的虛機(jī)集群。每個(gè)服務(wù)依賴不同的中間件或 DB 組件，有些依賴云產(chǎn)品，還有一些依賴原有自建 DB 或組件。

我們可以看到使用之前的監(jiān)控方案，很難實(shí)現(xiàn)全面的監(jiān)控指標(biāo)采集。應(yīng)用層的同學(xué)通常只關(guān)心應(yīng)用層正不正常，有哪些指標(biāo)可以反映健康狀態(tài)，他們可能會(huì)選擇一些 APM 工具，或者其使用的開發(fā)語言相關(guān)的特定監(jiān)控工具，比如使用 Spring Boot 的開發(fā)同學(xué)會(huì)通過 Actuator 監(jiān)控應(yīng)用狀態(tài)。而負(fù)責(zé) SRE 的同學(xué)通常會(huì)關(guān)心基礎(chǔ)設(shè)施正不正常，怎么監(jiān)控 Kubernetes 組件，容器的黃金指標(biāo)水位是否正常。他們可能是不同的部門，會(huì)通過不同監(jiān)控工具實(shí)現(xiàn)不同的監(jiān)控系統(tǒng)，這些系統(tǒng)之間是割裂的，所以你去排查一個(gè)問題，我們都有一個(gè)體感，很多時(shí)候可能是網(wǎng)絡(luò)問題，有些時(shí)候可能是某一臺(tái)主機(jī)有問題，影響了應(yīng)用性能，如果只看應(yīng)用層，會(huì)覺得應(yīng)用代碼沒有問題，但是有了這樣一個(gè)全局的視圖，就會(huì)很快排查到影響你應(yīng)用的問題點(diǎn)到底在哪。

我們可以通過 node exporter 去采集 VM 層面 CPU、內(nèi)存、 IO 黃金三指標(biāo)，也可以通過云監(jiān)控的 exporter，監(jiān)控應(yīng)用依賴的云服務(wù)健康狀態(tài)。當(dāng)然 Kubernetes 和容器這一層 Prometheus 提供的能力更加全面，比如 kube-state-metrics 可以監(jiān)控 Kubernetes 的元信息，通過 cadvisor 可以采集容器運(yùn)行時(shí)指標(biāo)，還有各種 kube 組件的監(jiān)控，動(dòng)動(dòng)手指頭配置幾個(gè)采集 job，或者直接用開源或者云產(chǎn)品，開箱即用。

另外我們團(tuán)隊(duì)提供了 ARMS APM，以無侵入的方式去生產(chǎn)，暴露應(yīng)用的指標(biāo)，全面監(jiān)控應(yīng)用健康狀態(tài)。如果不能滿足需求的話，你也可以使用 Prometheus 官方的多語言 client library 或者三方提供的一些 client library 很方便的去生產(chǎn)和暴露你的指標(biāo)。還有很多官方或者三方的 exporter 可以用來監(jiān)控 mysql，redis，nginx，kafka 等 DB 和中間件。除此之外，針對(duì)特定語言開發(fā)，比如 JVM，還有 JMX exporter 可以使用，查看堆內(nèi)存有使用正不正常，GC 是不是在頻繁的發(fā)生。

通過 Prometheus 及其生態(tài)，規(guī)范化，統(tǒng)一的指標(biāo)可以很容易的匯聚在一起，接下來我們就可以定義 SLO。在電商系統(tǒng)場(chǎng)景下，以支付成功率為例，這是很要命的一個(gè)指標(biāo)，如果你的支付成功率低了，可能今天 gaap 就會(huì)損失很大。通過 SLI 去準(zhǔn)確衡量核心目標(biāo)是否受損。比如 SLI 是應(yīng)用層面的接口 error 這種指標(biāo)，可能還需要關(guān)注應(yīng)用運(yùn)行的容器，其內(nèi)存、CPU 是否在健康水位，如果超出健康水位，這可能就是預(yù)警，在接下來某段時(shí)間就會(huì)發(fā)生故障。有了這些指標(biāo)，使用 Grafana 和 AlertManager，就可以輕松完成可視化和告警配置，在應(yīng)用異常不符合預(yù)期時(shí)及時(shí)告警，快速定位問題范圍。

如圖，我們可以看到 Grafana 全面的展示了應(yīng)用層，依賴的中間件、容器層、以及主機(jī)層的全量視圖。

基于 Prometheus，我們還可以衍生出非常多的應(yīng)用。舉個(gè)例子，Kubernetes 上的網(wǎng)絡(luò)拓?fù)涫呛茈y刻畫出來的，但基于 epbf 技術(shù)可以采集 Kubernetes 工作負(fù)載間的各種關(guān)聯(lián)關(guān)系，可以把這種關(guān)聯(lián)關(guān)系轉(zhuǎn)換成 metrics，結(jié)合 Prometheus 采集 Kubernetes 集群元信息指標(biāo)，可以非常方便的刻畫出整個(gè)網(wǎng)絡(luò)拓?fù)?，方便定位集群?nèi)的網(wǎng)絡(luò)問題。我們已經(jīng)提供了相關(guān)的云產(chǎn)品，并且由于基于 ebpf 實(shí)現(xiàn)，也是多語言適用且完全無侵入的。

還有一個(gè)例子和資源使用成本相關(guān)，由于云原生架構(gòu)的彈性和動(dòng)態(tài)化，我們很難計(jì)量各個(gè)應(yīng)用消耗了多少資源，付出多少成本。但通過 Prometheus 加上自己的賬單系統(tǒng)，定義好每個(gè)資源的計(jì)費(fèi)，很容易去刻畫出來一個(gè)部門和各個(gè)應(yīng)用的成本視圖。當(dāng)應(yīng)用出現(xiàn)資源消耗不合理時(shí)，我們還可以給出優(yōu)化建議。

四、大規(guī)模落地實(shí)踐挑戰(zhàn)和解決方案

接下來我們討論下，落地 Prometheus 有哪些技術(shù)上的挑戰(zhàn)以及相應(yīng)的解決方案，這其中包括：

• 多云、多租場(chǎng)景
• 規(guī)?；\(yùn)維
• 可用性降低，MTTD 和 MTTR 時(shí)間長
• 大數(shù)據(jù)量、大時(shí)間跨度查詢性能差
• GlobalView
• 高基數(shù)問題

為了應(yīng)對(duì)以上挑戰(zhàn)，我們對(duì)采集和存儲(chǔ)進(jìn)行了分離。這樣的好處就是采集端做的盡量輕，存儲(chǔ)端可用性做的足夠強(qiáng)，這樣就可以支持公有云、混合云、邊緣或者多元環(huán)境。在分離之后，我們針對(duì)采集、存儲(chǔ)分別進(jìn)行可用性優(yōu)化，并保持與開源一致的使用方式。

接下來，可以看到部署拓?fù)鋱D，采集端就是部署在業(yè)務(wù)方的集群里面，所以天然就是多租的，存儲(chǔ)端我們用超大規(guī)模 Kubernetes 集群進(jìn)行多租部署，計(jì)算存儲(chǔ)分離，這些租戶共享資源池，在容器層物理隔離，通過云盤和 NAS 存儲(chǔ)索引和指標(biāo)數(shù)值文件，可以保證一定彈性和單租戶水平擴(kuò)容能力，同時(shí)我們對(duì)每個(gè)租戶使用的資源又有限制，避免某個(gè)租戶對(duì)資源的消耗影響到其他租戶。

最后為了解決多租問題，我們做了中心化的元信息管理，保證租戶數(shù)據(jù)的最終一致性。在進(jìn)行故障調(diào)度時(shí)，可以通過中心化的元信息管理，非常方便進(jìn)行故障轉(zhuǎn)移。改造之后，當(dāng) node 發(fā)生故障，在一分鐘之內(nèi)就可以恢復(fù)，Pod 發(fā)生故障，10s 可以恢復(fù)。

我們對(duì)采集側(cè)進(jìn)行了可用性改造，因?yàn)殚_源 Prometheus 是一個(gè)單體應(yīng)用，單副本是無法保障高可用的。我們把采集端改造成一個(gè)多副本模型，共享同樣的采集配置，根據(jù)采集量將采集目標(biāo)調(diào)度到不同的副本上。當(dāng)采集量發(fā)生變化或有新增的采集目標(biāo)時(shí)，會(huì)計(jì)算副本的采集水位，進(jìn)行動(dòng)態(tài)擴(kuò)容，保證采集可用性。

在存儲(chǔ)側(cè)，我們也做了一些可用性保障措施。在寫的時(shí)候，可以根據(jù)時(shí)間線的數(shù)量來動(dòng)態(tài)擴(kuò)容存儲(chǔ)節(jié)點(diǎn)，也可以根據(jù)索引所使用的 pagecache 有沒有超限來進(jìn)行擴(kuò)容。在讀的時(shí)候，也會(huì)根據(jù)時(shí)間線數(shù)量，還有時(shí)間點(diǎn)的數(shù)量進(jìn)行限制，保證查詢和存儲(chǔ)節(jié)點(diǎn)的可用性。另外我們知道時(shí)序數(shù)據(jù)庫都會(huì)做壓縮，如果集中壓縮的話，IO 抖動(dòng)非常厲害，所以我們做了一個(gè)調(diào)度算法把節(jié)點(diǎn)進(jìn)行分批壓縮，這樣就可以減少抖動(dòng)。

在大數(shù)據(jù)量查詢性能方面，我們可以看一個(gè)比較典型的 PromQL 查詢案例?？倲?shù)據(jù)量有 6 億個(gè)時(shí)間點(diǎn)，600 萬個(gè)時(shí)間線。如果使用開源系統(tǒng)進(jìn)行查詢，要占用 25G 的帶寬，查詢耗時(shí)可能是三分鐘。但我們做了一些優(yōu)化，比如 DAG 執(zhí)行優(yōu)化，簡(jiǎn)單講就是對(duì)執(zhí)行語句進(jìn)行解析，如果發(fā)現(xiàn)有重復(fù)的子查詢，就去重，然后并行化查詢降低 RT。

還有算子下推，將一些算子計(jì)算邏輯從查詢節(jié)點(diǎn)下推到存儲(chǔ)節(jié)點(diǎn)實(shí)現(xiàn)，可以減少原始指標(biāo)數(shù)據(jù)的傳輸，大幅度降低 RT。

針對(duì)大促場(chǎng)景，應(yīng)用開發(fā)者或 SRE 在大促之前頻繁查詢大盤，執(zhí)行的 PromQL 除了起止時(shí)間有些微差別，其他都是一樣的，因此，我們做了場(chǎng)景化設(shè)計(jì)，將計(jì)算結(jié)果緩存，對(duì)超出起止時(shí)間緩存范圍的部分進(jìn)行增量查詢。

最后通過 Gorilla 壓縮算法結(jié)合流式響應(yīng)，避免批量一次性的加載到內(nèi)存里面進(jìn)行計(jì)算。經(jīng)過優(yōu)化之后，對(duì)大規(guī)模、大數(shù)據(jù)量的查詢性能優(yōu)化到 8~10 秒，并對(duì) 70% 場(chǎng)景都可以提升 10 倍以上性能。

這一部分簡(jiǎn)單聊一下安全問題。云上應(yīng)用是非常注重安全的，有些指標(biāo)數(shù)據(jù)比較敏感，可能不希望被無關(guān)業(yè)務(wù)方抓取到。因此，我們?cè)O(shè)計(jì)了租戶級(jí)別的鑒權(quán)機(jī)制，會(huì)對(duì)生成 Token 的密鑰進(jìn)行租戶級(jí)別加密，加密流程是企業(yè)級(jí)安全的。如果出現(xiàn) Token 泄露，可以收斂影響范圍到租戶級(jí)別，只需要受影響的租戶換一下加密密鑰生成新的 Token，廢棄掉舊 Token 就可以消除安全風(fēng)險(xiǎn)。

除了以上部分，我們也做了一些其他技術(shù)優(yōu)化，下面簡(jiǎn)單介紹一下。

• 高基數(shù)問題

通過預(yù)聚合，把發(fā)散指標(biāo)進(jìn)行收斂，在減少存儲(chǔ)成本的同時(shí)，一定程度上緩解高基數(shù)問題。另外我們做了全局索引的優(yōu)化，將時(shí)間線索引拆分到 shard 級(jí)別，當(dāng) shard 過期之后，索引也會(huì)隨之刪除，減少了短時(shí)間跨度查詢時(shí)需要加載的時(shí)間線數(shù)量。

• 大時(shí)間跨度查詢

實(shí)現(xiàn) Downsampling，犧牲一定精度來換取查詢性能與可用性。

• 采集能力

提升單副本采集能力，可以減少 agent 用戶側(cè)的資源消耗。

最后是阿里云 Proemtheus 監(jiān)控與開源版本的對(duì)比。

在可用性方面，開源版本到了百萬級(jí)時(shí)間線，內(nèi)存消耗會(huì)出現(xiàn)暴漲，基本上是不可用的。而且因?yàn)槭菃胃北荆绻霈F(xiàn)一些網(wǎng)絡(luò)異?；蛘咚诘乃拗鳈C(jī)出現(xiàn)問題，整個(gè)監(jiān)控系統(tǒng)就是不可用的。

雖然開源的 Thanos、Cortex 做了一些可用性增強(qiáng)，但總體來講他們并沒有完全解決可用性問題。我們做了采集存儲(chǔ)架構(gòu)分離，采集存儲(chǔ)端理論上可以無限水平擴(kuò)容，可用性比較高。而且存儲(chǔ)時(shí)長理論上也沒有上限，而開源版本存儲(chǔ)一個(gè)月指標(biāo)，時(shí)間線就會(huì)膨脹得非常厲害，查詢和寫入基本上都是不可用的。

五、云原生可觀測(cè)性的發(fā)展趨勢(shì)和展望

最后聊一聊云原生可觀測(cè)性的發(fā)展趨勢(shì)，個(gè)人認(rèn)為將來可觀測(cè)性一定是標(biāo)準(zhǔn)化且由開源驅(qū)動(dòng)的。現(xiàn)在整個(gè)軟件架構(gòu)體系變得越來越復(fù)雜，我們要監(jiān)控的對(duì)象越來越多，場(chǎng)景也越來越廣。封閉的單一廠商很難面面俱到的去實(shí)現(xiàn)全局可觀測(cè)能力，需要社區(qū)生態(tài)共同參與，用開放、標(biāo)準(zhǔn)的方法來構(gòu)建云原生可觀測(cè)性。

我們可以看一下 metric、log、tracing 的關(guān)系，這三者在不同維度上從低到高，各有特長。

在告警有效性上來說，metric 是最有效的，因?yàn)?metric 最能真實(shí)反映系統(tǒng)狀態(tài)，不會(huì)因?yàn)榕及l(fā)抖動(dòng)造成告警轟炸，告警平臺(tái)完全失效的問題。但在排查問題的深度上，肯定還是需要去看 tracing 和 log。另外在單條記錄存儲(chǔ)成本上，metric 遠(yuǎn)低于 tracing 和 log。所以基于此，個(gè)人認(rèn)為將來會(huì)以 metric 為接入點(diǎn)，再去關(guān)聯(lián) tracing 和 log，tracing 和 log 只在 metric 判定系統(tǒng)異常時(shí)才需要采集存儲(chǔ)。這樣就可以既保證問題拋出的有效性，又能降低資源使用成本，這樣的形態(tài)是比較理想合理，符合未來發(fā)展趨勢(shì)的。