Prometheus的基本原理與開發指南

導讀

本文由梯度科技云管研發部高級工程師周宇明撰寫，共分為7章，緊密圍繞Prometheus的基本原理與開發指南展開介紹：

監控系統概述

Prometheus入門

PromQL入門

PromQL高級實戰

告警引擎深度解析

本地存儲與遠程存儲

梯度運維管理平臺監控模塊架構

01監控系統概述

導讀：本章從監控的作用、架構分類、指標監控發展史、指標監控典型架構等4個方面介紹監控系統的相關概念。

1.1．監控的作用 ★

為了構建穩定性保障體系，核心就是在干一件事：減少故障。

減少故障有兩個層面的意思，一個是做好常態預防，不讓故障發生；另一個是如果故障發生，要能盡快止損，減少故障時長，減小故障影響范圍。監控的典型作用就是幫助我們發現及定位故障。

監控的其他作用：日常巡檢、性能調優的數據佐證、提前發現一些不合理的配置。

之所以能做到這些，是因為所有優秀的軟件，都內置了監控數據的暴露方法，讓用戶可以對其進行觀測，了解其健康狀況：比如各類開源組件，有的是直接暴露了 Prometheus metrics 接口，有的是暴露了 HTTP JSON 接口，有的是通過 JMX 暴露監控數據，有的則需要連上去執行命令。另外，所有軟件都可以使用日志的方式來暴露健康狀況。

因此，可被監控和觀測，也是我們開發軟件時必須考慮的一環。

1.2．監控架構分類 ★

1.1.1.Metrics（指標）

定義：可進行聚合計算的原子型數據，通常通過多個標簽值來確定指標唯一性。

特點：指標數據僅記錄時間戳和對應的指標數值，通常存儲在時間序列數據庫中（TSDB），存儲成本低，可用于渲染趨勢圖或柱狀圖，可靈活配置告警規則，對故障進行快速發現和響應；但是不適合用于定位故障原因。

實現方案：Zabbix、Open-Falcon、Prometheus

1.1.2.Logging（日志）

定義：離散事件，是系統運行時發生的一個個事件的記錄。

特點：日志數據可以記錄詳細的信息（請求響應參數、自定義文字描述、異常信息、時間戳等），一般用于排查具體問題；日志通常存儲在文件中，數據非結構化，存儲成本高，不適合作為監控數據的來源。

實現方案：ELK、Loki

1.1.3.Tracing（鏈路）

定義：基于特定請求作用域下的所有調用信息。

特點：一般需要依賴第三方存儲，在微服務中一般有多個調用信息，如從網關開始，A服務調用B服務，調用數據庫、緩存等。在鏈路系統中，需要清楚展現某條調用鏈中從主調方到被調方內部所有的調用信息。不僅有利于梳理接口及服務間調用的關系，還有助于排查慢請求或故障產生的原因。

實現方案：jaeger、zipkin、Skywalking

1.3.指標監控發展史

1.3.1.Zabbix

企業級的開源解決方案，擅長設備、網絡、中間件的監控。

優點：

平臺兼容性好，可運行在 Windows、Linux、Solaris、AIX、OS X等平臺上；

架構簡單，易于維護、備份。

缺點：

使用數據庫存儲，無法水平擴展，容量有限；

面向資產管理的邏輯，使得監控指標的數據結構固化，沒有靈活的標簽設計，無法適應云原生架構下動態多變的環境。

1.3.2.Open-Falcon

Open-Falcon 最初來自小米，14 年開源，當時小米有 3 套 Zabbix，1 套業務性能監控系統 perfcounter。Open-Falcon 的初衷是想做一套大一統的方案，來解決這個亂局。

優點：

比Zabbix容量大得多，不僅可以處理設備、中間件層面監控，還可以處理應用層面監控；

Go語言開發，易于二次開發。

缺點：

組件拆分比較散，部署相對比較麻煩；

生態不夠龐大，開源軟件的治理架構不夠優秀。

1.3.3.Prometheus

Prometheus 的設計思路來自Borgmon，就像 Borgmon 是為 Borg 而生的，而 Prometheus 就是為 Kubernetes 而生的。提供了多種服務發現機制，大幅簡化了 Kubernetes 的監控。

Prometheus2.0版本開始，重新設計了時序庫，性能和可靠性都大幅提升。

優點：

