怎么用Prometheus監(jiān)控十萬container的Kubernetes集群

這篇文章主要講解了“怎么用Prometheus監(jiān)控十萬container的Kubernetes集群”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“怎么用Prometheus監(jiān)控十萬container的Kubernetes集群”吧！

Prometheus

Prometheus依靠其強(qiáng)勁的單機(jī)性能，靈活的PromSQL，活躍的社區(qū)生態(tài)，逐漸成為云原生時(shí)代最核心的監(jiān)控組件，被全球各大產(chǎn)商用于監(jiān)控他們的核心業(yè)務(wù)。

然而，面對(duì)大規(guī)模監(jiān)控目標(biāo)（數(shù)千萬series）時(shí)，由于原生Prometheus只有單機(jī)版本，不提供集群化功能，開發(fā)人員不得不通過不斷增加機(jī)器的配置來滿足Prometheus不斷上漲的內(nèi)存。

單機(jī)性能瓶頸

我們對(duì)單機(jī)Prometheus進(jìn)行的壓測(cè)，用以探測(cè)單個(gè)Prometheus分片的合理負(fù)載，壓測(cè)的目標(biāo)有兩個(gè)。

• 確定target數(shù)目對(duì)Prometheus負(fù)載的關(guān)系

• 確定series數(shù)目和Prometheus負(fù)載的關(guān)系

target相關(guān)性

我們保持總series為100萬不變， 通過改變target個(gè)數(shù)，觀察Prometheus負(fù)載變動(dòng)。 壓測(cè)結(jié)果

• 從表中我們發(fā)現(xiàn)target數(shù)目的改動(dòng)對(duì)Prometheus負(fù)載的影響并不是強(qiáng)相關(guān)的。在target數(shù)目增長50倍的情況下，CPU消耗有小量增長，但是內(nèi)存幾乎不變。

series相關(guān)性

我們保持target數(shù)目不變，通過改變總series數(shù)，觀察Prometheus的負(fù)載變動(dòng)。

壓測(cè)結(jié)果

• 從表中，Prometheus的負(fù)載受到series的影響較大，series越多，資源消耗越大。

• 當(dāng)series數(shù)據(jù)超過300萬時(shí)，Prometheus內(nèi)存增長較為明顯，需要使用較大內(nèi)存的機(jī)器來運(yùn)行。

壓測(cè)過程中，我們使用了工具去生成預(yù)期數(shù)目的series，工具生成的series每個(gè)label的長度及值的長度都較小，固定為10個(gè)字符左右。我們的目的是觀察相對(duì)負(fù)載變化，實(shí)際生產(chǎn)中由于label長度不同，服務(wù)發(fā)現(xiàn)機(jī)制的消耗不同，相同的series數(shù)目所消耗的負(fù)載會(huì)比壓測(cè)中高不少。

現(xiàn)有集群化方案

針對(duì)單機(jī)Prometheus在大規(guī)模數(shù)據(jù)監(jiān)控時(shí)的性能瓶頸問題，社區(qū)目前已經(jīng)存在一些分片化方案，主要包括以下幾種。

hash_mod

Prometheus官方支持通過Relabel機(jī)制，在配置文件中，對(duì)采集上來的數(shù)據(jù)進(jìn)行hash，通過在不同Prometheus實(shí)例的配置文件中指定不同的moduleID來進(jìn)行分片化，然后通過聯(lián)邦，Thanos等方式將數(shù)據(jù)進(jìn)行統(tǒng)一匯總，如下圖所示，讀者也可以直接參考【官方文檔】。

配置文件分割

還有一種方法是根據(jù)業(yè)務(wù)進(jìn)行job層面的分割，不同Prometheus使用完全獨(dú)立的采集配置，其中包含了不同的job，。

上述方案存在的問題

無論是hash_mod的方式，還是配置文件分割的方式，其本質(zhì)都是將數(shù)據(jù)切分到多個(gè)采集配置中，由不同Prometheus進(jìn)行采集。兩者都存在以下幾個(gè)缺點(diǎn)。

