摘要：普羅米修斯是誰(shuí)在希臘神話中，是泰坦神族的神明之一，名字的意思是先見(jiàn)之明。普羅米修斯與智慧女神雅典娜共同創(chuàng)造了人類，普羅米修斯負(fù)責(zé)用泥土雕塑出人的形狀，雅典娜則為泥人灌注靈魂，并教會(huì)了人類很多知識(shí)。

普羅米修斯是誰(shuí)？

From Wikipedia：在希臘神話中，是泰坦神族的神明之一，名字的意思是“先見(jiàn)之明”。普羅米修斯與智慧女神雅典娜共同創(chuàng)造了人類，普羅米修斯負(fù)責(zé)用泥土雕塑出人的形狀，雅典娜則為泥人灌注靈魂，并教會(huì)了人類很多知識(shí)。

Prometheus 是什么？

Prometheus 是一個(gè)由 SoundCloud 公司開(kāi)發(fā)并開(kāi)源的監(jiān)控和告警工具。主要功能包括監(jiān)控指標(biāo)的收集，存儲(chǔ)，查詢以及以此為基礎(chǔ)的告警管理，其內(nèi)部包含一個(gè)用來(lái)存儲(chǔ)指標(biāo)的單機(jī)時(shí)序數(shù)據(jù)庫(kù)。它的開(kāi)發(fā)受到了Google內(nèi)部監(jiān)控系統(tǒng) Borgmon 的啟發(fā)。

Borgman 的特點(diǎn)是不使用特定的腳本來(lái)判斷系統(tǒng)是否正常工作，而是依靠一種標(biāo)準(zhǔn)數(shù)據(jù)分析模型進(jìn)行報(bào)警。這使得批量、大規(guī)模、低成本的數(shù)據(jù)收集變得可能，而不需要執(zhí)行復(fù)雜的子進(jìn)程以及建立特殊的網(wǎng)絡(luò)鏈接。

利用 Prometheus 和自動(dòng)服務(wù)發(fā)現(xiàn)， 我們可以采用 pull mode 而不是 push mode 來(lái)收集服務(wù)的指標(biāo)，pull mode 對(duì)于服務(wù)端的實(shí)現(xiàn)成本更低。

閑言：一個(gè)系統(tǒng)是采用 pull mode 還是 push mode 是很值得思考的問(wèn)題。pull mode 的實(shí)現(xiàn)可能更簡(jiǎn)單，數(shù)據(jù)的提供方只需要被動(dòng)的等待數(shù)據(jù)的需求方來(lái)拉取數(shù)據(jù)就可以了，減少了很多 sync 的工作，但是因?yàn)闀?huì)在 pipeline 產(chǎn)生 bubble，性能可能會(huì)不好。而 push mode 會(huì)使 pipeline 開(kāi)足馬力運(yùn)行，會(huì)帶來(lái)更好的性能，但同時(shí)會(huì)增加系統(tǒng)設(shè)計(jì)的復(fù)雜度，比如 sync，retry 等工作。

為什么要監(jiān)控

Google SRE 這本書(shū)中介紹主要有四個(gè)原因：

1. 分析長(zhǎng)期趨勢(shì)
2. 跨時(shí)間范圍的比較
3. 構(gòu)建監(jiān)控頁(yè)面
4. 臨時(shí)性的回溯分析（在線調(diào)試）

四個(gè)黃金指標(biāo)

同樣來(lái)自 Google SRE 一書(shū)：

1. 延遲

? 服務(wù)處理某個(gè)請(qǐng)求所需要的時(shí)間。需要區(qū)分成功請(qǐng)求和失敗請(qǐng)求很重要。2

2.流量

? 使用系統(tǒng)中的某個(gè)高層次的指標(biāo)針對(duì)系統(tǒng)負(fù)載進(jìn)行的度量。

3.錯(cuò)誤