對 Kubernetes 支持很好，Prometheus 是云原生架構下監控的標配；

生態龐大，有各種各樣的 Exporter，支持各種各樣的時序庫作為后端的備用存儲，也有很好的支持多種不同語言的 SDK，供業務代碼嵌入埋點。

缺點：

設置數據采集和告警策略需要修改配置文件，協同起來比較麻煩。

Exporter 參差不齊，通常是一個監控目標一個 Exporter，管理成本較高。

1.4.指標監控典型架構 ★

1.4.1.采集器 ★

有兩種典型的部署方式，一種是跟隨監控對象部署，比如所有的機器上都部署一個采集器，采集機器的 CPU、內存、硬盤、IO、網絡相關的指標；另一種是遠程探針式，比如選取一個中心機器做探針，同時探測很多個機器的 PING 連通性，或者連到很多 MySQL 實例上去，執行命令采集數據。

Telegraf：

InfluxData 公司的產品，主要配合 InfluxDB 使用。Telegraf 也可以把監控數據推給 Prometheus存儲；

Telegraf 是指標領域的 All-In-One 采集器，支持各種采集插件，只需要使用這一個采集器，就能解決絕大部分采集需求；

Telegraf 采集的很多數據都是字符串類型，但如果把這類數據推給 Prometheus 生態的時序庫，比如 VictoriaMetrics、M3DB、Thanos 等，它就會報錯

Exporter：

Exporter是專門用于Prometheus 生態的采集器，但是比較零散，每個采集目標都有對應的 Exporter 組件，比如 MySQL 有 mysqld_exporter，Redis 有 redis_exporter，JVM 有 jmx_exporter。

Exporter 的核心邏輯，就是去這些監控對象里采集數據，然后暴露為 Prometheus 協議的監控數據。比如 mysqld_exporter，就是連上 MySQL，執行一些類似于 show global status 、show global variables 、show slave status 這樣的命令，拿到輸出，再轉換為 Prometheus 協議的數據；

很多中間件都內置支持了 Prometheus，直接通過自身的 /metrics 接口暴露監控數據，不用再單獨伴生 Exporter；比如 Kubernetes 中的各類組件，比如 etcd，還有新版本的 ZooKeeper、 RabbitMQ；

不管是Exporter還是支持Prometheus協議的各類組件，都是提供 HTTP 接口（通常是 /metrics ）來暴露監控數據，讓監控系統來拉，這叫做 PULL 模型。

Grafana-Agent：

Grafana 公司推出的一款 All-In-One 采集器，不但可以采集指標數據，也可以采集日志數據和鏈路數據。

如何快速集成各類采集能力的呢？Grafana-Agent 寫了個框架，方便導入各類 Exporter，把各個 Exporter 當做 Lib 使用，常見的 Node-Exporter、Kafka-Exporter、Elasticsearch-Exporter、Mysqld-Exporter 等，都已經完成了集成。對于默認沒有集成進去的 Exporter，Grafana-Agent 也支持用 PULL 的方式去抓取其他 Exporter 的數據，然后再通過 Remote Write 的方式，將采集到的數據轉發給服務端。

很多時候，一個采集器可能搞不定所有業務需求，使用一款主力采集器，輔以多款其他采集器是大多數公司的選擇。

1.4.2.時序庫

PrometheusTSDB

Prometheus本地存儲經歷過多個迭代：V1.0（2012年）、V2.0（2015年）、V3.0（2017年）。最初借用第三方數據庫LevelDB，1.0版本性能不高，每秒只能存儲5W個樣本；2.0版本借鑒了Facebook Gorilla壓縮算法，將每個時序數據以單個文件方式保存，將性能提升到每秒存儲8W個樣本；2017年開始引入時序數據庫的3.0版本，并成立了Prometheus TSDB開源項目，該版本在單機上提高到每秒存儲百萬個樣本。

3.0版本保留了2.0版本高壓縮比的分塊保存方式，并將多個分塊保存到一個文件中，通過創建一個索引文件避免產生大量的小文件；同時為了防止數據丟失，引入了WAL機制。

InfluxDB

InfluxDB 針對時序存儲場景專門設計了存儲引擎、數據結構、存取接口，國內使用范圍比較廣泛，可以和 Grafana、Telegraf 等良好整合，生態是非常完備的。