• **對(duì)預(yù)監(jiān)控?cái)?shù)據(jù)要有所了解：**使用上述方法的前提是使用者必須對(duì)監(jiān)控對(duì)象會(huì)上報(bào)的數(shù)據(jù)有所了解，例如必須知道監(jiān)控對(duì)象會(huì)上報(bào)某個(gè)用于hash_mod的label，或者必須知道不同job的整體規(guī)模，才能對(duì)job進(jìn)行劃分。

• **實(shí)例負(fù)載不均衡：**雖然上述方案預(yù)期都是希望將數(shù)據(jù)打散到不同Prometheus實(shí)例上，但實(shí)際上通過某些label的值進(jìn)行hash_mod的，或者干脆按job進(jìn)行劃分的方式并不能保證每個(gè)實(shí)例最終所采集的series數(shù)是均衡的，實(shí)例依舊存在內(nèi)存占用過高的風(fēng)險(xiǎn)。

• **配置文件有侵入：**使用者必須對(duì)原配置文件進(jìn)行改造，加入Relabel相關(guān)配置，或者將一份配置文件劃分成多份，由于配置文件不再單一，新增，修改配置難度大大增加。

• **無法動(dòng)態(tài)擴(kuò)縮容：**上述方案中的由于配置是根據(jù)實(shí)際監(jiān)控目標(biāo)的數(shù)據(jù)規(guī)模來特殊制定的，并沒有一種統(tǒng)一的擴(kuò)縮容方案，可以在數(shù)據(jù)規(guī)模增長時(shí)增加Prometheus個(gè)數(shù)。當(dāng)然，用戶如果針對(duì)自己業(yè)務(wù)實(shí)際情況編寫擴(kuò)縮容的工具確實(shí)是可以的，但是這種方式并不能在不同業(yè)務(wù)間復(fù)用。

• **部分API不再正常：**上述方案將數(shù)據(jù)打散到了不同實(shí)例中，然后通過聯(lián)邦或者Thanos進(jìn)行匯總，得到全局監(jiān)控?cái)?shù)據(jù)，但是在不額外處理的情況下會(huì)導(dǎo)致部分Prometheus 原生API無法得到正確的值，最典型的是/api/v1/targets ，上述方案下無法得到全局targets值。

Kvass的原理

設(shè)計(jì)目標(biāo)

針對(duì)上述問題，我們希望設(shè)計(jì)一種無侵入的集群化方案，它對(duì)使用者表現(xiàn)出來的，是一個(gè)與原生Prometheus配置文件一致，API兼容，可擴(kuò)縮容的虛擬Prometheus。具體而言，我們有以下設(shè)計(jì)目標(biāo)。

• **無侵入，單配置文件：**我們希望使用者看到的，修改的都是一份原生的配置文件，不用加任何特殊的配置。

• 無需感知監(jiān)控對(duì)象：我們希望使用者不再需要預(yù)先了解采集對(duì)象，不參與集群化的過程。

• **實(shí)例負(fù)載盡可能均衡：**我們希望能根據(jù)監(jiān)控目標(biāo)的實(shí)際負(fù)載來劃分采集任務(wù)，讓實(shí)例盡可能均衡。

• **動(dòng)態(tài)擴(kuò)縮容：**我們希望系統(tǒng)能夠根據(jù)采集對(duì)象規(guī)模的變化進(jìn)行動(dòng)態(tài)擴(kuò)縮容，過程中數(shù)據(jù)不斷點(diǎn)，不缺失。

• **兼容核心PrometheusAPI：**我們希望一些較為核心的API，如上邊提到的/api/v1/target接口是正常的。

架構(gòu)

Kvass由多個(gè)組件構(gòu)成，下圖給出了Kvass的架構(gòu)圖，我們?cè)诩軜?gòu)圖中使用了Thanos，實(shí)際上Kvass并不強(qiáng)依賴于Thanos，可以換成其他TSDB。

