一、背景介紹

隨著vivo業(yè)務(wù)遷移到容器平臺(tái)，vivo云原生監(jiān)控體系面臨著指標(biāo)量快速上漲帶來的一系列挑戰(zhàn)，本文將分享vivo 容器化項(xiàng)目中容器監(jiān)控遇到的問題以及我們的解決和優(yōu)化方法。

二、監(jiān)控架構(gòu)

首先對(duì)vivo容器監(jiān)控架構(gòu)進(jìn)行一個(gè)簡單的介紹。

【資料圖】

【架構(gòu)高可用】：集群維度的雙副本 Prometheus 采集底層exporter數(shù)據(jù)，adapter多實(shí)例自動(dòng)選主實(shí)現(xiàn)容災(zāi)?！緮?shù)據(jù)持久化】：通過remoteWrite將數(shù)據(jù)存儲(chǔ)到后端的VictoriaMetrics中進(jìn)行持久化存儲(chǔ)，Grafana使用VictoriaMetrics做為數(shù)據(jù)源展示和告警?！颈O(jiān)控統(tǒng)一化】：通過remoteWrite將數(shù)據(jù)交由kafka-adapter轉(zhuǎn)發(fā)到Kafka，由公司基礎(chǔ)監(jiān)控等服務(wù)通過消費(fèi)Kafka中的數(shù)據(jù)來進(jìn)行展示和告警。

原生Prometheus沒有提供高可用的標(biāo)準(zhǔn)方案，我們通過自研 Adapter “分組選舉”方式實(shí)現(xiàn)去重，即每個(gè) Prometheus 副本對(duì)應(yīng)一組 Adapter，兩組 Adapter 之間會(huì)進(jìn)行選主，只有Leader組的 Adapter才會(huì)轉(zhuǎn)發(fā)數(shù)據(jù)。通過這種方式既實(shí)現(xiàn)了去重，也實(shí)現(xiàn)了Prometheus雙副本高可用。

三、問題現(xiàn)象

過去幾年來，vivo容器化服務(wù)快速增長，監(jiān)控流量上漲數(shù)倍，我們主要遇到如下三個(gè)問題：監(jiān)控組件負(fù)載快速升高、容器監(jiān)控?cái)?shù)據(jù)斷點(diǎn)和數(shù)據(jù)存儲(chǔ)組件負(fù)載陡增。

3.1 監(jiān)控組件負(fù)載快速升高

容器化每次部署IP都會(huì)變化的特性，導(dǎo)致容器監(jiān)控指標(biāo)量相比物理機(jī)和虛擬機(jī)要高出好幾個(gè)數(shù)量級(jí)。同時(shí)由于集群規(guī)模的不斷增加以及業(yè)務(wù)的快速增長，導(dǎo)致監(jiān)控 Prometheus、VictoriaMetrics 負(fù)載快速增高，給我們?nèi)萜鞅O(jiān)控帶來極大的挑戰(zhàn)。監(jiān)控總時(shí)間序列可以精簡為以下的表達(dá)式，即與 Pod數(shù)量、Pod指標(biāo)量、指標(biāo)Label維度數(shù)量呈線性關(guān)系：

TotalSeries = PodNum * PerPodMetrics * PerLabelCount

而隨著集群規(guī)模的不斷增加以及容器數(shù)量的不斷增多，監(jiān)控序列就會(huì)快速增長，同時(shí)監(jiān)控組件負(fù)載快速升高，會(huì)對(duì)容器監(jiān)控系統(tǒng)的穩(wěn)定性產(chǎn)生影響。

3.2 監(jiān)控丟點(diǎn)現(xiàn)象

vivo容器層面（業(yè)務(wù)）的監(jiān)控?cái)?shù)據(jù)則通過自研Adapter轉(zhuǎn)發(fā)給Kafka，進(jìn)而存儲(chǔ)到公司基礎(chǔ)監(jiān)控做業(yè)務(wù)監(jiān)控展示和告警配置，同時(shí)也存儲(chǔ)一份到Druid做更多維度的統(tǒng)計(jì)報(bào)表。我們?cè)谕扑捅O(jiān)控?cái)?shù)據(jù)的時(shí)候發(fā)現(xiàn)，Pod維度的指標(biāo)難以保證發(fā)送頻率，即配置指標(biāo)采集頻率為 10s，但是在推送的數(shù)據(jù)中頻率無法做到10s，且會(huì)有波動(dòng)。下圖為 采集頻率設(shè)置 10s，查詢1分鐘的指標(biāo)數(shù)據(jù)。