不過 InfluxDB 開源版本是單機的，沒有開源集群版本。

M3DB

M3DB 是 Uber 的時序數據庫，M3 在 Uber 抗住了 66 億監控指標，這個量非常龐大。其主要包括4個組件：M3DB、M3 Coordinator、M3 Query、M3 Aggregator，我們當前產品中Prometheus的遠程存儲就是通過M3DB實現的。

1.4.3.告警引擎 ★

用戶會配置數百甚至數千條告警規則，一些超大型的公司可能要配置數萬條告警規則。每個規則里含有數據過濾條件、閾值、執行頻率等，有一些配置豐富的監控系統，還支持配置規則生效時段、持續時長、留觀時長等。

告警引擎通常有兩種架構，一種是數據觸發式，一種是周期輪詢式。

數據觸發式，是指服務端接收到監控數據之后，除了存儲到時序庫，還會轉發一份數據給告警引擎，告警引擎每收到一條監控數據，就要判斷是否關聯了告警規則，做告警判斷。因為監控數據量比較大，告警規則的量也可能比較大，所以告警引擎是會做分片部署的，這樣的架構，即時性很好，但是想要做指標關聯計算就很麻煩，因為不同的指標哈希后可能會落到不同的告警引擎實例。

周期輪詢式，通常是一個規則一個協程，按照用戶配置的執行頻率，周期性查詢判斷即可，做指標關聯計算就會很容易。像 Prometheus、Nightingale、Grafana 等，都是這樣的架構。

生成事件之后，通常是交給一個單獨的模塊來做告警發送，這個模塊負責事件聚合、收斂，根據不同的條件發送給不同的接收者和不同的通知媒介。

1.4.4.數據展示

監控數據的可視化也是一個非常通用且重要的需求，業界做得最成功的是Grafana，采用插件式架構，可以支持不同類型的數據源，圖表非常豐富，基本是開源領域的事實標準。

02Prometheus入門

導讀：本章首先介紹了Prometheus主要特點，然后根據特點對其局限性及架構進行剖析。讀完本章，可以讓讀者清晰地了解如何運用Prometheus。

2.1．主要特點

PromQL多維度數據模型的靈活查詢；

定義了開放指標數據的標準，自定義探針（Exporter等）；

Go語言編寫，擁抱云原生；

數據采集方式以pull為主、push為輔；

二進制文件直接啟動、也支持容器鏡像化部署；

支持多種語言客戶端；

支持本地和第三方遠程存儲、高效的存儲；

可擴展，功能分區+聯邦集群；

結合Grafana可以做到出色的可視化功能；

精確告警：基于PromQL可以進行告警設置、預測等；另外還提供了分組、抑制、靜默等功能防止告警風暴；

支持動態發現機制：Kubernetes；

2.2. 局限性

主要針對性能和可用性監控，不適用日志、事件、調用鏈等監控；

關注近期發生的事，而不是跟蹤數周或數月的數據，監控數據默認保留15天；

本地存儲有限，存儲大量歷史數據需要對接第三方遠程存儲；

采用聯邦集群方式時，沒有提供統一的全局視圖。

2.3. 架構剖析 ★

Job/Exporter

prometheus監控探針，共收錄有上千種Exporter，用于對第三方系統進行監控，方式是獲取第三方系統的監控數據然后按照Prometheus的格式暴露出來；沒有Exporter探針的第三方系統也可以自己定制開發。

不過Exporter種類繁多會導致維護壓力大，也可以考慮用Influx Data公司開源的Telegraf統一進行管理。使用Telegraf集成Prometheus比單獨使用Prometheus擁有更低的內存使用率和CPU使用率。

PushGateway

是支持臨時性job主動推送指標的中間網關。

使用場景：臨時/短作業、批處理作業、應用程序與Prometheus之間有防火墻或不在同一個網段；

不過該解決方案存在單點故障問題、必須使用PushGateway的API從推送網關中刪除過期指標。

ServiceDiscovery（服務發現機制）

可以使用Kubernetes的API獲取容器信息的變化來動態更新監控對象；

Prometheus Server（核心監控服務）

i.Retrieval（抓?。?/p>

從Job、Exporter、PushGateway3個組件中通過HTTP輪詢的形式拉取指標數據；

ii.Storage（存儲）

本地存儲：直接保存到本地磁盤，從性能上考慮，建議使用SSD且不要保存超過一個月的數據；