• Kvass sidecar: 用于接收Coordinator下發(fā)的采集任務(wù)，生成新的配置文件給Prometheus，也服務(wù)維護(hù)target負(fù)載情況。

• Kvass coordinator: 該組件是集群的中心控制器，負(fù)責(zé)服務(wù)發(fā)現(xiàn)，負(fù)載探測(cè)，targets下發(fā)等。

• Thanos 組件: 圖中只使用了Thanos sidecar與Thanos query，用于對(duì)分片的數(shù)據(jù)進(jìn)行匯總，得到統(tǒng)一的數(shù)據(jù)視圖。

Coordinator

Kvass coordinaor 首先會(huì)代替Prometheus對(duì)采集目標(biāo)做服務(wù)發(fā)現(xiàn)，實(shí)時(shí)獲得需要采集的target列表。

針對(duì)這些target，Kvass coordinaor會(huì)負(fù)責(zé)對(duì)其做負(fù)載探測(cè)，評(píng)估每個(gè)target的series數(shù)，一旦target負(fù)載被探測(cè)成功，Kvass coordinaor 就會(huì)在下個(gè)計(jì)算周期將target分配給某個(gè)負(fù)載在閾值以下的分片。

Kvass coordinaor 還負(fù)責(zé)對(duì)分片集群做擴(kuò)縮容。

服務(wù)發(fā)現(xiàn)

Kvass coordinaor引用了原生Prometheus的服務(wù)發(fā)現(xiàn)代碼，用于實(shí)現(xiàn)與Prometheus 100%兼容的服務(wù)發(fā)現(xiàn)能力，針對(duì)服務(wù)發(fā)現(xiàn)得到的待抓取targets，Coordinaor會(huì)對(duì)其應(yīng)用配置文件中的relabel_configs進(jìn)行處理，得到處理之后的targets及其label集合。服務(wù)發(fā)現(xiàn)后得到的target被送往負(fù)載探測(cè)模塊進(jìn)行負(fù)載探測(cè)。

負(fù)載探測(cè)

負(fù)載探測(cè)模塊從服務(wù)發(fā)現(xiàn)模塊獲得處理之后的targets，結(jié)合配置文件中的抓取配置（如proxy，證書等）對(duì)目標(biāo)進(jìn)行抓取，隨后解析計(jì)算抓取結(jié)果，獲得target的series規(guī)模。

負(fù)載探測(cè)模塊并不存儲(chǔ)任何抓取到的指標(biāo)數(shù)據(jù)，只記錄target的負(fù)載，負(fù)載探測(cè)只對(duì)target探測(cè)一次，不維護(hù)后續(xù)target的負(fù)載變化，長期運(yùn)行的target的負(fù)載信息由Sidecar維護(hù)，我們將在后面章節(jié)介紹。

target分配與擴(kuò)容

在Prometheus單機(jī)性能瓶頸那一節(jié)，我們介紹過Prometheus的內(nèi)存和series相關(guān)，確切來說，Prometheus的內(nèi)存和其head series直接相關(guān)。Prometheus 會(huì)將最近（默認(rèn)為2小時(shí)）采集到的數(shù)據(jù)的series信息緩存在內(nèi)存中，我們?nèi)绻芸刂坪妹總€(gè)分片內(nèi)存中head series的數(shù)目，就能有效控制每個(gè)分片的內(nèi)存使用量，而控制head series實(shí)際就是控制分片當(dāng)前采集的target列表。

基于上邊的思路，Kvass coordinaor會(huì)周期性的對(duì)每個(gè)分片當(dāng)前采集的target列表進(jìn)行管理：分配新target，刪除無效target。

在每個(gè)周期，Coordinaor會(huì)首先從所有分片獲得當(dāng)前運(yùn)行狀態(tài)，其中包括分片當(dāng)前內(nèi)存中的series數(shù)目及當(dāng)前正在抓取的target列表。隨后針對(duì)從服務(wù)發(fā)現(xiàn)模塊得到的全局target信息進(jìn)行以下處理