一分鐘內(nèi)某一容器的

container_cpu_user_seconds_total 指標(biāo)的值：

可以看到只取到了4個(gè)值，與期望的 6個(gè)值不相符，即發(fā)生了“掉點(diǎn)”的情況，監(jiān)控面板按指定頻率展示數(shù)據(jù)會(huì)有頻繁掉0現(xiàn)象。

3.3 數(shù)據(jù)存儲(chǔ)組件負(fù)載陡增

vivo容器監(jiān)控使用 VictoriaMetrics的v1.59.1-cluster版本做為后端時(shí)序數(shù)據(jù)庫來持久化存儲(chǔ)監(jiān)控?cái)?shù)據(jù)。在使用過程中發(fā)現(xiàn) VictoriaMetrics的負(fù)載有不定期增高的情況，而后端數(shù)據(jù)庫的延遲會(huì)導(dǎo)致監(jiān)控查詢告警功能的異常影響用戶體驗(yàn)。

四、解法4.1 監(jiān)控組件負(fù)載快速升高

我們使用 Prometheus-Operator 管理 Prometheus，因?yàn)閮?yōu)化方案中有 Prometheus-Operator 相關(guān)的名詞，故為了下面的理解，先對(duì) Prometheus-Operator 做一個(gè)介紹：

（圖片來源：官方架構(gòu)圖）

上圖是Prometheus-Operator官方提供的架構(gòu)圖，下面來介紹下圖中各組件:

Operator: Operator是最核心的部分，作為一個(gè)控制器，他會(huì)去創(chuàng)建Prometheus、ServiceMonitor資源對(duì)象，然后會(huì)一直監(jiān)控并維持這些資源對(duì)象的狀態(tài)。Prometheus：這種資源對(duì)象就是作為Prometheus Server存在， Operator 根據(jù)自定義資源 Prometheus 類型中定義的內(nèi)容而部署的 Prometheus Server。Prometheus 也可以通過 labelSelector 去匹配多個(gè)ServiceMonitor。ServiceMonitor：ServiceMonitor就是exporter的各種抽象，exporter是用來提供專門提供metrics數(shù)據(jù)接口的服務(wù)。Prometheus就是通過ServiceMonitor提供的metrics數(shù)據(jù)接口去 pull 數(shù)據(jù)的。該資源通過 Labels 來選取對(duì)應(yīng)的 Service Endpoint，讓 Prometheus Server 通過選取的 Service 來獲取 Metrics 信息。一個(gè) ServiceMonitor 可以通過 labelSelector 的方式去匹配一類 Service。Service：Service是Kubernetes內(nèi)建資源用于把一組擁有相同功能的Pod封裝起來，并提供一個(gè)統(tǒng)一的入口來暴露這組Pod的服務(wù)，從而為客戶端訪問提供了一個(gè)穩(wěn)定的訪問地址，屏蔽了底層Pod的變化和故障。Service可以結(jié)合Kubernetes中的其他組件實(shí)現(xiàn)負(fù)載均衡、服務(wù)發(fā)現(xiàn)、集群內(nèi)部通信等功能。

我們重點(diǎn)關(guān)注 ServiceMonitor，因?yàn)镾erviceMonitor為我們提供了指定 target 采集的配置，例如采集頻率，target內(nèi)指標(biāo)過濾，指標(biāo)中l(wèi)abel重命名等等操作。

對(duì)于監(jiān)控組件負(fù)載快速升高問題的解決，我們主要從兩個(gè)方面著手，分別是指標(biāo)治理以及性能優(yōu)化。

圖片

4.1.1 指標(biāo)治理

1、過濾未使用指標(biāo)

第一個(gè)工作是過濾無用指標(biāo)，Prometheus 會(huì)去從 Target 中去獲取指標(biāo)數(shù)據(jù)。每個(gè) Target 下會(huì)有多個(gè) endponit。每一個(gè)endpoint 又會(huì)提供幾十上百個(gè)指標(biāo)，而每個(gè)指標(biāo)下的數(shù)據(jù)量也很大。但在生產(chǎn)環(huán)境中我們實(shí)際上用到的指標(biāo)可能只有幾十個(gè)，Prometheus采集過來我們又沒有用到的指標(biāo)就會(huì)浪費(fèi)資源并降低監(jiān)控系統(tǒng)的穩(wěn)定性。因此我們需要對(duì)Prometheus 采集到的指標(biāo)進(jìn)行一定程度的過濾，從而減少資源的占用。

