導(dǎo)讀

本文由梯度科技云管研發(fā)部高級(jí)工程師周宇明撰寫(xiě)，共分為7章，緊密?chē)@Prometheus的基本原理與開(kāi)發(fā)指南展開(kāi)介紹：

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

Prometheus入門(mén)

PromQL入門(mén)

PromQL高級(jí)實(shí)戰(zhàn)

告警引擎深度解析

本地存儲(chǔ)與遠(yuǎn)程存儲(chǔ)

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

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

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

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

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

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

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

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

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

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

1.1.1.Metrics（指標(biāo)）

定義：可進(jìn)行聚合計(jì)算的原子型數(shù)據(jù)，通常通過(guò)多個(gè)標(biāo)簽值來(lái)確定指標(biāo)唯一性。

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

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

1.1.2.Logging（日志）

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

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

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

1.1.3.Tracing（鏈路）

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

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

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

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

1.3.1.Zabbix

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

優(yōu)點(diǎn)：

平臺(tái)兼容性好，可運(yùn)行在 Windows、Linux、Solaris、AIX、OS X等平臺(tái)上；

架構(gòu)簡(jiǎn)單，易于維護(hù)、備份。

缺點(diǎn)：

使用數(shù)據(jù)庫(kù)存儲(chǔ)，無(wú)法水平擴(kuò)展，容量有限；

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

1.3.2.Open-Falcon

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

優(yōu)點(diǎn)：

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

Go語(yǔ)言開(kāi)發(fā)，易于二次開(kāi)發(fā)。

缺點(diǎn)：

組件拆分比較散，部署相對(duì)比較麻煩；

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

1.3.3.Prometheus

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

Prometheus2.0版本開(kāi)始，重新設(shè)計(jì)了時(shí)序庫(kù)，性能和可靠性都大幅提升。

優(yōu)點(diǎn)：

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

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

缺點(diǎn)：

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

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

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

1.4.1.采集器 ★

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

Telegraf：

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

Telegraf 是指標(biāo)領(lǐng)域的 All-In-One 采集器，支持各種采集插件，只需要使用這一個(gè)采集器，就能解決絕大部分采集需求；

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

Exporter：

Exporter是專(zhuān)門(mén)用于Prometheus 生態(tài)的采集器，但是比較零散，每個(gè)采集目標(biāo)都有對(duì)應(yīng)的 Exporter 組件，比如 MySQL 有 mysqld_exporter，Redis 有 redis_exporter，JVM 有 jmx_exporter。

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

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

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

Grafana-Agent：

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

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

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

1.4.2.時(shí)序庫(kù)

PrometheusTSDB

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

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

InfluxDB

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

不過(guò) InfluxDB 開(kāi)源版本是單機(jī)的，沒(méi)有開(kāi)源集群版本。

M3DB

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

1.4.3.告警引擎 ★

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

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

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

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

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

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

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

02Prometheus入門(mén)

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

2.1．主要特點(diǎn)

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

定義了開(kāi)放指標(biāo)數(shù)據(jù)的標(biāo)準(zhǔn)，自定義探針（Exporter等）；

Go語(yǔ)言編寫(xiě)，擁抱云原生；

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

二進(jìn)制文件直接啟動(dòng)、也支持容器鏡像化部署；

支持多種語(yǔ)言客戶(hù)端；

支持本地和第三方遠(yuǎn)程存儲(chǔ)、高效的存儲(chǔ)；

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

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

精確告警：基于PromQL可以進(jìn)行告警設(shè)置、預(yù)測(cè)等；另外還提供了分組、抑制、靜默等功能防止告警風(fēng)暴；

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

2.2. 局限性

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

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

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

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

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

Job/Exporter

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

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

PushGateway

是支持臨時(shí)性job主動(dòng)推送指標(biāo)的中間網(wǎng)關(guān)。

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

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

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

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

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

i.Retrieval（抓?。?/p>

從Job、Exporter、PushGateway3個(gè)組件中通過(guò)HTTP輪詢(xún)的形式拉取指標(biāo)數(shù)據(jù)；

ii.Storage（存儲(chǔ)）

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

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

iii.PromQL（查詢(xún)）

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

Dashboard（可視化）

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

Alertmanager（告警引擎）

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

03PromQL入門(mén)

導(dǎo)讀：本章圍繞PromQL基本概念、4大選擇器、4大指標(biāo)類(lèi)型及13種聚合操作等展開(kāi)介紹，幫助讀者輕松理解PromQL相關(guān)知識(shí)。