遠程存儲：適用于存儲大量監控數據，支持的遠程存儲包括OpenTSDB、InfluxDB、M3DB、PostgreSQL等；需要配合中間層適配器進行轉換；

iii.PromQL（查詢）

多維度數據模型的靈活查詢。

Dashboard（可視化）

實際工作中使用Grafana，也可以調用HTTP API發送請求獲取數據；

Alertmanager（告警引擎）

獨立的告警組件，可以將多個AlertManager配置成集群，支持集群內多個實例間通信；

03PromQL入門

導讀：本章圍繞PromQL基本概念、4大選擇器、4大指標類型及13種聚合操作等展開介紹，幫助讀者輕松理解PromQL相關知識。

3.1.初識PromQL ★

3.1.1.時間序列 ★

按照一定的時間間隔產生的一個個數據點，這些數據點按照時間戳和值的生成順序存放，得到了向量（vector）。

每條時間序列是通過指標名稱和一組標簽集來命名的。

矩陣中每一個點都可以稱之為一個樣本（Sample），主要有3方面構成：

指標（Metrics）：包括指標名稱（__name__）和一組標簽集名稱；

時間戳（TimeStamp）：默認精確到毫秒；

樣本值（Value）：默認使用64位浮點類型。

3.1.2.指標 ★

時間序列的指標可以基于Bigtable設計為Key-Value存儲的方式：

Prometheus的Metrics可以有兩種表現方式（指標名稱只能由ASCII字符、數字、下劃線、冒號組成，冒號用來表示用戶自定義的記錄規則）：

分別對應的查詢形式（以下兩個查詢語句等價）：

3.2. 4大選擇器

3.2.1.匹配器

相等匹配器（=）：對于不存在的標簽可以使用Label=""的形式查詢

不等匹配器（!=）：相等匹配器的否定

正則表達式匹配器（=~）：前面或者后面加上".*"

所有PromQL語句必須包含至少一個有效表達式（至少一個不會匹配到空字符串的標簽過濾器），因此，以下三種示例是非法的：

正則表達式相反匹配器（!~）：正則表達式匹配器的否定

3.2.2.瞬時向量選擇器

用于返回在指定時間戳之前查詢到的最新樣本的瞬時向量。

3.2.3.區間向量選擇器

高級應用：

3.2.4.偏移量修改器

瞬時偏移向量

高級應用：

3.3. 4大指標類型 ★

3.3.1.計數器（Counter）★

只增不減，一般配合rate（統計時間區間內增長速率）、topk（統計top N的數據）、increase等函數使用；

increase(v range-vector)獲取區間向量的第一個和最后一個樣本并返回其增長量：

為什么increase函數算出來的值非33？真實計算公式：(360 - 327) / (1687922987 - 1687922882) * 120 = 37.71428571428571

irate(v range-vector)是針對長尾效應專門提供的用于計算區間向量的增長速率的函數，反應的是瞬時增長率，敏感度更高。長期趨勢分析或告警中更推薦rate函數。

rate(v range-vector) 求取的是每秒變化率，也有數據外推的邏輯，increase 的結果除以 range-vector 的時間段的大小，就是 rate 的值。

rate(jvm_memory_used_bytes{id="PS Eden Space"}[1m]) 與 increase(jvm_memory_used_bytes{id="PS Eden Space"}[1m])/60.0 是等價的

3.3.2.儀表盤（Gauge） ★

表示樣本數據可任意增減的指標；實際更多用于求和、取平均值、最大值、最小值。

without可以讓sum函數根據相同的標簽進行求和，但是忽略掉without函數覆蓋的標簽；如上圖，可以忽略掉id，只按照堆/非堆的區別進行內存空間求和。

3.3.3.直方圖（Histogram） ★

用于描述數據分布，最典型的應用場景就是監控延遲數據，計算 90 分位、99 分位的值。

有些服務訪問量很高，每秒幾百萬次，如果要把所有請求的延遲數據全部拿到，排序之后再計算分位值，這個代價就太高了。使用 Histogram 類型，可以用較小的代價計算一個大概值。

Prometheus的Histogram類型計算原理：bucket桶排序+假定桶內數據均勻分布。

Histogram 這種做法性能有了巨大的提升，但是要同時計算成千上萬個接口的分位值延遲數據，還是非常耗費資源的，甚至會造成服務端 OOM。