通過Prometheus提供的

scrape_samples_scraped指標(biāo)對(duì)采集的 target進(jìn)行分析找到采集樣本量大的Target。

我們進(jìn)行指標(biāo)過濾主要就是關(guān)注這些數(shù)據(jù)量大的 target，在進(jìn)行指標(biāo)過濾之前需要收集 Prometheus所采集的所有指標(biāo)數(shù)據(jù)以及當(dāng)前監(jiān)控告警面板以及相關(guān)依賴服務(wù)所使用到的指標(biāo)。再根據(jù)采集的指標(biāo)和正在使用的指標(biāo)進(jìn)行正則表達(dá)式的書寫。最終在對(duì)應(yīng) target的 ServiceMonitor將正則表達(dá)式寫入。Prometheus則會(huì)過濾掉我們不需要的指標(biāo)。下面就是過濾 cAdvisor這個(gè) target 的 container_threads 開頭的指標(biāo)的示例。

# 過濾  container_threads  開頭的指標(biāo)    - action: drop      regex: container_threads(.*)      sourceLabels:      - __name__

完成指標(biāo)精簡后，監(jiān)控單次采集樣本量從 1000萬降低到 250萬。Prometheus 的CPU 使用量降低 70% ，內(nèi)存 使用量降低 55%。

2、過濾低優(yōu)先級(jí) pod 相關(guān)指標(biāo)

對(duì)精簡后的指標(biāo)進(jìn)行分析，發(fā)現(xiàn) Pod維度的監(jiān)控指標(biāo)占比為70%，且有相當(dāng)比例的 Pod 是集群組件的 Daemonset的Pod。而Daemonset的Pod是隨著集群規(guī)模的增加而增加的。

而對(duì)于大部分的集群組件Daemonset，因?yàn)樵O(shè)置了資源上限，我們不需要關(guān)注其資源消耗情況，只需要關(guān)注是否存活和正常提供服務(wù)即可。故可以對(duì)這部分 Pod 的指標(biāo)進(jìn)行一個(gè)精簡，不收集這些 Pod的 memory、cpu 等容器監(jiān)控指標(biāo)。

一個(gè) Daemonset 提供的 Pod 的 Namespace 是相同的，且Pod名稱前綴相同。

# 名稱為cadvisor的 daemonset 提供的 podcadvisor-xxxx1                                    1/1     Running            cadvisor-xxxx2                                    1/1     Running

且 cAdvisor 提供的指標(biāo)中包含了 namespace 和 pod 的 label。

container_memory_cache{cnotallow="POD", namespace="monitoring", pod="kube-state-metrics-xxxx-xxxx", service="cadvisor"}

所以我們通過在 ServiceMonitor 上面組合指標(biāo)的 pod 和 namespace，并與指定的規(guī)則進(jìn)行匹配丟棄掉我們不需要的 daemonset pod 的序列。

# 過濾掉 monitoring namespace 下面 telegraf 這個(gè)daemosnet提供的 pod 的相關(guān)指標(biāo)    - action: drop      regex: monitoring@telegraf(.*)      separator: "@"      sourceLabels:      - namespace      - pod

在對(duì)集群中部分ds Pod 的指標(biāo)進(jìn)行過濾后。

對(duì) cAdvisor 的單次采集數(shù)據(jù)量下降 70%。效果十分明顯。

4.1.2 性能優(yōu)化

1、均衡 Prometheus 負(fù)載

vivo 容器監(jiān)控架構(gòu)中最核心的組件就是 Prometheus了，而 Prometheus 也是日常出現(xiàn)問題最多的一個(gè)組件，因?yàn)?Prometheus 不僅是需要采集數(shù)據(jù),還需要將數(shù)據(jù)通過remote_write的方式推送的VictoriaMetrics 和 Kafka中。

圖片

將監(jiān)控 target 進(jìn)行分類交由不同的組 Prometheus 采集，且每類 Prometheus 為雙副本模式。隨著集群規(guī)模的增加，發(fā)現(xiàn)當(dāng)前模式的不合理之處，即因?yàn)镻od維度監(jiān)控?cái)?shù)據(jù)量級(jí)十分高，導(dǎo)致container 類型 Prometheus 負(fù)載遠(yuǎn)遠(yuǎn)高于其他類型的 Prometheus。在高負(fù)載的情況下面會(huì)發(fā)生重啟，remote_write 異常等情況。

