深入Prometheus設計

本次讀後感來自于《深入淺出Prometheus：原理、應用、源碼與拓展詳解》

書籍連結https://item.jd.com/12573580.html

一 名額含義

Prometheus的所有監控名額（Metric）被統一定義為

名額定義涉及名額名稱和标簽這兩部分

1.名額名稱（metric name）

名額名稱用于說明名額的含義，例如http_request_total代表HTTP的請求總數。名額名稱必須由字面、數值下畫線或者冒号組成，符合正規表達式[a-zA-Z_:][a-zA-Z0-9_:]*，其中的冒号名額不能用于exporter。

2.标簽（label）

标簽可展現名額的次元特征，用于過濾和聚合。它通過标簽名（label name）和标簽值（label value）這種鍵值對的形式，形成多種次元。例如，對于名額 http_request_total，可以有{status=“200”,method=“POST”}和{status=“200”,method=“GET”}這兩個标簽。在需要分别擷取GET和POST傳回200的請求時，可分别使用上述兩種名額；在需要擷取所有傳回200的請求時，可以通過http_request_total{status=“200”}完成資料的聚合，非常便捷和通用。名額的某些标簽是以“__”開頭的，這些标簽是在Prometheus系統内部使用的。在形式上，http_request_total{status=“200”} 和{name=“http_request_total”,status=“200”}代表相同的名額。Prometheus名額采用标簽的方式能夠很好地與容器結合，無論是原生Docker還是Kubernetes，都通過标簽關聯資源。

二 名額分類

Prometheus名額分為Counter（計數器）、Gauge（儀表盤）、Histogram（直方圖）和Summary（摘要）這4類

1.Counter

Counter是計數器類型，它的特點是隻增不減，例如機器啟動時間、HTTP通路量等。

Counter 具有很好的不相關性，不會因為機器重新開機而置0。我們在使用 Counter名額時，通常會結合 rate()方法擷取該名額在某個時間段的變化率，例如，“HTTP請求總量”名額就屬于典型的Counter名額，通過對它進行rate()操作，可以得出請求的變化率

2.Gauge

Gauge是儀表盤，表征名額的實時變化情況，可增可減，例如CPU和記憶體的使用量、網絡 I/O 大小等，大部分監控資料都是 Gauge 類型的。如圖2-3所示是記憶體使用量監控圖，記憶體使用量随着時間的推移不斷變化

3.Summary

Summary 同 Histogram 一樣，都屬于進階名額，用于凸顯資料的分布狀況。如果需要了解某個時間段内請求的響應時間，則通常使用平均響應時間，但這樣做無法展現資料的長尾效應。例如，一個HTTP伺服器的正常響應時間是30ms，但有很少幾次請求耗時3s，通過平均響應時間很難甄别長尾效應，這時可以通過Histogram或者Summary展現。

Histogram和Summary這兩種名額類型在本質上是可以互相轉化的。這裡先了解一下資料分位：φ代表分位數，0≤φ≤1，分位數是在N個觀測值中按數量φ·N排序的觀測值。

例如，0.9分位數代表第90%位置上的數，如果總數是100個，那麼将是第90個數。Summary是采樣點分位圖統計，用于得到資料的分布情況。

例如，如果在要統計的班級中，有90%學生的成績低于93分，有95%學生的成績低于96分，則采用Summary能夠更好地展示資料的分布情況。

我們可以将Summary看作用戶端分位，它的優勢是無須消耗服務端資源，但缺點也很明顯：首先，與 Histogram 采用 Counter 計數器統計的方式相比，Summary會消耗更多的資源；其次，通過Summary計算的名額不能再擷取平均數或者關聯其他名額等，是以Summary名額一般隻适用于獨立的監控名額，例如垃圾回收時間等。

4.Histogram

Histogram反映了某個區間内的樣本個數，通過{le=“上邊界”}指定這個範圍内的樣本數。Prometheus中表示每個本地存儲序列儲存的chunk數量的名額prometheus_local_storage_series_chunks_persisted就屬于Histogram名額類型

三 資料采集

和采用Push方式采集監控資料不同，Prometheus采用 Pull方式采集監控資料。這兩種監控資料采集方式各有優缺點：采用Push方式時，Agent主動上報資料，采用Pull方式時，監控中心（Master）拉取 Agent的資料。其主要差別在于 Agent和Master的主動、被動關系

為了相容 Push方式，Prometheus 提供了 Pushgateway元件。Pushgateway元件接收用戶端發送過來的資料，按照 Job 和 Instance 兩個層級進行組織，支援資料的追加和删除，并且為防止資料丢失，還支援本地存儲。