數據解析：http://ip:9090/metrics prometheus_http_request_duration_seconds

3.3.4.匯總（Summary） ★

在客戶端計算分位值，然后把計算之后的結果推給服務端存儲，展示的時候直接查詢即可。

Summary 的計算是在客戶端計算的，也就意味著不是全局（整個服務）的分位值，分位值延遲數據是進程粒度的。

負載均衡會把請求均勻地打給后端的多個實例。一個實例內部計算的分位值，理論上和全局計算的分位值差別不會很大。另外，如果某個實例有故障，比如硬盤問題，導致落在這個實例的請求延遲大增，我們在實例粒度計算的延遲數據反而更容易發現問題。

數據解析：http://ip:9090/metrics go_gc_duration_seconds

3.4.13種聚合操作

without 和 by 用來保留不同維度的可選操作符，其余11個聚合操作都是用于瞬時向量，使用相同的分組邏輯：

sum

min

max

avg

count

count_values（對value進行計數）

stddev（標準差）

stdvar（標準差異）

bottomk（樣本值最小k個元素）

topk（樣本值最大k個元素）

quantile（分布統計）

3.4.1.without、by★

上述兩個查詢是等價的；同一個聚合語句中不可同時使用by和without，by的作用類似于sql語句中的分組（group by），without語義是：除開XX標簽，對剩下的標簽進行分組。

3.4.2.stdvar

數學中稱為方差，用于衡量一組數據的離散程度：數據分布得越分散，各個數據與平均數的差的平方和越大，方差就越大。

3.4.3.stddev

標準差：用方差開算術平方根。

3.4.4.count、count_values

count：對分組中時間序列的數目進行求和

count_values：表示時間序列中每一個樣本值（value）出現的次數，實踐中一般用于統計版本號。

3.4.5.quantile

用于計算當前樣本數據值的分布情況，例如計算一組http請求次數的中位數：

3.5.3種二元操作符

3.5.1.算術運算符（加減乘除模冪）

3.5.2.集合/邏輯運算符

僅用于瞬時向量之間，and（并且）、or（或者）、unless（排除）

內置函數absent扮演了not的角色；

absent應用場景，配置告警規則：

3.5.3.比較運算符（== !=> < ?>= <=），無需過多解釋

04PromQL高級實戰

導讀：本章首先介紹了Prometheus內置函數，然后通過HTTP API、執行規則、指標抓取與存儲等多個知識點，輔以實踐案例，全方位介紹了PromQL的高級用法。

4.1.Prometheus內置函數

4.1.1.動態標簽函數 ★

提供了對時間序列標簽的自定義能力。

label_replace(input_vector, "dst", "replacement", "src", "regex")

label_join(input_vector, "dst", "separator", "src_1", "src_2" ...)

4.1.2.時間日期函數（沒有時區的概念）

4.1.3.多對多運算算函數（absent，常用于檢測服務是否存活）

4.1.4.Counter函數

resets函數用于統計計數器重置次數，兩個連續的樣本之間值減少，被認為是一次計數器重置，相當于是進程重啟次數。

4.1.5.Gauge函數

predict_linear(v range-vector, t scalar)

預測時間序列v在t秒后的值

deriv(v range-vector)

使用簡單的線性回歸計算區間向量v中各個時間序列的導數

delta(v range-vector)

計算區間向量內第一個元素和最后一個元素的差值：

idelta(v range-vector)

最新的兩個樣本值之間的差值，如上圖例子，返回值為整數

holt_winters(v range-vector, sf scalar, tf scalar)

要求sf > 0, tf <= 1

霍爾特-溫特雙指數平滑算法，暫時想不到應用場景

changes(v range-vector)

返回區間向量中每個樣本數據值變化的次數，如果樣本值沒有變化就返回1；

prometheus提供度量標準process_start_time_seconds記錄每一個targets的啟動時間，該時間被更改則意味著進程重啟，可以發出循環崩潰告警：

expr:avgwtihout(instance) (changes{process_start_time_seconds [1h]}) > 3

4.1.6.時間聚合函數

4.2.HTTPAPI ★

4.2.1.API響應格式

調用成功會返回2XX狀態碼

resultType: matrix(區間向量) | vector(瞬時向量) | scalar | string

4.2.2.表達式查詢

