Prometheus 在分布式監(jiān)控上的實踐，運維請收藏

作者：lxkaka 2022-02-08 10:21:17

在這篇文章中我們介紹了如何利用 Prometheus 監(jiān)控應(yīng)用。在后續(xù)的工作中隨著監(jiān)控的深入，我們結(jié)合自己的經(jīng)驗和官方文檔總結(jié)了一些 Metrics 的實踐。希望這些實踐能給大家提供參考。

使用 Promethues 實現(xiàn)應(yīng)用監(jiān)控的一些實踐

確定監(jiān)控對象

在具體設(shè)計 Metrics 之前，首先需要明確需要測量的對象。需要測量的對象應(yīng)該依據(jù)具體的問題背景、需求和需監(jiān)控的系統(tǒng)本身來確定。

從需求出發(fā)

Google 針對大量分布式監(jiān)控的經(jīng)驗總結(jié)出四個監(jiān)控的黃金指標，這四個指標對于一般性的監(jiān)控測量對象都具有較好的參考意義。這四個指標分別為：

延遲：服務(wù)請求的時間。
通訊量：監(jiān)控當前系統(tǒng)的流量，用于衡量服務(wù)的容量需求。
錯誤：監(jiān)控當前系統(tǒng)所有發(fā)生的錯誤請求，衡量當前系統(tǒng)錯誤發(fā)生的速率。
飽和度：衡量當前服務(wù)的飽和度。主要強調(diào)最能影響服務(wù)狀態(tài)的受限制的資源。例如，如果系統(tǒng)主要受內(nèi)存影響，那就主要關(guān)注系統(tǒng)的內(nèi)存狀態(tài)。

以上四種指標，其實是為了滿足四個監(jiān)控需求：

反映用戶體驗，衡量系統(tǒng)核心性能。如：在線系統(tǒng)的時延，作業(yè)計算系統(tǒng)的作業(yè)完成時間等。
反映系統(tǒng)的吞吐量。如：請求數(shù)，發(fā)出和接收的網(wǎng)絡(luò)包大小等。
幫助發(fā)現(xiàn)和定位故障和問題。如：錯誤計數(shù)、調(diào)用失敗率等。
反映系統(tǒng)的飽和度和負載。如：系統(tǒng)占用的內(nèi)存、作業(yè)隊列的長度等。

除了以上常規(guī)需求，還可根據(jù)具體的問題場景，為了排除和發(fā)現(xiàn)以前出現(xiàn)過或可能出現(xiàn)的問題，確定相應(yīng)的測量對象。比如，系統(tǒng)需要經(jīng)常調(diào)用的一個庫的接口可能耗時較長，或偶有失敗，可制定 Metrics 以測量這個接口的時延和失敗數(shù)。

從需要監(jiān)控的系統(tǒng)出發(fā)

為了滿足相應(yīng)的需求，不同系統(tǒng)需要觀測的測量對象也是不同的。在官方文檔的最佳實踐中，將需要監(jiān)控的應(yīng)用分為了三類：

線上服務(wù)系統(tǒng)（Online-serving systems）：需對請求做即時的響應(yīng)，請求發(fā)起者會等待響應(yīng)。如 web 服務(wù)器。
離線計算系統(tǒng)（Offline processing）：請求發(fā)起者不會等待響應(yīng)，請求的作業(yè)通常會耗時較長。如批處理計算框架 Spark 等。
批處理作業(yè)（Batch jobs）：這類應(yīng)用通常為一次性的，不會一直運行，運行完成后便會結(jié)束運行。如數(shù)據(jù)分析的 MapReduce 作業(yè)。

對于每一類應(yīng)用其通常情況下測量的對象是不太一樣的。其總結(jié)如下：

線上服務(wù)系統(tǒng)：主要有請求、出錯的數(shù)量，請求的時延等。
線下計算系統(tǒng)：最后開始處理作業(yè)的時間，目前正在處理作業(yè)的數(shù)量，發(fā)出了多少 items，作業(yè)隊列的長度等。
批處理作業(yè)：最后成功執(zhí)行的時刻，每個主要 stage 的執(zhí)行時間，總的耗時，處理的記錄數(shù)量等。

除了系統(tǒng)本身，有時還需監(jiān)控子系統(tǒng)：