? 請(qǐng)求失敗的頻率，可以是顯示失敗（例如HTTP 500），隱式失敗（例如HTTP 200 但是包含了錯(cuò)誤內(nèi)容）或者是某種策略原因?qū)е碌氖。ɡ珥憫?yīng)超時(shí)）

4.飽和度

? 衡量服務(wù)容量有多“滿”，通常是系統(tǒng)中最為受限的某種資源的某個(gè)具體指標(biāo)的度量（比如內(nèi)存，IO）。

碎語(yǔ)：一本好書(shū)

Prometheus 的數(shù)據(jù)模型

Prometheus 將收集的監(jiān)控指標(biāo)數(shù)據(jù)作為時(shí)序數(shù)據(jù)進(jìn)行存儲(chǔ)，一條時(shí)序數(shù)據(jù)流（stream）由指標(biāo)名稱（metric name）和標(biāo)簽（label）以及被打賞時(shí)間戳的數(shù)據(jù)組成：

{=, ...}

例如用來(lái)記錄一個(gè) API 網(wǎng)關(guān)中注冊(cè)的一臺(tái)服務(wù)器的健康狀態(tài)（1 代表健康）：

api_gray_gateway_upstream_health{usptream="product-test",id="0",name="192.168.152.194:8000",backup="false"} 1
api_gray_gateway_upstream_health{usptream="product-test",id="1",name="192.168.152.195:8000",backup="false"} 0

通過(guò)這種簡(jiǎn)單的數(shù)據(jù)模型我們可以組合出四種典型的指標(biāo)類型。

1. Counter：一種累加的指標(biāo)，這種指標(biāo)只能增加或者在重啟時(shí)重置為0。可以用來(lái)記錄請(qǐng)求數(shù)。結(jié)合rate函數(shù)可以計(jì)算出請(qǐng)求速率
2. Gauge：一種可增可減的指標(biāo)，通常用來(lái)記錄系統(tǒng)的某種狀態(tài)，比如記錄CPU使用率
3. Histogram：柱狀圖，某一指標(biāo)的區(qū)間分布情況：這是一個(gè)復(fù)合的指標(biāo)，由total sum，count 以及不同的 bucket 組成，例如：

1. Summary：分位數(shù)，某一指標(biāo)的 50%分位數(shù)（中位數(shù)），90%分位數(shù)和99%分位數(shù)等，分位數(shù)還可以使用 histogram_quantile 函數(shù)由 histogram 近似計(jì)算得到，區(qū)別是會(huì)有一定的誤差，但是 histogram 計(jì)算在服務(wù)端的開(kāi)銷(xiāo)更小（服務(wù)端只需要統(tǒng)計(jì)次數(shù)，而不需要計(jì)算分位數(shù)），例如：

一些實(shí)際應(yīng)用

利用 Prometheus 展示 HTTP 網(wǎng)關(guān)托管的后端服務(wù)器健康狀態(tài)

我們的 HTTP 網(wǎng)關(guān)是使用 OpenResty 實(shí)現(xiàn)的，具有良好的擴(kuò)展性。實(shí)現(xiàn)這一特性，只需要在 /metrics 接口中增加查詢后端服務(wù)器狀態(tài)的邏輯（使用 lua-upstream-nginx-module 模塊的 API），并使用Gauge 類型的指標(biāo)記錄健康狀態(tài)，然后將結(jié)果返回給Prometheus，如：

最后在 Grafana 中（Prometheus作為數(shù)據(jù)源）建立圖表，還可以通過(guò)設(shè)置一些變量方便業(yè)務(wù)方查詢不同的 Upstream 中 Server 的健康狀態(tài)，當(dāng)然這里的圖表還可以更美觀一些（我用的 Grafana 版本有點(diǎn)老）并且集成到其他 WEB 頁(yè)面中，下圖中狀態(tài) 1 表示 Server 健康，0 表示不健康。

在這個(gè)應(yīng)用中，我利用了 Prometheus 簡(jiǎn)單的編程模型和查詢能力，以及 Grafana 的圖表生成能力，快速構(gòu)建了監(jiān)控系統(tǒng)。

