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

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

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

1.第一個挑戰(zhàn)：監(jiān)控對象動態(tài)化

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

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

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

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

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

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

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

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

二、云原生時代，為什么是 Prometheus

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

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

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

三、Prometheus 落地實踐方案

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

之前我們幾乎是不可能完成這種將各類指標(biāo)進行匯聚的工作的。因為每個監(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 組件有沒有在正常運行，容器的 CPU，內(nèi)存水位是否符合預(yù)期，Node 節(jié)點 tcp 連接數(shù)分配有沒有風(fēng)險，或者需要將 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)運行狀態(tài)的指標(biāo)采集到 Prometheus 平臺。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們可以通過 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 可以采集容器運行時指標(biāo)，還有各種 kube 組件的監(jiān)控，動動手指頭配置幾個采集 job，或者直接用開源或者云產(chǎn)品，開箱即用。

另外我們團隊提供了 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 和中間件。除此之外，針對特定語言開發(fā)，比如 JVM，還有 JMX exporter 可以使用，查看堆內(nèi)存有使用正不正常，GC 是不是在頻繁的發(fā)生。

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

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

基于 Prometheus，我們還可以衍生出非常多的應(yīng)用。舉個例子，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)，可以非常方便的刻畫出整個網(wǎng)絡(luò)拓?fù)洌奖愣ㄎ患簝?nèi)的網(wǎng)絡(luò)問題。我們已經(jīng)提供了相關(guān)的云產(chǎn)品，并且由于基于 ebpf 實現(xiàn)，也是多語言適用且完全無侵入的。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 高基數(shù)問題

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

• 大時間跨度查詢

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

• 采集能力

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

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

在可用性方面，開源版本到了百萬級時間線，內(nèi)存消耗會出現(xiàn)暴漲，基本上是不可用的。而且因為是單副本，如果出現(xiàn)一些網(wǎng)絡(luò)異?；蛘咚诘乃拗鳈C出現(xiàn)問題，整個監(jiān)控系統(tǒng)就是不可用的。

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

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

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

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

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