使用的庫（Libraries）: 調(diào)用次數(shù)，成功數(shù)，出錯數(shù)，調(diào)用的時延。
日志（Logging）：計數(shù)每一條寫入的日志，從而可找到每條日志發(fā)生的頻率和時間。
Failures: 錯誤計數(shù)。
線程池：排隊的請求數(shù)，正在使用的線程數(shù)，總線程數(shù)，耗時，正在處理的任務(wù)數(shù)等。
緩存：請求數(shù)，命中數(shù)，總時延等。

選擇 Vector

選用 Vec 的原則：

數(shù)據(jù)類型類似但資源類型、收集地點等不同
Vec 內(nèi)數(shù)據(jù)單位統(tǒng)一

例子：

不同資源對象的請求延遲
不同地域服務(wù)器的請求延遲
不同 http 請求錯誤的計數(shù)
…

此外，官方文檔中建議，對于一個資源對象的不同操作，如 Read/Write、Send/Receive，應(yīng)采用不同的 Metric 去記錄，而不要放在一個 Metric 里。原因是監(jiān)控時一般不會對這兩者做聚合，而是分別去觀測。不過對于 request 的測量，通常是以 Label 做區(qū)分不同的 action。

確定 Label

常見 Label 的選擇有：

resource
region
type
…

確定 Label 的一個重要原則是：同一維度 Label 的數(shù)據(jù)是可平均和可加和的，也即單位要統(tǒng)一。如風扇的風速和電壓就不能放在一個 Label 里。

此外，不建議下列做法：

my_metric{label=a} 1 my_metric{label=b} 6 my_metric{label=total} 7

即在 Label 中同時統(tǒng)計了分和總的數(shù)據(jù)，建議采用 PromQL 在服務(wù)器端聚合得到總和的結(jié)果。或者用另外的 Metric 去測量總的數(shù)據(jù)。

命名 Metrics 和 Label

好的命名能夠見名知義，因此命名也是良好設(shè)計的一環(huán)。

Metric 的命名：

prometheus_notifications_total
process_cpu_seconds_total
ipamd_request_latency

需要符合 pattern: a-zA-Z:
應(yīng)該包含一個單詞作為前綴，表明這個 Metric 所屬的域。
如：
應(yīng)該包含一個單位的單位作為后綴，表明這個 Metric 的單位。
如：
http_request_duration_seconds
node_memory_usage_bytes
http_requests_total (for a unit-less accumulating count)
邏輯上與被測量的變量含義相同。
盡量使用基本單位，如 seconds，bytes。而不是 Milliseconds, megabytes。

Label 的命名：

依據(jù)選擇的維度命名，如：

region: shenzhen/guangzhou/beijing
owner: user1/user2/user3
stage: extract/transform/load

Buckets 選擇

適宜的 buckets 能使 histogram 的百分位數(shù)計算更加準確。

理想情況下，桶會使得數(shù)據(jù)分布呈階梯狀，即各桶區(qū)間內(nèi)數(shù)據(jù)個數(shù)大致相同。

buckets 的設(shè)計可遵從如下經(jīng)驗：

需要知道數(shù)據(jù)的大致分布，若事先不知道可先用默認桶（{.005, .01, .025, .05, .1, .25, .5, 1, 2.5, 5, 10}）或 2 倍數(shù)桶（{1,2,4,8…}）觀察數(shù)據(jù)分布再調(diào)整 buckets。
數(shù)據(jù)分布較密處桶間隔制定的較窄一些，分布稀疏處可制定的較寬一些。
對于多數(shù)時延數(shù)據(jù)，一般具有長尾的特性，較適宜用指數(shù)形式的桶（ExponentialBuckets）。
初始桶上界一般覆蓋10%左右的數(shù)據(jù)，若不關(guān)注頭部數(shù)據(jù)也可以讓初始上界更大一些。
若為了更準確計算特定百分位數(shù)，如90%，可在90%的數(shù)據(jù)處加密分布桶，即減少桶的間隔。

比如我在監(jiān)控我們某些任務(wù)耗時的時候，就是選根據(jù)實際情況估算出大致的 bucket 取值，上線后觀察數(shù)據(jù)和監(jiān)控再去調(diào)整 bucket，這樣經(jīng)過幾次調(diào)整應(yīng)該就能調(diào)整到比較合適的 bucket。