vivo 容器集群監(jiān)控系統(tǒng)優(yōu)化之道
一、背景介紹
隨著vivo業(yè)務(wù)遷移到容器平臺(tái)，vivo云原生監(jiān)控體系面臨著指標(biāo)量快速上漲帶來(lái)的一系列挑戰(zhàn)，本文將分享vivo 容器化項(xiàng)目中容器監(jiān)控遇到的問(wèn)題以及我們的解決和優(yōu)化方法。
二、監(jiān)控架構(gòu)
首先對(duì)vivo容器監(jiān)控架構(gòu)進(jìn)行一個(gè)簡(jiǎn)單的介紹。
- 【架構(gòu)高可用】：集群維度的雙副本 Prometheus 采集底層exporter數(shù)據(jù)，adapter多實(shí)例自動(dòng)選主實(shí)現(xiàn)容災(zāi)。
- 【數(shù)據(jù)持久化】：通過(guò)remoteWrite將數(shù)據(jù)存儲(chǔ)到后端的VictoriaMetrics中進(jìn)行持久化存儲(chǔ)，Grafana使用VictoriaMetrics做為數(shù)據(jù)源展示和告警。
- 【監(jiān)控統(tǒng)一化】：通過(guò)remoteWrite將數(shù)據(jù)交由kafka-adapter轉(zhuǎn)發(fā)到Kafka，由公司基礎(chǔ)監(jiān)控等服務(wù)通過(guò)消費(fèi)Kafka中的數(shù)據(jù)來(lái)進(jìn)行展示和告警。
原生Prometheus沒(méi)有提供高可用的標(biāo)準(zhǔn)方案，我們通過(guò)自研 Adapter “分組選舉”方式實(shí)現(xiàn)去重，即每個(gè) Prometheus 副本對(duì)應(yīng)一組 Adapter，兩組 Adapter 之間會(huì)進(jìn)行選主，只有Leader組的 Adapter才會(huì)轉(zhuǎn)發(fā)數(shù)據(jù)。通過(guò)這種方式既實(shí)現(xiàn)了去重，也實(shí)現(xiàn)了Prometheus雙副本高可用。
三、問(wèn)題現(xiàn)象
過(guò)去幾年來(lái)，vivo容器化服務(wù)快速增長(zhǎng)，監(jiān)控流量上漲數(shù)倍，我們主要遇到如下三個(gè)問(wèn)題：監(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ù)的快速增長(zhǎng)，導(dǎo)致監(jiān)控 Prometheus、VictoriaMetrics 負(fù)載快速增高，給我們?nèi)萜鞅O(jiān)控帶來(lái)極大的挑戰(zhàn)。監(jiān)控總時(shí)間序列可以精簡(jiǎn)為以下的表達(dá)式，即與 Pod數(shù)量、Pod指標(biāo)量、指標(biāo)Label維度數(shù)量呈線性關(guān)系：
TotalSeries = PodNum * PerPodMetrics * PerLabelCount
而隨著集群規(guī)模的不斷增加以及容器數(shù)量的不斷增多，監(jiān)控序列就會(huì)快速增長(zhǎng)，同時(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ù)則通過(guò)自研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ù)中頻率無(wú)法做到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ù)庫(kù)來(lái)持久化存儲(chǔ)監(jiān)控?cái)?shù)據(jù)。在使用過(guò)程中發(fā)現(xiàn) VictoriaMetrics的負(fù)載有不定期增高的情況，而后端數(shù)據(jù)庫(kù)的延遲會(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è)介紹：
上圖是Prometheus-Operator官方提供的架構(gòu)圖，下面來(lái)介紹下圖中各組件:
- 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 也可以通過(guò) labelSelector 去匹配多個(gè)ServiceMonitor。
- ServiceMonitor：ServiceMonitor就是exporter的各種抽象，exporter是用來(lái)提供專門提供metrics數(shù)據(jù)接口的服務(wù)。Prometheus就是通過(guò)ServiceMonitor提供的metrics數(shù)據(jù)接口去 pull 數(shù)據(jù)的。該資源通過(guò) Labels 來(lái)選取對(duì)應(yīng)的 Service Endpoint，讓 Prometheus Server 通過(guò)選取的 Service 來(lái)獲取 Metrics 信息。一個(gè) ServiceMonitor 可以通過(guò) labelSelector 的方式去匹配一類 Service。
- Service：Service是Kubernetes內(nèi)建資源用于把一組擁有相同功能的Pod封裝起來(lái)，并提供一個(gè)統(tǒng)一的入口來(lái)暴露這組Pod的服務(wù)，從而為客戶端訪問(wèn)提供了一個(gè)穩(wěn)定的訪問(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)過(guò)濾，指標(biāo)中l(wèi)abel重命名等等操作。
對(duì)于監(jiān)控組件負(fù)載快速升高問(wèn)題的解決，我們主要從兩個(gè)方面著手，分別是指標(biāo)治理以及性能優(yōu)化。
圖片
4.1.1 指標(biāo)治理
1、過(guò)濾未使用指標(biāo)
第一個(gè)工作是過(guò)濾無(wú)用指標(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采集過(guò)來(lái)我們又沒(méi)有用到的指標(biāo)就會(huì)浪費(fèi)資源并降低監(jiān)控系統(tǒng)的穩(wěn)定性。因此我們需要對(duì)Prometheus 采集到的指標(biāo)進(jìn)行一定程度的過(guò)濾，從而減少資源的占用。
通過(guò)Prometheus提供的
scrape_samples_scraped指標(biāo)對(duì)采集的 target進(jìn)行分析找到采集樣本量大的Target。
我們進(jìn)行指標(biāo)過(guò)濾主要就是關(guān)注這些數(shù)據(jù)量大的 target，在進(jìn)行指標(biāo)過(guò)濾之前需要收集 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ì)過(guò)濾掉我們不需要的指標(biāo)。下面就是過(guò)濾 cAdvisor這個(gè) target 的 container_threads 開(kāi)頭的指標(biāo)的示例。
# 過(guò)濾 container_threads 開(kāi)頭的指標(biāo)
- action: drop
regex: container_threads(.*)
sourceLabels:
- __name__完成指標(biāo)精簡(jiǎn)后，監(jiān)控單次采集樣本量從 1000萬(wàn)降低到 250萬(wàn)。Prometheus 的CPU 使用量降低 70% ，內(nèi)存 使用量降低 55%。
2、過(guò)濾低優(yōu)先級(jí) pod 相關(guān)指標(biāo)
對(duì)精簡(jiǎn)后的指標(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è)精簡(jiǎn)，不收集這些 Pod的 memory、cpu 等容器監(jiān)控指標(biāo)。
一個(gè) Daemonset 提供的 Pod 的 Namespace 是相同的，且Pod名稱前綴相同。
# 名稱為cadvisor的 daemonset 提供的 pod
cadvisor-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"}所以我們通過(guò)在 ServiceMonitor 上面組合指標(biāo)的 pod 和 namespace，并與指定的規(guī)則進(jìn)行匹配丟棄掉我們不需要的 daemonset pod 的序列。
# 過(guò)濾掉 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)行過(guò)濾后。
對(duì) cAdvisor 的單次采集數(shù)據(jù)量下降 70%。效果十分明顯。
4.1.2 性能優(yōu)化
1、均衡 Prometheus 負(fù)載
vivo 容器監(jiān)控架構(gòu)中最核心的組件就是 Prometheus了，而 Prometheus 也是日常出現(xiàn)問(wèn)題最多的一個(gè)組件，因?yàn)?Prometheus 不僅是需要采集數(shù)據(jù),還需要將數(shù)據(jù)通過(guò)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ù)測(cè)試發(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ù)主要用于排查問(wèn)題，不需要承擔(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 問(wèn)題定位
最初我們認(rèn)為是 Prometheus 在remote_write 的過(guò)程中發(fā)生了丟點(diǎn)的情況，但是通過(guò)在社區(qū)查詢和配置問(wèn)題Prometheus 遠(yuǎn)程寫相關(guān)的監(jiān)控指標(biāo)發(fā)現(xiàn)Prometheus并沒(méi)有在遠(yuǎn)程寫的時(shí)候丟棄數(shù)據(jù)，且發(fā)現(xiàn)在推送數(shù)據(jù)的過(guò)程中只有kubelet 內(nèi)置的 cAdvisor提供的數(shù)據(jù)有"丟點(diǎn)"的情況。 故我們開(kāi)始研究指標(biāo)提供端組件 cAdvisor，發(fā)現(xiàn)cAdvisor”丟點(diǎn)”問(wè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 如果還沒(méi)有去刷新數(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 沒(méi)有進(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 是否開(kāi)啟動(dòng)態(tài) housekeeping
const 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.Second4.2.2 解決方案
根據(jù)上面的分析，定位到無(wú)法保證指標(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ù)來(lái)保證 cAdvisor 刷新數(shù)據(jù)的頻率，并設(shè)置 Prometheus 采集 cAdvisor 數(shù)據(jù)的時(shí)候忽略 cAdvisor 自帶的時(shí)間戳，即通過(guò)單獨(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，來(lái)保證 cAdvisor 獲取數(shù)據(jù)的頻率。
containers:// 參數(shù)設(shè)置
- -allow_dynamic_housekeeping=false
- -housekeeping_interval=1s2、創(chuàng)建對(duì)應(yīng)的ServiceMonitor 讓 cAdvisor 讓Prometheus 忽略cadviosr自帶的時(shí)間戳。（因?yàn)?cadviosr自身的抖動(dòng)機(jī)制，頻率無(wú)法固定）
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í)間戳
通過(guò)單獨(dú)部署的 cAdvisor和 Prometheus 的忽略 cAdvisor 自帶的時(shí)間戳，我們成功的解決了容器監(jiān)控?cái)帱c(diǎn)的問(wè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)”問(wèn)題解決。
監(jiān)控面板展示數(shù)據(jù)連續(xù)，無(wú)中斷現(xiàn)象發(fā)生。
4.3 后端數(shù)據(jù)庫(kù)負(fù)載突增
4.3.1 問(wèn)題定位
從監(jiān)控架構(gòu)圖可以看到，我們使用社區(qū) v1.59.1-cluster版本的VictoriaMetrics 作為監(jiān)控后端的時(shí)序數(shù)據(jù)庫(kù)，并在Prometheus 采集的數(shù)據(jù)后通過(guò)remote_write寫入到時(shí)序數(shù)據(jù)庫(kù)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ù)庫(kù)延遲的飆升會(huì)導(dǎo)致，監(jiān)控面板展示延時(shí)、監(jiān)控誤告警等一系列問(wè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ù)載過(guò)高，無(wú)法正常響應(yīng) Prometheus的 remote_write的數(shù)據(jù)。我們所期望的是在 indexdb merge 的時(shí)候，資源使用量的增長(zhǎng)不會(huì)影響到正常的數(shù)據(jù)插入和查詢。經(jīng)過(guò)查詢相關(guān)資源得到VictoriaMetrics在1.73.0版本中對(duì)indexdb的 merge進(jìn)行優(yōu)化,提升了整體性能。故我們對(duì)VictoriaMetrics 進(jìn)行了版本升級(jí)以優(yōu)化這個(gè)問(wèn)題。在版本升級(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沒(méi)有提供高可用和持久化存儲(chǔ)的標(biāo)準(zhǔn)方案，vivo通過(guò)自研adapter實(shí)現(xiàn)了Prometheus雙副本高可用，并將數(shù)據(jù)寫入到VictoriaMetrics中實(shí)現(xiàn)了數(shù)據(jù)的持久化存儲(chǔ)。而在業(yè)務(wù)規(guī)模的增長(zhǎng)的過(guò)程中，監(jiān)控?cái)?shù)據(jù)量也在快速增長(zhǎng)，對(duì)監(jiān)控采集和存儲(chǔ)組件都帶來(lái)了不小的壓力，當(dāng)前我們通過(guò)降低數(shù)據(jù)提供端指標(biāo)數(shù)量、優(yōu)化采集組件參數(shù)、升級(jí)開(kāi)源存儲(chǔ)組件版本的方式，提升了監(jiān)控系統(tǒng)的性能。
而架構(gòu)的演變是隨著業(yè)務(wù)規(guī)模的增長(zhǎng)而不斷的演變改進(jìn)的，未來(lái)我們將結(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)分片從而降低采集端壓力。
- 【監(jiān)控查詢】：應(yīng)用 PrometheusRule以降低常用查詢耗時(shí)，提升監(jiān)控查詢體驗(yàn)。
- 【監(jiān)控?cái)?shù)據(jù)提供】：在exporter端降低數(shù)量從而更穩(wěn)定提供的數(shù)據(jù)。