• 如果該target已經(jīng)被某個(gè)分片抓取，則繼續(xù)分配給他，分片的series數(shù)不變。

• 如果該target沒有任何分片抓取，則從負(fù)載探測(cè)模塊獲得其series（如果還未探測(cè)完則跳過，下個(gè)周期繼續(xù)），從分片中挑一個(gè)目前內(nèi)存中series加上該target的series后依然比閾值低的，分配給他。

• 如果當(dāng)前所有分片沒法容納所有待分配的targets，則進(jìn)行擴(kuò)容，擴(kuò)容數(shù)量與全局series總量成正比。

target遷移和縮容

在系統(tǒng)運(yùn)行過程中，target有可能會(huì)被刪除，如果某個(gè)分片的target被刪除且超過2小時(shí)，則該分片中的head series就會(huì)降低，也就是出現(xiàn)了部分空閑，因?yàn)閠arget分配到了不同分片，如果有大量target被刪除，則會(huì)出現(xiàn)很多分片的內(nèi)存占用都很低的情況，這種情況下，系統(tǒng)的資源利用率很低，我們需要對(duì)系統(tǒng)進(jìn)行縮容。

當(dāng)出現(xiàn)這種情時(shí)，Coordinaor會(huì)對(duì)target進(jìn)行遷移，即將序號(hào)更大的分片（分片會(huì)從0進(jìn)行編號(hào)）中的target轉(zhuǎn)移到序號(hào)更低的分片中，最終讓序號(hào)低的分片負(fù)載變高，讓序號(hào)高的分片完全空閑出來。如果存儲(chǔ)使用了thanos，并會(huì)將數(shù)據(jù)存儲(chǔ)到cos中，則空閑分片在經(jīng)過2小時(shí)候會(huì)刪除（確保數(shù)據(jù)已被傳到cos中）。

多副本

Kvass的分片當(dāng)前只支持以StatefulSet方式部署。

Coordinator將通過label selector來獲得所有分片StatefulSet，每個(gè)StatefulSet被認(rèn)為是一個(gè)副本，StatefulSet中編號(hào)相同的Pod會(huì)被認(rèn)為是同一個(gè)分片組，相同分片組的Pod將被分配相同的target并預(yù)期有相同的負(fù)載。

/api/v1/targets接口

上文提到Coordinator根據(jù)配置文件做了服務(wù)發(fā)現(xiàn)，得到了target列表，所以Coordinator實(shí)際上可以得到/api/v1/targets接口所需要的返回結(jié)果集合，但是由于Coordinator只做了服務(wù)發(fā)現(xiàn)，并不進(jìn)行實(shí)際采集，所以target的采集狀態(tài)（例如健康狀態(tài)，上一次采集時(shí)間等）都無法直接得知。

當(dāng)Coordinator接收到/api/v1/targets請(qǐng)求時(shí)，他會(huì)基于服務(wù)發(fā)現(xiàn)得到的target集合，結(jié)合向Sidecar（如果target已分配）或向探測(cè)模塊（target還未分配）詢問target采集狀態(tài)，綜合后將正確的/api/v1/targets結(jié)果返回。

Sidecar

上一節(jié)介紹了Kvass coordinaor的基本功能，要想系統(tǒng)正常運(yùn)行，還需要Kvass sidecar的配合，其核心思想是將配置文件中所有服務(wù)發(fā)現(xiàn)模式全部改成static_configs并直接將已經(jīng)relabel過的target信息寫入配置中，來達(dá)到消除分片服務(wù)發(fā)現(xiàn)和relabel行為，只采集部分target的效果。

每個(gè)分片都會(huì)有一個(gè)Kvass sidecar，其核心功能包括從Kvass coordinator接受本分片負(fù)責(zé)的target列表，生成新的配置文件給該分片的Prometheus使用。另外，Kvass sidecar還會(huì)劫持抓取請(qǐng)求，維護(hù)target最新負(fù)載。Kvass sidecar還作為PrometheusAPI的網(wǎng)關(guān)，修正部分請(qǐng)求結(jié)果。

配置文件生成

