導讀

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

監(jiān)控系統(tǒng)概述

Prometheus入門

PromQL入門

PromQL高級實戰(zhàn)

告警引擎深度解析

本地存儲與遠程存儲

梯度運維管理平臺監(jiān)控模塊架構(gòu)

01監(jiān)控系統(tǒng)概述

導讀：本章從監(jiān)控的作用、架構(gòu)分類、指標監(jiān)控發(fā)展史、指標監(jiān)控典型架構(gòu)等4個方面介紹監(jiān)控系統(tǒng)的相關概念。

1.1．監(jiān)控的作用 ★

為了構(gòu)建穩(wěn)定性保障體系，核心就是在干一件事：減少故障。

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

監(jiān)控的其他作用：日常巡檢、性能調(diào)優(yōu)的數(shù)據(jù)佐證、提前發(fā)現(xiàn)一些不合理的配置。

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

因此，可被監(jiān)控和觀測，也是我們開發(fā)軟件時必須考慮的一環(huán)。

1.2．監(jiān)控架構(gòu)分類 ★

1.1.1.Metrics（指標）

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

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

實現(xiàn)方案：Zabbix、Open-Falcon、Prometheus

1.1.2.Logging（日志）

定義：離散事件，是系統(tǒng)運行時發(fā)生的一個個事件的記錄。

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

實現(xiàn)方案：ELK、Loki

1.1.3.Tracing（鏈路）

定義：基于特定請求作用域下的所有調(diào)用信息。

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

實現(xiàn)方案：jaeger、zipkin、Skywalking

1.3.指標監(jiān)控發(fā)展史

1.3.1.Zabbix

企業(yè)級的開源解決方案，擅長設備、網(wǎng)絡、中間件的監(jiān)控。

優(yōu)點：

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

架構(gòu)簡單，易于維護、備份。

缺點：

使用數(shù)據(jù)庫存儲，無法水平擴展，容量有限；

面向資產(chǎn)管理的邏輯，使得監(jiān)控指標的數(shù)據(jù)結(jié)構(gòu)固化，沒有靈活的標簽設計，無法適應云原生架構(gòu)下動態(tài)多變的環(huán)境。

1.3.2.Open-Falcon

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

優(yōu)點：

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

Go語言開發(fā)，易于二次開發(fā)。

缺點：

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

生態(tài)不夠龐大，開源軟件的治理架構(gòu)不夠優(yōu)秀。

1.3.3.Prometheus

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

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

優(yōu)點：

對 Kubernetes 支持很好，Prometheus 是云原生架構(gòu)下監(jiān)控的標配；

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

缺點：

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

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

1.4.指標監(jiān)控典型架構(gòu) ★

1.4.1.采集器 ★

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

Telegraf：

InfluxData 公司的產(chǎn)品，主要配合 InfluxDB 使用。Telegraf 也可以把監(jiān)控數(shù)據(jù)推給 Prometheus存儲；

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

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

Exporter：

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

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

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

不管是Exporter還是支持Prometheus協(xié)議的各類組件，都是提供 HTTP 接口（通常是 /metrics ）來暴露監(jiān)控數(shù)據(jù)，讓監(jiān)控系統(tǒng)來拉，這叫做 PULL 模型。

Grafana-Agent：

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

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

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

1.4.2.時序庫

PrometheusTSDB

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

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

InfluxDB

InfluxDB 針對時序存儲場景專門設計了存儲引擎、數(shù)據(jù)結(jié)構(gòu)、存取接口，國內(nèi)使用范圍比較廣泛，可以和 Grafana、Telegraf 等良好整合，生態(tài)是非常完備的。

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

M3DB

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

1.4.3.告警引擎 ★

用戶會配置數(shù)百甚至數(shù)千條告警規(guī)則，一些超大型的公司可能要配置數(shù)萬條告警規(guī)則。每個規(guī)則里含有數(shù)據(jù)過濾條件、閾值、執(zhí)行頻率等，有一些配置豐富的監(jiān)控系統(tǒng)，還支持配置規(guī)則生效時段、持續(xù)時長、留觀時長等。

告警引擎通常有兩種架構(gòu)，一種是數(shù)據(jù)觸發(fā)式，一種是周期輪詢式。

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

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

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

1.4.4.數(shù)據(jù)展示

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

02Prometheus入門

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

2.1．主要特點

PromQL多維度數(shù)據(jù)模型的靈活查詢；

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

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

數(shù)據(jù)采集方式以pull為主、push為輔；

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

支持多種語言客戶端；

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

可擴展，功能分區(qū)+聯(lián)邦集群；

結(jié)合Grafana可以做到出色的可視化功能；

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

支持動態(tài)發(fā)現(xiàn)機制：Kubernetes；

2.2. 局限性

主要針對性能和可用性監(jiān)控，不適用日志、事件、調(diào)用鏈等監(jiān)控；