我們 Prometheus組件架構(gòu)為按類型采集監(jiān)控指標(biāo)。其中 Container類型的 Prometheus采集的指標(biāo)數(shù)量遠(yuǎn)遠(yuǎn)大于 Component、Host、Resource類型。故需要手動(dòng)平衡 集群中 Prometheus的負(fù)載 將集群的 container類型 Prometheus上面kubelet 和 kube-state-metrics 轉(zhuǎn)移到 resource-Prometheus 上面 降低 container-Prometheus負(fù)載。（與此同時(shí)resource-Prometheus也會(huì)發(fā)送到 kafka-adapter）。且在負(fù)載低的Prometheus上 監(jiān)控跳轉(zhuǎn)面板用到的監(jiān)控指標(biāo)（核心指標(biāo)）進(jìn)行重復(fù)采集，盡可能防止數(shù)據(jù)丟失。降低了container-Prometheus 40%的負(fù)，極大的減少了Prometheus異常情況的發(fā)生。

2、減少Prometheus存儲(chǔ)數(shù)據(jù)時(shí)間

我們的第2個(gè)修改點(diǎn)在 Prometheus的數(shù)據(jù)存儲(chǔ)時(shí)間上，Prometheus的默認(rèn)存儲(chǔ)時(shí)間為2周，后續(xù)測試發(fā)現(xiàn) Prometheus的存儲(chǔ)數(shù)據(jù)時(shí)間對(duì)內(nèi)存的影響很大，且現(xiàn)在監(jiān)控?cái)?shù)據(jù)的持久化存儲(chǔ)都放在 VictoriaMetrics 上面，Prometheus存儲(chǔ)的數(shù)據(jù)主要用于排查問題，不需要承擔(dān)持久化存儲(chǔ)的任務(wù)。故我們修改Prometheus采集的數(shù)據(jù)本地存儲(chǔ)時(shí)間從7天改為2天。Prometheus 內(nèi)存消耗降低 40%。

4.2 監(jiān)控丟點(diǎn)現(xiàn)象

4.2.1 問題定位

最初我們認(rèn)為是 Prometheus 在remote_write 的過程中發(fā)生了丟點(diǎn)的情況，但是通過在社區(qū)查詢和配置問題Prometheus 遠(yuǎn)程寫相關(guān)的監(jiān)控指標(biāo)發(fā)現(xiàn)Prometheus并沒有在遠(yuǎn)程寫的時(shí)候丟棄數(shù)據(jù)，且發(fā)現(xiàn)在推送數(shù)據(jù)的過程中只有kubelet 內(nèi)置的 cAdvisor提供的數(shù)據(jù)有"丟點(diǎn)"的情況。故我們開始研究指標(biāo)提供端組件 cAdvisor，發(fā)現(xiàn)cAdvisor”丟點(diǎn)”問題的原因在于 cAdvisor組件有自己的刷新頻率 和 時(shí)間戳。cAdvisor 會(huì)去 cgroup 中讀取數(shù)據(jù)并存儲(chǔ)到內(nèi)存中供外部使用。Kubelet的cAdvisor 的刷新數(shù)據(jù)頻率達(dá)不到 10s，并且會(huì)根據(jù)刷新時(shí)間放到指標(biāo)中。而 Prometheus 按 10s 采集頻率去采集數(shù)據(jù)時(shí)，底層的 cAdvisor 如果還沒有去刷新數(shù)據(jù)，內(nèi)存中則還是上次的數(shù)據(jù)。而cAdvisor 在0.31版本及之后的版本中添加了時(shí)間戳支持，即 cadvisor 提供的數(shù)據(jù)會(huì)帶上自己的時(shí)間戳。當(dāng) Prometheus 去采集 cadviosr數(shù)據(jù)時(shí)會(huì)以 cAdvisor提供的時(shí)間戳為準(zhǔn)。故當(dāng) Prometheus 按照ServiceMonitor 設(shè)置的采集頻率10s去采集cAdvisor 提供的數(shù)據(jù)時(shí)，如果在此期間 cAdvisor 沒有進(jìn)行數(shù)據(jù)更新，則Prometheus會(huì)采集到與上次采集時(shí)間戳和值相同的情況，Prometheus 就只會(huì)記錄一條數(shù)據(jù)。這就是cAdvisor “丟點(diǎn)”的本質(zhì)。cAdvisor的刷新頻率由 housekeeping相關(guān)參數(shù) 和 抖動(dòng) 機(jī)制確定。