Coordinaor經(jīng)過服務(wù)發(fā)現(xiàn)，relabel及負(fù)載探測(cè)后，會(huì)將target分配給某個(gè)分片，并將target信息下發(fā)給Sidecar，包括

• target的地址，

• target預(yù)估的series值

• target的hash值

• 處理完relabel之后的label集合。

Sidecar根據(jù)從Coordinator得到的target信息，結(jié)合原始配置文件，生成一個(gè)新的配置文件給Prometheus使用，這個(gè)新的配置文件做了如下改動(dòng)。

• 將所有服務(wù)發(fā)現(xiàn)機(jī)制改為static_configs模式，并直接寫入target列表，每個(gè)target包含經(jīng)過relabel之后的label值

• 由于現(xiàn)在target已經(jīng)relabel過了，所以刪除job配置中的relabel_configs項(xiàng)，但是依舊保留metrics_rebale_configs

• 將target的label中的scheme字段全部替換成http，并將原schme以請(qǐng)求參數(shù)的形式加入到label集合中

• 將target的job_name以請(qǐng)求參數(shù)的形式加入到label集合中* 注入proxy_url將所有抓取請(qǐng)求代理到Sidecar

我們來看一個(gè)例子，假如原來的配置是一個(gè)kubelet的采集配置

global:
  evaluation_interval: 30s
  scrape_interval: 15s
scrape_configs:
- job_name: kubelet
  honor_timestamps: true
  metrics_path: /metrics
  scheme: https
  kubernetes_sd_configs:
  - role: node
  bearer_token: xxx
  tls_config:
    insecure_skip_verify: true
  relabel_configs:
  - separator: ;
    regex: __meta_kubernetes_node_label_(.+)
    replacement: $1
    action: labelmap

通過注入將生成一個(gè)新的配置文件

global:
  evaluation_interval: 30s
  scrape_interval: 15s
scrape_configs:
- job_name: kubelet                                        
  honor_timestamps: true                                                                      
  metrics_path: /metrics                                   
  scheme: https  
  proxy_url: http://127.0.0.1:8008 # 所有抓取請(qǐng)求代理到Sidecar
  static_configs:                                          
  - targets:                                               
    - 111.111.111.111:10250                                   
    labels:                                                
      __address__: 111.111.111.111:10250                      
      __metrics_path__: /metrics                           
      __param__hash: "15696628886240206341"                
      __param__jobName: kubelet                            
      __param__scheme: https  # 保存原始的scheme                             
      __scheme__: http        # 設(shè)置新的scheme，這將使得代理到Sidecar的抓取請(qǐng)求都是http請(qǐng)求
      # 以下是經(jīng)過relabel_configs處理之后得到的label集合
      beta_kubernetes_io_arch: amd64                       
      beta_kubernetes_io_instance_type: QCLOUD             
      beta_kubernetes_io_os: linux                         
      cloud_tencent_com_auto_scaling_group_id: asg-b4pwdxq5
      cloud_tencent_com_node_instance_id: ins-q0toknxf     
      failure_domain_beta_kubernetes_io_region: sh         
      failure_domain_beta_kubernetes_io_zone: "200003"     
      instance: 172.18.1.106                               
      job: kubelet                                         
      kubernetes_io_arch: amd64                            
      kubernetes_io_hostname: 172.18.1.106                 
      kubernetes_io_os: linux

上邊新生成的配置文件是Prometheus真正使用的配置文件，Sidecar通過Coordinator下發(fā)的target列表來生成配置，就可以讓Prometheus有選擇性得進(jìn)行采集。

抓取劫持

在上邊的配置生成中，我們會(huì)將proxy注入到j(luò)ob的配置中，并且target的label中，scheme會(huì)被設(shè)置成http，所以Prometheus所有的抓取請(qǐng)求都會(huì)被代理到Sidecar，之所以要這么做，是因?yàn)镾idecar需要維護(hù)每個(gè)target新的series規(guī)模，用于Coordinator查閱后作為target遷移的參考。