/api/v1/query（瞬時數據查詢）

入參：PromQL表達式、時間戳、超時設置（可全局設置）

/api/v1/query_range（區間數據查詢）

入參：PromQL表達式、起始時間戳、結束時間戳、查詢時間步長（不能超過11000）、超時設置（可全局設置）

4.2.3.其他拓展

/api/v1/targets（獲取監控對象列表）

/api/v1/rules（獲取告警規則數據）

/api/v1/alerts（獲取告警列表）

/api/v1/alertmanagers（獲取關聯的告警引擎）

/api/v1/targets/metadata（獲取監控對象元數據）

/api/v1/metadata（獲取指標元數據）

/status（prometheus配置、版本等數據）

TSDB管理API

啟動參數帶上--web.enable-admin-api

執行以下命令可對數據庫進行備份：

curl -X POST http://your_ip:9090/api/v1/admin/tsdb/snapshot

備份目錄：/prometheus/data/snapshot

刪除序列：

http://your_ip:9090/api/v1/admin/tsdb/delete_series

釋放空間：http://your_ip:9090/api/v1/admin/tsdb/clean_tombstones

4.3.可定期執行的規則

4.3.1.記錄規則

預先計算經常需要用到的或計算量較大的表達式，并將結果保存為一組新的時間序列。

4.3.2.告警規則

4.4.指標的抓取與存儲 ★

抓取前依賴服務發現，通過relabel_configs的方式自動對服務發現的目標進行重新標記；

抓取后主要指標保存在存儲系統之前，依賴作業內的metrics_relabel_configs實現。

4.4.1.用relabel_configs抓取指標 ★

重寫instance實現告警同時顯示服務名+IP端口

4.4.2.用metrics_relabel_configs抓取指標將監控不需要的數據直接丟掉，不在prometheus保存，配置方法類似。

05告警引擎深度解析

導讀：本章拓展了Alertmanager架構解析、Alertmanager配置文件、告警應用與問題處理等眾多知識點。

5.1.Alertmanager架構解析 ★

從左上開始，Prometheus 發送的警報到 Alertmanager;

警報會被存儲到 AlertProvider 中，Alertmanager 的內置實現就是包了一個 map，也就是存放在本機內存中，這里可以很容易地擴展其它 Provider;

Dispatcher 是一個單獨的 goroutine，它會不斷到 AlertProvider 拉新的警報，并且根據 YAML 配置的 Routing Tree 將警報路由到一個分組中;

分組會定時進行 flush (間隔為配置參數中的 group_interval), flush 后這組警報會走一個 Notification Pipeline 鏈式處理;

Notification Pipeline 為這組警報確定發送目標，并執行抑制邏輯，靜默邏輯，發送與重試邏輯，實現警報的最終投遞;

5.2.Alertmanager配置文件解讀 ★

全局配置（global）：定義一些全局的公共參數，如全局SMTP設置、Slack配置等；

模板（template）：定義告警通知的模板，如HTML模板、郵件模板；

告警路由（route）：告警的分組聚合，根據自定義標簽匹配，確定當前告警應該如何處理；

接收者（receivers）：郵箱、webhook等，一般配合告警路由使用；

抑制規則（inhibit_rules）：減少垃圾告警產生；

5.3.關于告警的應用與問題處理 ★

關鍵配置參數：

prometheus.yml

scrape_interval：prometheus從采集器抓取數據間隔，默認1分鐘；

scrape_timeout：數據抓取超時時間，默認10秒鐘；

evaluation_interval：評估告警規則的時間間隔（即多長時間計算一次告警規則是否觸發），默認1分鐘；

alertmanager.yml

group_wait：初始等待時間，一組告警消息第一次發送前的等待時間，在這個時間內允許為同一組告警收集更多初始告警，此參數的作用是防止短時間內出現大量告警的情況下，接收者被消息淹沒?！敬藚到ㄗh設置為0到5分鐘】。

group_interval：睡眠/喚醒周期，一組告警消息被成功發送后，會進入睡眠/喚醒周期，此參數是睡眠狀態將持續的時間，在睡眠狀態下該組消息可能會有明細內容變化。睡眠結束后進入喚醒狀態，如果檢查到有明細內容存在變化，則發送新告警消息；如果沒有變化，則判斷是否達到“重復發送間隔時間”來決定是否發送?！敬藚到ㄗh設置為5到30分鐘】。