kubelet 內(nèi)置 cAdvisor設(shè)置的參數(shù)：

// Kubelet 內(nèi)置 cadvisor 默認(rèn)參數(shù)// cadvisor housekeeping 的間隔，刷新數(shù)據(jù)的間隔const defaultHousekeepingInterval = 10 * time.Second      // cadvisor 是否開啟動(dòng)態(tài) housekeepingconst allowDynamicHousekeeping = true                        /*cadvisor housekeeping 的最大間隔，allow_dynamic_housekeeping=true的時(shí)候, 會(huì)判斷容器活躍程度動(dòng)態(tài)的調(diào)整 HousekeepingInterval， 當(dāng)發(fā)現(xiàn)一段時(shí)間為容器狀態(tài)為發(fā)生改變會(huì)將 housekeeping 的間隔 設(shè)置為maxHousekeepingInterval 。*/const maxHousekeepingInterval = 15 * time.Second

4.2.2 解決方案

根據(jù)上面的分析，定位到無法保證指標(biāo)頻率的根本原因在于 cAdvisor 的默認(rèn)啟動(dòng)參數(shù)，而目前我們采集的cAdvisor是內(nèi)置于 kubelet 中的，如果要修改參數(shù)的話需要改動(dòng) kubelet。故綜合考慮集群穩(wěn)定性和維護(hù)成本等因素，我們決定以 daemonset 的方式部署一套cAdvisor，并根據(jù)需求設(shè)置 housekeeping 相關(guān)的參數(shù)來保證 cAdvisor 刷新數(shù)據(jù)的頻率，并設(shè)置 Prometheus 采集 cAdvisor 數(shù)據(jù)的時(shí)候忽略 cAdvisor 自帶的時(shí)間戳，即通過單獨(dú)部署的 cAdvisor 提供Pod的監(jiān)控?cái)?shù)據(jù)并保證監(jiān)控?cái)?shù)據(jù)的頻率。

我們的工作主要在部署 cAdvisor 和 修改對(duì)應(yīng)的 ServiceMonitor。

1、部署 cAdvisor：主要是確定cAdvisor啟動(dòng)參數(shù)， 主要操作為禁用dynamic_housekeeping 和 設(shè)置 housekeeping_interval 為 1s，來保證 cAdvisor 獲取數(shù)據(jù)的頻率。

containers:// 參數(shù)設(shè)置  - -allow_dynamic_housekeeping=false  - -housekeeping_interval=1s

2、創(chuàng)建對(duì)應(yīng)的ServiceMonitor讓 cAdvisor 讓Prometheus 忽略cadviosr自帶的時(shí)間戳。（因?yàn)?cadviosr自身的抖動(dòng)機(jī)制，頻率無法固定）

cAdvisor的抖動(dòng)機(jī)制：

// return jitter(cd.housekeepingInterval, 1.0)func jitter(duration time.Duration, maxFactor float64) time.Duration {if maxFactor <= 0.0 {maxFactor = 1.0}wait := duration + time.Duration(rand.Float64()*maxFactor*float64(duration))return wait}

cAdvisor的 ServiceMonitor上配置忽略指標(biāo)自帶時(shí)間戳

通過單獨(dú)部署的 cAdvisor和 Prometheus 的忽略 cAdvisor 自帶的時(shí)間戳，我們成功的解決了容器監(jiān)控?cái)帱c(diǎn)的問題，保證了監(jiān)控的頻率。

spec:  endpoints:  - honorLabels: true    // 忽略時(shí)間戳    honorTimestamps: false    interval: 10s

可以看到再去采集 1分鐘內(nèi)的容器相關(guān)監(jiān)控?cái)?shù)據(jù)，是很標(biāo)準(zhǔn)的 6 個(gè)數(shù)據(jù)點(diǎn)。至此監(jiān)控“掉點(diǎn)”問題解決。

監(jiān)控面板展示數(shù)據(jù)連續(xù)，無中斷現(xiàn)象發(fā)生。

4.3 后端數(shù)據(jù)庫負(fù)載突增

4.3.1 問題定位