從上邊配置生成我們可以看到，有以下幾個(gè)額外的請(qǐng)求參數(shù)會(huì)被一并發(fā)送到Sidecar

• hash：target的hash值，用于Sidecar識(shí)別是哪個(gè)target的抓取請(qǐng)求，hash值由Coordinator根據(jù)target的label集合進(jìn)行計(jì)算獲得并傳遞給Sidecar。

• jobName：是哪個(gè)job下的抓取請(qǐng)求，用于Sidecar根據(jù)原配置文件中job的請(qǐng)求配置（如原proxy_url，證書等）對(duì)抓取目標(biāo)發(fā)起真正的請(qǐng)求。

• scheme：這里的scheme是target通過relabel操作之后最終得到的協(xié)議值，雖然在job配置文件中已經(jīng)有scheme字段，但Prometheus配置文件依舊支持通過relabel指定某個(gè)target的請(qǐng)求協(xié)議。在上述生成新配置過程中，我們將真實(shí)的scheme保存到這個(gè)參數(shù)里，然后將scheme全部設(shè)置成http。

有了上述幾個(gè)參數(shù)，Sidecar就可以對(duì)抓取目標(biāo)發(fā)起正確的請(qǐng)求，并得到監(jiān)控?cái)?shù)據(jù)，在統(tǒng)計(jì)的target這次抓取的series規(guī)模后，Sidecar會(huì)將監(jiān)控?cái)?shù)據(jù)拷貝一份給Prometheus。

API代理

由于Sidecar的存在，部分發(fā)往Prometheus的API請(qǐng)求需要被特殊處理，包括

• /-/reload：由于Prometheus真正使用的配置文件由Sidecar生成，針對(duì)該接口，需要由Sidecar去處理并在處理成功后調(diào)用Prometheus的/-/reload接口。

• /api/v1/status/config：該接口需要由Sidecar處理并把原配置文件返回。

• 其他接口直接發(fā)往Prometheus。

全局?jǐn)?shù)據(jù)視圖

由于我們將采集目標(biāo)分散到了不同分片中，導(dǎo)致每個(gè)分片的數(shù)據(jù)都只是全局?jǐn)?shù)據(jù)的一部分，所以我們需要使用額外的組件來將所有數(shù)據(jù)進(jìn)行匯總并去重（多副本的情況下），得到全局?jǐn)?shù)據(jù)視圖。

以thanos為例

thanos是一個(gè)非常好的方案，通過加入thanos組件，可以很方便得得到kvass集群的全局?jǐn)?shù)據(jù)視圖。當(dāng)然我們也可以通過加入remote writer配置來使用其他TSDB方案，例如influxdb，M3等等。

使用例子

這一節(jié)我們通過一個(gè)部署例子，來直觀感受一下Kvass的效果，相關(guān)yaml文件可以在這里找到https://github.com/tkestack/kvass/tree/master/examples 讀者可以將項(xiàng)目clone到本地，并進(jìn)入examples。

git clone https://github.com/tkestack/kvass.git
cd kvass/examples

部署數(shù)據(jù)生成器

我們提供了一個(gè)metrics數(shù)據(jù)生成器，可以指定生成一定數(shù)量的series，在本例子中，我們將部署6個(gè)metrics生成器副本，每個(gè)會(huì)生成10045 series (其中45 series為golang的metrics)。

kubectl create -f  metrics.yaml

部署kvass

現(xiàn)在我們部署基于Kvass的Prometheus集群，用以采集這6個(gè)metrics生成器的指標(biāo)。

首先我們部署rbac相關(guān)配置

kubectl create -f kvass-rbac.yaml

接著部署一個(gè)Prometheus config文件，這個(gè)文件就是我們的原始配置，我們?cè)谶@個(gè)配置文件中，使用kubernetes_sd來做服務(wù)發(fā)現(xiàn)

kubectl create -f config.yaml

配置如下

global:
  scrape_interval: 15s
  evaluation_interval: 15s
  external_labels:
    cluster: custom