1.實時性

Push方式的實時性相對較好，可以将采集資料立即上報到監控中心。Pull 方式通常進行周期性采集，采集時間為30s 或者更長時間。是以，如果對監控系統的實時性要求非常高，則建議采用Push方式。

2.狀态儲存

Push 方式通常在采集完成後立即上報，本地不會儲存采集資料，Agent 本身是沒有狀态的，而Master需要維護各種Agent狀态。Pull 方式正好相反，Agent 本身需要有一定的資料存儲能力，Master 隻負責簡單的資料拉取，而且Master本身可以做到無狀态。

3.控制能力

采用Push方式時，控制方為Agent,Agent上報的資料決定了上報的周期和内容。采用Pull方式時，Master更加主動，控制采集的内容和頻率。

4.配置的複雜性

采用Push方式時，通常每個 Agent都需要配置Master的位址。采用Pull方式時，通常通過批量配置或者自動發現來擷取所有采集點，相對簡單，并且可以做到和 Agent充分解耦，Agent可以不用感覺Master的存在

四 服務發現

靜态檔案配置和動态發現

1.靜态檔案配置

靜态檔案配置是一種傳統的服務發現方式，一般适用于有固定的監控環境、IP位址和統一的服務接口的場景，需要在配置中指定采集的目标。

例如，指定采集本地8080端口的Agent資料的代碼如下：

scrape_configs:
  # The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
  - job_name: 'prometheus'

    # metrics_path defaults to '/metrics'
    # scheme defaults to 'http'.

    static_configs:
    - targets: ['localhost:8080']
           

如上代碼表示監控對象的位址是10.10.10.10，端口是8080,Prometheus會周期性地調用這個監控對象（10.10.10.10:8080），但如果服務發生遷移、變更，以及更換位址或者端口，就需要重新修改配置檔案并通知Prometheus重新加載配置檔案。

為了應對監控對象的變化，Prometheus提供了動态發現方式來擷取監控對象

2.動态發現

在雲環境下，靜态配置方式很難應對雲資源動态變化的場景，比如下面兩個場景。

• 動态伸縮場景。根據負載的高低，動态建立或者銷毀資源，這裡的資源包括虛拟機、容器及關聯的資源，這些動态建立的資源很難被運維人員追蹤并且加入Prometheus監控或者從監控中剔除。随着DevOps的不斷推行，應用不斷更新、疊代、上線，一天可能釋出多次，每次都可能釋出到不同的機器，這都需要一種動态發現機制。

• 迅速配置場景。在一個Kubernetes叢集中可能需要在幾分鐘内拉起數千個容器，如果需要對每個容器都進行配置，那麼工作量可想而知；并且在經過數個小後，這些容器都将被銷毀，運維人員可能會崩潰。

  Prometheus通過動态發現方式擷取監控對象。目前支援以下系統擷取監控對象：

  ◎ 容器管理系統，例如Kubernetes、Marathon；

  ◎ 各種雲管平台，例如EC2、Azure、OpenStack；◎ 各種服務發現元件，例如DNS、ZooKeeper和Consul等。

  

  Prometheus 會從這些元件中擷取監控對象，并彙總在這些元件中擷取的資料，進而擷取所有監控對象。在第一次被加入時，監控對象（下稱 target）的狀态是unknown。之後，Prometheus會在設定的周期内對target資料進行循環采集，如果采內建功，則target狀态變為up；如果采集失敗（例如逾時），則target狀态變為down。

五 資料處理

1.資料采集

Prometheus采用統一的Restful API方式擷取資料，具體來說是調用HTTP GET請求或metrics資料接口擷取監控資料。為了高效地采集資料，Prometheus對每個采集點都啟動了一個線程去定時采集資料。在修改了采集的時間間隔後，Prometheus會提供兩種配置更新方式：

◎ 第1種是通過調用Prometheus的reload接口進行配置更新；

◎ 第2種是發送信号，通過“kill –HUP Prometheus程序ID”動态加載配置，進而更新采集時間間隔。相較而言，筆者不建議采用第2種配置更新方式，因為它需要動态擷取ID。Prometheus 支援文本資料格式，每個 exporter 都将監控資料輸出成文本資料格式，文本内容以行（\n）為機關，空行将被忽略，文本内容的最後一行為空行，“#”代表注釋，“# HELP”提供幫助資訊，“#TYPE”代表 metric類型。