TiDB Peer 遷移限速模塊中的指標(biāo)設(shè)計(jì)的改進(jìn)

背景：TiDB 是一個(gè)由 Pingcap 公司主導(dǎo)的開(kāi)源分布式 NewSQL 數(shù)據(jù)庫(kù)，TiDB 使用 TiKV 作為存儲(chǔ)。TiKV 一個(gè)由 Pingcap 公司主導(dǎo)的開(kāi)源分布式 Key-value 數(shù)據(jù)庫(kù)。Raft是 一個(gè)工業(yè)領(lǐng)域內(nèi)常用的分布式一致性算法，而 TiKV 使用的正是 Raft 算法，更具體的是一種 Multi Raft Group。下圖的示例中，每個(gè) Store 是一個(gè)實(shí)際的存儲(chǔ)節(jié)點(diǎn)（一個(gè)進(jìn)程），因?yàn)樾阅艿脑驍?shù)據(jù)會(huì)分成多個(gè) Region 存儲(chǔ)（不同 Region 存儲(chǔ)不同 Key 范圍的數(shù)據(jù)），為了實(shí)現(xiàn)高可用同一個(gè) Region 的數(shù)據(jù)在不同的 Store 中會(huì)有多個(gè)副本（Peer），同一個(gè) Region 的不同 Peer 構(gòu)成一個(gè) Raft 共識(shí)：

當(dāng)我們需要對(duì)系統(tǒng)進(jìn)行擴(kuò)容時(shí)，可以添加一個(gè) Store，并由 PD （Placement Driver for TiKV）完成 Region 的 Peer 在 Store 中分布的調(diào)整。這些調(diào)整是在線調(diào)整的，如果 Peer 的遷移速度過(guò)快會(huì)影響系統(tǒng)的性能，因而需要對(duì)速度進(jìn)行限制，PD 中采用了令牌桶算法實(shí)現(xiàn)了限速的特性。

為了監(jiān)控限速模塊的工作狀態(tài)，需要設(shè)計(jì)一些監(jiān)控指標(biāo)。我在 https://github.com/pingcap/pd/pull/2404 這個(gè) PR 中完成了對(duì)限速模塊監(jiān)控指標(biāo)的改進(jìn)。

改進(jìn)后的指標(biāo)有：

1. storeLimitAvailableGauge：記錄當(dāng)前限速器中的可用令牌數(shù)
2. storeLimitRateGauge：記錄當(dāng)前設(shè)置的速率
3. storeLimitCostCounter：記錄累計(jì)的 Peer 遷移的開(kāi)銷(xiāo)

指標(biāo)收集的時(shí)機(jī)：

1. storeLimitAvailableGauge 和 storeLimitRateGauge：使用協(xié)程周期性地更新
2. storeLimitCostCounter：在系統(tǒng)發(fā)生Region遷移時(shí)更新

這里我們需要關(guān)注的是需要根據(jù)指標(biāo)的含義選擇指標(biāo)類型，需要合理利用不同指標(biāo)類型，收集與之相適應(yīng)的監(jiān)控?cái)?shù)據(jù)。

思考：在工作之余參與其他開(kāi)源項(xiàng)目（比如 TiDB，Kubernetes）可以開(kāi)拓視野，收獲行業(yè)內(nèi)的一些先進(jìn)經(jīng)驗(yàn)，避免思維的僵化。

總結(jié)

本文介紹了 Prometheus 的特定，數(shù)據(jù)模型，指標(biāo)類型以及監(jiān)控指標(biāo)設(shè)計(jì)方面的準(zhǔn)則，以及一些閑言碎語(yǔ)。最后介紹了兩個(gè)實(shí)際工作和業(yè)余參與的開(kāi)源項(xiàng)目中的實(shí)際應(yīng)用。

本文作者：

王任錚 UCloud 后臺(tái)研發(fā)工程師