關注近期發(fā)生的事，而不是跟蹤數(shù)周或數(shù)月的數(shù)據(jù)，監(jiān)控數(shù)據(jù)默認保留15天；

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

采用聯(lián)邦集群方式時，沒有提供統(tǒng)一的全局視圖。

2.3. 架構(gòu)剖析 ★

Job/Exporter

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

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

PushGateway

是支持臨時性job主動推送指標的中間網(wǎng)關。

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

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

ServiceDiscovery（服務發(fā)現(xiàn)機制）

可以使用Kubernetes的API獲取容器信息的變化來動態(tài)更新監(jiān)控對象；

Prometheus Server（核心監(jiān)控服務）

i.Retrieval（抓?。?/p>

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

ii.Storage（存儲）

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

遠程存儲：適用于存儲大量監(jiān)控數(shù)據(jù)，支持的遠程存儲包括OpenTSDB、InfluxDB、M3DB、PostgreSQL等；需要配合中間層適配器進行轉(zhuǎn)換；

iii.PromQL（查詢）

多維度數(shù)據(jù)模型的靈活查詢。

Dashboard（可視化）

實際工作中使用Grafana，也可以調(diào)用HTTP API發(fā)送請求獲取數(shù)據(jù)；

Alertmanager（告警引擎）

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

03PromQL入門

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

3.1.初識PromQL ★

3.1.1.時間序列 ★

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

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

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

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

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

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

3.1.2.指標 ★

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

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

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

3.2. 4大選擇器

3.2.1.匹配器

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

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

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

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

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

3.2.2.瞬時向量選擇器

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

3.2.3.區(qū)間向量選擇器

高級應用：

3.2.4.偏移量修改器

瞬時偏移向量

高級應用：

3.3. 4大指標類型 ★

3.3.1.計數(shù)器（Counter）★

只增不減，一般配合rate（統(tǒng)計時間區(qū)間內(nèi)增長速率）、topk（統(tǒng)計top N的數(shù)據(jù)）、increase等函數(shù)使用；

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

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

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

rate(v range-vector) 求取的是每秒變化率，也有數(shù)據(jù)外推的邏輯，increase 的結(jié)果除以 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） ★

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

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

3.3.3.直方圖（Histogram） ★

用于描述數(shù)據(jù)分布，最典型的應用場景就是監(jiān)控延遲數(shù)據(jù)，計算 90 分位、99 分位的值。

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

Prometheus的Histogram類型計算原理：bucket桶排序+假定桶內(nèi)數(shù)據(jù)均勻分布。

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

數(shù)據(jù)解析：http://ip:9090/metrics prometheus_http_request_duration_seconds

3.3.4.匯總（Summary） ★

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

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

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

數(shù)據(jù)解析：http://ip:9090/metrics go_gc_duration_seconds

3.4.13種聚合操作

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

sum

min

max

avg

count

count_values（對value進行計數(shù)）

stddev（標準差）

stdvar（標準差異）

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

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

quantile（分布統(tǒng)計）

3.4.1.without、by★

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

3.4.2.stdvar

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

3.4.3.stddev

標準差：用方差開算術(shù)平方根。

3.4.4.count、count_values

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

count_values：表示時間序列中每一個樣本值（value）出現(xiàn)的次數(shù)，實踐中一般用于統(tǒng)計版本號。

3.4.5.quantile

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

3.5.3種二元操作符

3.5.1.算術(shù)運算符（加減乘除模冪）

3.5.2.集合/邏輯運算符

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

內(nèi)置函數(shù)absent扮演了not的角色；

absent應用場景，配置告警規(guī)則：

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

04PromQL高級實戰(zhàn)

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

4.1.Prometheus內(nèi)置函數(shù)

4.1.1.動態(tài)標簽函數(shù) ★

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

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

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

4.1.2.時間日期函數(shù)（沒有時區(qū)的概念）

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

4.1.4.Counter函數(shù)

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

4.1.5.Gauge函數(shù)

predict_linear(v range-vector, t scalar)

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

deriv(v range-vector)

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

delta(v range-vector)

計算區(qū)間向量內(nèi)第一個元素和最后一個元素的差值：

idelta(v range-vector)

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

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

要求sf > 0, tf <= 1

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

changes(v range-vector)

返回區(qū)間向量中每個樣本數(shù)據(jù)值變化的次數(shù)，如果樣本值沒有變化就返回1；

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

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

4.1.6.時間聚合函數(shù)

4.2.HTTPAPI ★

4.2.1.API響應格式

調(diào)用成功會返回2XX狀態(tài)碼

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

4.2.2.表達式查詢

/api/v1/query（瞬時數(shù)據(jù)查詢）

入?yún)ⅲ篜romQL表達式、時間戳、超時設置（可全局設置）

/api/v1/query_range（區(qū)間數(shù)據(jù)查詢）

入?yún)ⅲ篜romQL表達式、起始時間戳、結(jié)束時間戳、查詢時間步長（不能超過11000）、超時設置（可全局設置）