如果是Histogram或Summary類型，則必須滿足以下條件：

◎ 名額必須提供sum和count方法，分别表示總和和總量；

◎ Summary類型符合“名額名稱{quantile=分位點}”格式；

◎ Histogram類型符合“名額名稱_bucket{le=分位點}”格式，必須包含“名額名稱_bucket{le="+Inf"}”的名額項，它的值等于“名額名_count”的值；

◎ 在Summary和Historam中，quantile和le必須按從小到大的順序排列。

2.資料處理

Prometheus會從 target中擷取所有暴露的資料，但某些資料對 Prometheus是無用的，如果直接儲存這些資料，則不僅浪費空間，還會降低系統的吞吐量。

Prometheus提供了 keep 或 drop 機制，如果設定了 keep 機制，則會保留所有比對标簽的資料；如果設定了drop機制，則會丢棄比對标簽的資料，進而完成資料過濾。除了處理 keep或 drop,Prometheus還支援 Hash的分區采集，通過對 target位址計算 Hash值，然後取模比對 Prometheus設定的值，便可以過濾該Prometheus負責采集的 target，這也是一種服務端負載均衡的方案，進而擴充 Prometheus的采集能力。

下面是一種通過Hash取模的經典用法

3.資料存儲

（1）本地存儲

Prometheus的本地存儲經曆了兩個版本的重要演進，從 Prometheus V1版本更新到V2版本，又更新為現在的V3版本。從V2版本開始，Prometheus的本地存儲便充分借鑒了Facebook Gorilla的設計思想及Facebook内部的長期經驗，總結了時序資料的以下特點：

◎ 相鄰資料點時間戳的內插補點相對固定，即使有變化，也僅在一個很小的範圍内浮動；◎ 相鄰資料點的值的變化幅度很小，甚至無變化；

◎ 對熱資料的查詢頻率遠遠超出對非熱點資料的查詢頻率，并且資料距離現在越近，熱度越高。

（2）prometheus V2 與v3 存儲的差別

V2

• 每個序列都有一個檔案，這樣會耗盡檔案系統的Inode，并且同時随機讀寫了這麼多的檔案，磁盤的性能會大大降低，對于SSD還會存在寫放大的問題。
• 被監控對象不停更新。例如，在Kubernetes容器監控方面，容器的生命周期比較短暫，名額不停變化，會形成“時序流失”。随着時間的推移，雖然有LevelDB負責時序的索引，但這些時間序列會形成線性增長，導緻記憶體積壓過多，

  V3

  ◎ 從 V2版本的每個時序一個檔案改進到 V3版本的一段時間一個檔案，可以有效避免時序流失的問題，還可以任意組織多個塊的資料到一個檔案中；

  ◎ 每個檔案塊最大支援512MB，可避免SSD寫放大；

  ◎ 在删除資料的時候更簡單，直接删除分區即可；

  ◎ 在查詢曆史資料時，由于已經按照時間排序，是以可以将記憶體資料和此磁盤資料合并，通過懶加載的方式載入資料，而不需要将所有磁盤資料加載記憶體，避免發生OOM。

  (3) 遠端存儲

  為了提高對大量曆史資料持久化存儲的能力，Prometheus 在1.6版本後支援遠端存儲，Adapter需要實作Prometheus的read接口和write接口，并且将read和write轉化為每種資料庫各自的協定

  

  在使用者查詢資料時，Prometheus會通過配置的查詢接口發送 HTTP請求，查詢開始時間、結束時間及名額屬性等，Adapter會傳回相應的時序資料；相應地，在使用者寫入資料時，HTTP請求Adapter的消息體會包含時序數組（樣本資料）。

4.資料查詢

對于Prometheus資料，我們都可以通過HTTP來查詢，如果是複雜的資料查詢，則還可以使用PromQL進行。和關系型資料庫實作SQL解析一樣，Prometheus實作了一套自己的資料庫語言（PromQL）解析器。PromQL與SQL的最大差别是PromQL隻支援查詢。

Prometheus 通過解析引擎将查詢語句轉化為 QUERY 請求，然後通過時序資料庫找到具體的資料塊，在資料傳回後再通過支援内置的函數處理資料，最終将結果傳回到前端

Prometheus支援Grafana等開源顯示面闆，通過自定義PromQL可以制作豐富的監控視圖。Prometheus本身也提供了一個簡單的 Web查詢控制台，如圖2-14所示，Web控制台包含三個主要子產品：Graph名額查詢，Alerts告警查詢、Status狀态查詢