repeat_interval：重復發送間隔時間，此參數是指同一個消息組在明細內容不變的情況下，連續多長時間不發送告警消息。不過此參數值并不代表告警的實際重復間隔，因為在上一次發送消息后并等待了“重復發送間隔時間”的時刻，該消息組可能處在睡眠狀態；所以實際的告警間隔應該大于“重復發送間隔時間”且小于“重復發送間隔時間”與“睡眠/喚醒周期”之和?！敬藚到ㄗh設置為3小時以上】。

06本地存儲與遠程存儲

導讀：本章主要分析了壓縮算法、本地存儲文件結構、存儲原理、M3DB遠程存儲技術，并對使用過程中可能出現的問題給出了指導和建議。

6.1.壓縮算法

lPrometheus本地存儲經歷過多個迭代：V1.0（2012年）、V2.0（2015年）、V3.0（2017年）。最初借用第三方數據庫LevelDB，1.0版本性能不高，每秒只能存儲5W個樣本；2.0版本借鑒了Facebook Gorilla壓縮算法，將每個時序數據以單個文件方式保存，將性能提升到每秒存儲8W個樣本；2017年開始引入時序數據庫的3.0版本，并成立了Prometheus TSDB開源項目，該版本在單機上提高到每秒存儲百萬個樣本。

3.0版本保留了2.0版本高壓縮比的分塊保存方式，并將多個分塊保存到一個文件中，通過創建一個索引文件避免產生大量的小文件；同時為了防止數據丟失，引入了WAL機制。

6.2.本地存儲文件結構解析

6.3.存儲原理解析

按時間順序生成多個block文件，其中第一個block稱為head block，存儲在內存中且允許被修改，其它block文件則以只讀的方式持久化在磁盤上。

抓取數據時，Prometheus周期性的將監控數據以chunk的形式添加到head block中，同時寫日志。會按2小時一個block的速率進行磁盤持久化。

崩潰后再次啟動會以寫入日志的方式實現重播，從而恢復數據。

2小時的block會在后臺壓縮成更大的block，數據被壓縮合并成更高級別的block文件后刪除低級別的block文件。

6.4.M3DB遠程存儲技術

6.4.1.M3特性

主要包括4個組件：M3DB、M3 Coordinator、M3 Query、M3 Aggregator

M3DB：分布式時序庫，為時間序列數據和反向索引提供了可伸縮、可擴展的存儲。

M3 Coordinator：輔助服務，用于協調上游系統（如Prometheus和M3DB）之間的讀寫操作，是用戶訪問M3DB的橋梁。

M3 Query：分布式查詢引擎，可查詢實時和歷史指標，支持多種不同的查詢語言（包括PromQL）。

M3 Aggregator：聚合層，作為專用度量聚合器運行的服務。

6.4.2.M3DB特性

分布式時間序列存儲，單個節點使用WAL提交日志并獨立保存每個分片的時間窗口。

集群管理建立在etcd之上（分布式服務注冊中心）。

內置同步復制功能，具有可配置的持久性和讀取一致性。

自定義壓縮算法M3TSZ float64。

6.4.3.M3DB限制

M3DB主要是為了減少攝取和存儲數十億個時間序列的成本并提供快速可伸縮的讀取，因此存在一些限制，不適合用作通用時序庫。

M3DB旨在盡可能避免壓縮，目前M3DB僅在可變壓縮時間序列窗口內執行壓縮，因此亂序寫入僅限單個壓縮時間序列窗口的大小。

M3DB針對float64值的存儲和檢索進行優化，無法將其用作包含任意數據結構的通用時序庫。

6.4.4.M3DB分布式架構

Coordinator：m3coordinator用于協調群集中所有主機之間的讀取和寫入。這是一個輕量級的過程，不存儲任何數據。該角色通常將與Prometheus實例一起運行。

Storage Node：在這些主機上運行的m3dbnode進程是數據庫的主力，它們存儲數據，并提供讀寫功能。

Seed Node：首先，這些主機本身就是存儲節點。除了該職責外，他們還運行嵌入式ETCD服務器。這是為了允許跨集群運行的各種M3DB進程以一致的方式推斷集群的拓撲/配置。

07梯度運維管理平臺監控模塊架構★

審核編輯：彭菁