scrape_configs:
- job_name: 'metrics-test'
  kubernetes_sd_configs:
    - role: pod
  relabel_configs:
  - source_labels: [__meta_kubernetes_pod_label_app_kubernetes_io_name]
    regex: metrics
    action: keep
  - source_labels: [__meta_kubernetes_pod_ip]
    action: replace
    regex: (.*)
    replacement: ${1}:9091
    target_label: __address__
  - source_labels:
    - __meta_kubernetes_pod_name
    target_label: pod

現(xiàn)在我們來部署Kvass coordinator

kubectl create -f coordinator.yaml

我們?cè)贑oordinator的啟動(dòng)參數(shù)中設(shè)置每個(gè)分片的最大head series數(shù)目不超過30000

--shard.max-series=30000

我們現(xiàn)在就可以部署帶有Kvass sidecar的Prometheus了，這里我們只部署單個(gè)副本

kubectl create -f prometheus-rep-0.yaml

部署thanos-query

為了得到全局?jǐn)?shù)據(jù)，我們需要部署一個(gè)thanos-query

kubectl create -f thanos-query.yaml

查看結(jié)果

根據(jù)上述計(jì)算，監(jiān)控目標(biāo)總計(jì)6個(gè)target, 60270 series，根據(jù)我們?cè)O(shè)置每個(gè)分片不能超過30000 series，則預(yù)期需要3個(gè)分片。

我們發(fā)現(xiàn)，Coordinator成功將StatefulSet的副本數(shù)改成了3。

我們看下單個(gè)分片內(nèi)存中的series數(shù)目，發(fā)現(xiàn)只有2個(gè)target的量

我們?cè)偻ㄟ^thanos-query來查看全局?jǐn)?shù)據(jù)，發(fā)現(xiàn)數(shù)據(jù)是完整的（其中metrics0為指標(biāo)生成器生成的指標(biāo)名）

云原生監(jiān)控

騰訊云容器團(tuán)隊(duì)在Kvass的設(shè)計(jì)思想上進(jìn)一步優(yōu)化，構(gòu)建了高性能支持多集群云原生監(jiān)控服務(wù)，產(chǎn)品目前已正式公測(cè)。

大集群監(jiān)控

這一節(jié)我們就直接使用云原生監(jiān)控服務(wù)來監(jiān)控一個(gè)規(guī)模較大的真實(shí)集群，測(cè)試一下Kvass監(jiān)控大集群的能力。

集群規(guī)模

我們關(guān)聯(lián)的集群規(guī)模大致如下

• 1060個(gè)節(jié)點(diǎn)

• 64000+ Pod

• 96000+ container

采集配置

我們直接使用云原生監(jiān)控服務(wù)在關(guān)聯(lián)集群默認(rèn)添加的采集配置，目前已包含了社區(qū)主流的監(jiān)控指標(biāo)：

• kube-state-metrics

• node-exporer

• kubelet

• cadvisor

• kube-apiserver

• kube-scheduler

• kube-controler-manager

測(cè)試結(jié)果

• 總計(jì)3400+target, 2700+萬series

• 總計(jì)擴(kuò)容了17個(gè)分片

• 每個(gè)分片series穩(wěn)定在200w以下

• 每個(gè)分片消耗內(nèi)存在6-10G左右

云原生監(jiān)控所提供的默認(rèn)Grafana面板也能正常拉取

targets列表也能正常拉取

多集群監(jiān)控

值得一提的是，云原生監(jiān)控服務(wù)不僅支持監(jiān)控單個(gè)大規(guī)模集群，還可以用同個(gè)實(shí)例監(jiān)控多個(gè)集群，并支持采集和告警模板功能，可一鍵將采集告警模板下發(fā)至各地域各個(gè)集群，徹底告別了每個(gè)集群重復(fù)添加配置的問題。

感謝各位的閱讀，以上就是“怎么用Prometheus監(jiān)控十萬container的Kubernetes集群”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)怎么用Prometheus監(jiān)控十萬container的Kubernetes集群這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！