3.1.初識(shí)PromQL ★

3.1.1.時(shí)間序列 ★

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

每條時(shí)間序列是通過(guò)指標(biāo)名稱(chēng)和一組標(biāo)簽集來(lái)命名的。

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

指標(biāo)（Metrics）：包括指標(biāo)名稱(chēng)（__name__）和一組標(biāo)簽集名稱(chēng)；

時(shí)間戳（TimeStamp）：默認(rèn)精確到毫秒；

樣本值（Value）：默認(rèn)使用64位浮點(diǎn)類(lèi)型。

3.1.2.指標(biāo) ★

時(shí)間序列的指標(biāo)可以基于Bigtable設(shè)計(jì)為Key-Value存儲(chǔ)的方式：

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

分別對(duì)應(yīng)的查詢(xún)形式（以下兩個(gè)查詢(xún)語(yǔ)句等價(jià)）：

3.2. 4大選擇器

3.2.1.匹配器

相等匹配器（=）：對(duì)于不存在的標(biāo)簽可以使用Label=""的形式查詢(xún)

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

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

所有PromQL語(yǔ)句必須包含至少一個(gè)有效表達(dá)式（至少一個(gè)不會(huì)匹配到空字符串的標(biāo)簽過(guò)濾器），因此，以下三種示例是非法的：

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

3.2.2.瞬時(shí)向量選擇器

用于返回在指定時(shí)間戳之前查詢(xún)到的最新樣本的瞬時(shí)向量。

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

高級(jí)應(yīng)用：

3.2.4.偏移量修改器

瞬時(shí)偏移向量

高級(jí)應(yīng)用：

3.3. 4大指標(biāo)類(lèi)型 ★

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

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

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

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

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

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

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

3.3.2.儀表盤(pán)（Gauge） ★

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

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

3.3.3.直方圖（Histogram） ★

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

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

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

Histogram 這種做法性能有了巨大的提升，但是要同時(shí)計(jì)算成千上萬(wàn)個(gè)接口的分位值延遲數(shù)據(jù)，還是非常耗費(fèi)資源的，甚至?xí)斐煞?wù)端 OOM。

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

3.3.4.匯總（Summary） ★

在客戶(hù)端計(jì)算分位值，然后把計(jì)算之后的結(jié)果推給服務(wù)端存儲(chǔ)，展示的時(shí)候直接查詢(xún)即可。

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

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

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

3.4.13種聚合操作

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

sum

min

max

avg

count

count_values（對(duì)value進(jìn)行計(jì)數(shù)）

stddev（標(biāo)準(zhǔn)差）

stdvar（標(biāo)準(zhǔn)差異）

bottomk（樣本值最小k個(gè)元素）

topk（樣本值最大k個(gè)元素）

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

3.4.1.without、by★

上述兩個(gè)查詢(xún)是等價(jià)的；同一個(gè)聚合語(yǔ)句中不可同時(shí)使用by和without，by的作用類(lèi)似于sql語(yǔ)句中的分組（group by），without語(yǔ)義是：除開(kāi)XX標(biāo)簽，對(duì)剩下的標(biāo)簽進(jìn)行分組。

3.4.2.stdvar

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

3.4.3.stddev

標(biāo)準(zhǔn)差：用方差開(kāi)算術(shù)平方根。

3.4.4.count、count_values

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

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

3.4.5.quantile

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

3.5.3種二元操作符

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

3.5.2.集合/邏輯運(yùn)算符

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

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

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

3.5.3.比較運(yùn)算符（== !=> < ?>= <=），無(wú)需過(guò)多解釋

04PromQL高級(jí)實(shí)戰(zhàn)

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

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

4.1.1.動(dòng)態(tài)標(biāo)簽函數(shù) ★

提供了對(duì)時(shí)間序列標(biāo)簽的自定義能力。

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

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

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

4.1.3.多對(duì)多運(yùn)算算函數(shù)（absent，常用于檢測(cè)服務(wù)是否存活）

4.1.4.Counter函數(shù)

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

4.1.5.Gauge函數(shù)

predict_linear(v range-vector, t scalar)

預(yù)測(cè)時(shí)間序列v在t秒后的值

deriv(v range-vector)

使用簡(jiǎn)單的線(xiàn)性回歸計(jì)算區(qū)間向量v中各個(gè)時(shí)間序列的導(dǎo)數(shù)