從監(jiān)控架構(gòu)圖可以看到，我們使用社區(qū) v1.59.1-cluster版本的VictoriaMetrics 作為監(jiān)控后端的時(shí)序數(shù)據(jù)庫，并在Prometheus 采集的數(shù)據(jù)后通過remote_write寫入到時(shí)序數(shù)據(jù)庫VictoriaMetrics中進(jìn)行持久化存儲(chǔ)，Grafana會(huì)從VictoriaMetrics 讀取數(shù)據(jù)展示在對(duì)應(yīng)的 Dashboard上面。而在我們的實(shí)際使用中發(fā)現(xiàn)，Prometheus 遠(yuǎn)程寫入VictoriaMetrics有不定期延遲飆升的現(xiàn)象。

Prometheus寫入VictoriaMetrics延遲

寫入數(shù)據(jù)庫延遲的飆升會(huì)導(dǎo)致，監(jiān)控面板展示延時(shí)、監(jiān)控誤告警等一系列問題。

我們對(duì) VictoriaMetrics的詳細(xì)指標(biāo)進(jìn)行分析。發(fā)現(xiàn) vmstorage 組件在底層執(zhí)行 indexdb merge 操作的時(shí)候，其 CPU、內(nèi)存等資源使用量會(huì)有一個(gè)突增, 即indexdb 的 Merge 操作非常消耗資源。

4.3.2 解決方案

正是由于VictoriaMetrics 這些的資源突增，導(dǎo)致自己負(fù)載過高，無法正常響應(yīng) Prometheus的 remote_write的數(shù)據(jù)。我們所期望的是在 indexdb merge 的時(shí)候，資源使用量的增長不會(huì)影響到正常的數(shù)據(jù)插入和查詢。經(jīng)過查詢相關(guān)資源得到VictoriaMetrics在1.73.0版本中對(duì)indexdb的 merge進(jìn)行優(yōu)化,提升了整體性能。故我們對(duì)VictoriaMetrics 進(jìn)行了版本升級(jí)以優(yōu)化這個(gè)問題。在版本升級(jí)后，未發(fā)現(xiàn) VictoriaMetrics 在indexdb merge時(shí)有資源突增的情況發(fā)生。

五、總結(jié)

在Kubernetes大規(guī)模使用的今天，以 Prometheus 為核心的監(jiān)控系統(tǒng)已成為云原生監(jiān)控領(lǐng)域的事實(shí)標(biāo)準(zhǔn)。原生Prometheus沒有提供高可用和持久化存儲(chǔ)的標(biāo)準(zhǔn)方案，vivo通過自研adapter實(shí)現(xiàn)了Prometheus雙副本高可用，并將數(shù)據(jù)寫入到VictoriaMetrics中實(shí)現(xiàn)了數(shù)據(jù)的持久化存儲(chǔ)。而在業(yè)務(wù)規(guī)模的增長的過程中，監(jiān)控?cái)?shù)據(jù)量也在快速增長，對(duì)監(jiān)控采集和存儲(chǔ)組件都帶來了不小的壓力，當(dāng)前我們通過降低數(shù)據(jù)提供端指標(biāo)數(shù)量、優(yōu)化采集組件參數(shù)、升級(jí)開源存儲(chǔ)組件版本的方式，提升了監(jiān)控系統(tǒng)的性能。

而架構(gòu)的演變是隨著業(yè)務(wù)規(guī)模的增長而不斷的演變改進(jìn)的，未來我們將結(jié)合業(yè)務(wù)實(shí)際規(guī)模優(yōu)化監(jiān)控架構(gòu)提升容器監(jiān)控整體性能。后續(xù)我們規(guī)劃在監(jiān)控采集、監(jiān)控查詢、監(jiān)控?cái)?shù)據(jù)提供三個(gè)方向繼續(xù)提升提供系統(tǒng)性能：

【監(jiān)控采集】：改進(jìn)數(shù)據(jù)采集端架構(gòu)，應(yīng)用自動(dòng)分片從而降低采集端壓力?！颈O(jiān)控查詢】：應(yīng)用 PrometheusRule以降低常用查詢耗時(shí)，提升監(jiān)控查詢體驗(yàn)?！颈O(jiān)控?cái)?shù)據(jù)提供】：在exporter端降低數(shù)量從而更穩(wěn)定提供的數(shù)據(jù)。

關(guān)鍵詞：