4.2.3.其他拓展

/api/v1/targets（獲取監(jiān)控對象列表）

/api/v1/rules（獲取告警規(guī)則數(shù)據(jù)）

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

/api/v1/alertmanagers（獲取關聯(lián)的告警引擎）

/api/v1/targets/metadata（獲取監(jiān)控對象元數(shù)據(jù)）

/api/v1/metadata（獲取指標元數(shù)據(jù)）

/status（prometheus配置、版本等數(shù)據(jù)）

TSDB管理API

啟動參數(shù)帶上--web.enable-admin-api

執(zhí)行以下命令可對數(shù)據(jù)庫進行備份：

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.可定期執(zhí)行的規(guī)則

4.3.1.記錄規(guī)則

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

4.3.2.告警規(guī)則

4.4.指標的抓取與存儲 ★

抓取前依賴服務發(fā)現(xiàn)，通過relabel_configs的方式自動對服務發(fā)現(xiàn)的目標進行重新標記；

抓取后主要指標保存在存儲系統(tǒng)之前，依賴作業(yè)內(nèi)的metrics_relabel_configs實現(xiàn)。

4.4.1.用relabel_configs抓取指標 ★

重寫instance實現(xiàn)告警同時顯示服務名+IP端口

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

05告警引擎深度解析

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

5.1.Alertmanager架構(gòu)解析 ★

從左上開始，Prometheus 發(fā)送的警報到 Alertmanager;

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

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

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

Notification Pipeline 為這組警報確定發(fā)送目標，并執(zhí)行抑制邏輯，靜默邏輯，發(fā)送與重試邏輯，實現(xiàn)警報的最終投遞;

5.2.Alertmanager配置文件解讀 ★

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

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

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

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

抑制規(guī)則（inhibit_rules）：減少垃圾告警產(chǎn)生；

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

關鍵配置參數(shù)：

prometheus.yml

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

scrape_timeout：數(shù)據(jù)抓取超時時間，默認10秒鐘；

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

alertmanager.yml

group_wait：初始等待時間，一組告警消息第一次發(fā)送前的等待時間，在這個時間內(nèi)允許為同一組告警收集更多初始告警，此參數(shù)的作用是防止短時間內(nèi)出現(xiàn)大量告警的情況下，接收者被消息淹沒。【此參數(shù)建議設置為0到5分鐘】。

group_interval：睡眠/喚醒周期，一組告警消息被成功發(fā)送后，會進入睡眠/喚醒周期，此參數(shù)是睡眠狀態(tài)將持續(xù)的時間，在睡眠狀態(tài)下該組消息可能會有明細內(nèi)容變化。睡眠結(jié)束后進入喚醒狀態(tài)，如果檢查到有明細內(nèi)容存在變化，則發(fā)送新告警消息；如果沒有變化，則判斷是否達到“重復發(fā)送間隔時間”來決定是否發(fā)送。【此參數(shù)建議設置為5到30分鐘】。

repeat_interval：重復發(fā)送間隔時間，此參數(shù)是指同一個消息組在明細內(nèi)容不變的情況下，連續(xù)多長時間不發(fā)送告警消息。不過此參數(shù)值并不代表告警的實際重復間隔，因為在上一次發(fā)送消息后并等待了“重復發(fā)送間隔時間”的時刻，該消息組可能處在睡眠狀態(tài)；所以實際的告警間隔應該大于“重復發(fā)送間隔時間”且小于“重復發(fā)送間隔時間”與“睡眠/喚醒周期”之和。【此參數(shù)建議設置為3小時以上】。

06本地存儲與遠程存儲

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

6.1.壓縮算法

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

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

6.2.本地存儲文件結(jié)構(gòu)解析

6.3.存儲原理解析

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

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

崩潰后再次啟動會以寫入日志的方式實現(xiàn)重播，從而恢復數(shù)據(jù)。

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

6.4.M3DB遠程存儲技術(shù)

6.4.1.M3特性

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

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

M3 Coordinator：輔助服務，用于協(xié)調(diào)上游系統(tǒng)（如Prometheus和M3DB）之間的讀寫操作，是用戶訪問M3DB的橋梁。

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

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

6.4.2.M3DB特性

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

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

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

自定義壓縮算法M3TSZ float64。

6.4.3.M3DB限制

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

M3DB旨在盡可能避免壓縮，目前M3DB僅在可變壓縮時間序列窗口內(nèi)執(zhí)行壓縮，因此亂序?qū)懭雰H限單個壓縮時間序列窗口的大小。

M3DB針對float64值的存儲和檢索進行優(yōu)化，無法將其用作包含任意數(shù)據(jù)結(jié)構(gòu)的通用時序庫。

6.4.4.M3DB分布式架構(gòu)

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

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

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

07梯度運維管理平臺監(jiān)控模塊架構(gòu)★

審核編輯：彭菁