delta(v range-vector)

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

idelta(v range-vector)

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

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

要求sf > 0, tf <= 1

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

changes(v range-vector)

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

prometheus提供度量標(biāo)準(zhǔn)process_start_time_seconds記錄每一個(gè)targets的啟動(dòng)時(shí)間，該時(shí)間被更改則意味著進(jìn)程重啟，可以發(fā)出循環(huán)崩潰告警：

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

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

4.2.HTTPAPI ★

4.2.1.API響應(yīng)格式

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

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

4.2.2.表達(dá)式查詢(xún)

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

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

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

入?yún)ⅲ篜romQL表達(dá)式、起始時(shí)間戳、結(jié)束時(shí)間戳、查詢(xún)時(shí)間步長(zhǎng)（不能超過(guò)11000）、超時(shí)設(shè)置（可全局設(shè)置）

4.2.3.其他拓展

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

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

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

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

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

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

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

TSDB管理API

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

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

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ī)則

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

4.3.2.告警規(guī)則

4.4.指標(biāo)的抓取與存儲(chǔ) ★

抓取前依賴(lài)服務(wù)發(fā)現(xiàn)，通過(guò)relabel_configs的方式自動(dòng)對(duì)服務(wù)發(fā)現(xiàn)的目標(biāo)進(jìn)行重新標(biāo)記；

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

4.4.1.用relabel_configs抓取指標(biāo) ★

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

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

05告警引擎深度解析

導(dǎo)讀：本章拓展了Alertmanager架構(gòu)解析、Alertmanager配置文件、告警應(yīng)用與問(wèn)題處理等眾多知識(shí)點(diǎn)。

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

從左上開(kāi)始，Prometheus 發(fā)送的警報(bào)到 Alertmanager;

警報(bào)會(huì)被存儲(chǔ)到 AlertProvider 中，Alertmanager 的內(nèi)置實(shí)現(xiàn)就是包了一個(gè) map，也就是存放在本機(jī)內(nèi)存中，這里可以很容易地?cái)U(kuò)展其它 Provider;

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

分組會(huì)定時(shí)進(jìn)行 flush (間隔為配置參數(shù)中的 group_interval), flush 后這組警報(bào)會(huì)走一個(gè) Notification Pipeline 鏈?zhǔn)教幚?

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

5.2.Alertmanager配置文件解讀 ★

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

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

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

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

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

5.3.關(guān)于告警的應(yīng)用與問(wèn)題處理 ★

關(guān)鍵配置參數(shù)：

prometheus.yml

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

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

evaluation_interval：評(píng)估告警規(guī)則的時(shí)間間隔（即多長(zhǎng)時(shí)間計(jì)算一次告警規(guī)則是否觸發(fā)），默認(rèn)1分鐘；

alertmanager.yml

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

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

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

06本地存儲(chǔ)與遠(yuǎn)程存儲(chǔ)

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

6.1.壓縮算法

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

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

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

6.3.存儲(chǔ)原理解析

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

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

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

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

6.4.M3DB遠(yuǎn)程存儲(chǔ)技術(shù)

6.4.1.M3特性

主要包括4個(gè)組件：M3DB、M3 Coordinator、M3 Query、M3 Aggregator

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

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

M3 Query：分布式查詢(xún)引擎，可查詢(xún)實(shí)時(shí)和歷史指標(biāo)，支持多種不同的查詢(xún)語(yǔ)言（包括PromQL）。

M3 Aggregator：聚合層，作為專(zhuān)用度量聚合器運(yùn)行的服務(wù)。

6.4.2.M3DB特性

分布式時(shí)間序列存儲(chǔ)，單個(gè)節(jié)點(diǎn)使用WAL提交日志并獨(dú)立保存每個(gè)分片的時(shí)間窗口。

集群管理建立在etcd之上（分布式服務(wù)注冊(cè)中心）。

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

自定義壓縮算法M3TSZ float64。

6.4.3.M3DB限制

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

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

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

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

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

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

Seed Node：首先，這些主機(jī)本身就是存儲(chǔ)節(jié)點(diǎn)。除了該職責(zé)外，他們還運(yùn)行嵌入式ETCD服務(wù)器。這是為了允許跨集群運(yùn)行的各種M3DB進(jìn)程以一致的方式推斷集群的拓?fù)?配置。

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

審核編輯：彭菁