Prometheus 在分布式監(jiān)控上的實(shí)踐,運(yùn)維請收藏
使用 Promethues 實(shí)現(xiàn)應(yīng)用監(jiān)控的一些實(shí)踐
在這篇文章中我們介紹了如何利用 Prometheus 監(jiān)控應(yīng)用。在后續(xù)的工作中隨著監(jiān)控的深入,我們結(jié)合自己的經(jīng)驗(yàn)和官方文檔總結(jié)了一些 Metrics 的實(shí)踐。希望這些實(shí)踐能給大家提供參考。
確定監(jiān)控對象
在具體設(shè)計(jì) Metrics 之前,首先需要明確需要測量的對象。需要測量的對象應(yīng)該依據(jù)具體的問題背景、需求和需監(jiān)控的系統(tǒng)本身來確定。
從需求出發(fā)
Google 針對大量分布式監(jiān)控的經(jīng)驗(yàn)總結(jié)出四個(gè)監(jiān)控的黃金指標(biāo),這四個(gè)指標(biāo)對于一般性的監(jiān)控測量對象都具有較好的參考意義。這四個(gè)指標(biāo)分別為:
- 延遲:服務(wù)請求的時(shí)間。
- 通訊量:監(jiān)控當(dāng)前系統(tǒng)的流量,用于衡量服務(wù)的容量需求。
- 錯(cuò)誤:監(jiān)控當(dāng)前系統(tǒng)所有發(fā)生的錯(cuò)誤請求,衡量當(dāng)前系統(tǒng)錯(cuò)誤發(fā)生的速率。
- 飽和度:衡量當(dāng)前服務(wù)的飽和度。主要強(qiáng)調(diào)最能影響服務(wù)狀態(tài)的受限制的資源。例如,如果系統(tǒng)主要受內(nèi)存影響,那就主要關(guān)注系統(tǒng)的內(nèi)存狀態(tài)。
以上四種指標(biāo),其實(shí)是為了滿足四個(gè)監(jiān)控需求:
- 反映用戶體驗(yàn),衡量系統(tǒng)核心性能。如:在線系統(tǒng)的時(shí)延,作業(yè)計(jì)算系統(tǒng)的作業(yè)完成時(shí)間等。
- 反映系統(tǒng)的吞吐量。如:請求數(shù),發(fā)出和接收的網(wǎng)絡(luò)包大小等。
- 幫助發(fā)現(xiàn)和定位故障和問題。如:錯(cuò)誤計(jì)數(shù)、調(diào)用失敗率等。
- 反映系統(tǒng)的飽和度和負(fù)載。如:系統(tǒng)占用的內(nèi)存、作業(yè)隊(duì)列的長度等。
除了以上常規(guī)需求,還可根據(jù)具體的問題場景,為了排除和發(fā)現(xiàn)以前出現(xiàn)過或可能出現(xiàn)的問題,確定相應(yīng)的測量對象。比如,系統(tǒng)需要經(jīng)常調(diào)用的一個(gè)庫的接口可能耗時(shí)較長,或偶有失敗,可制定 Metrics 以測量這個(gè)接口的時(shí)延和失敗數(shù)。
從需要監(jiān)控的系統(tǒng)出發(fā)
為了滿足相應(yīng)的需求,不同系統(tǒng)需要觀測的測量對象也是不同的。在 官方文檔 的最佳實(shí)踐中,將需要監(jiān)控的應(yīng)用分為了三類:
- 線上服務(wù)系統(tǒng)(Online-serving systems):需對請求做即時(shí)的響應(yīng),請求發(fā)起者會(huì)等待響應(yīng)。如 web 服務(wù)器。
- 離線計(jì)算系統(tǒng)(Offline processing):請求發(fā)起者不會(huì)等待響應(yīng),請求的作業(yè)通常會(huì)耗時(shí)較長。如批處理計(jì)算框架 Spark 等。
- 批處理作業(yè)(Batch jobs):這類應(yīng)用通常為一次性的,不會(huì)一直運(yùn)行,運(yùn)行完成后便會(huì)結(jié)束運(yùn)行。如數(shù)據(jù)分析的 MapReduce 作業(yè)。
對于每一類應(yīng)用其通常情況下測量的對象是不太一樣的。其總結(jié)如下:
- 線上服務(wù)系統(tǒng):主要有請求、出錯(cuò)的數(shù)量,請求的時(shí)延等。
- 線下計(jì)算系統(tǒng):最后開始處理作業(yè)的時(shí)間,目前正在處理作業(yè)的數(shù)量,發(fā)出了多少 items, 作業(yè)隊(duì)列的長度等。
- 批處理作業(yè):最后成功執(zhí)行的時(shí)刻,每個(gè)主要 stage 的執(zhí)行時(shí)間,總的耗時(shí),處理的記錄數(shù)量等。
除了系統(tǒng)本身,有時(shí)還需監(jiān)控子系統(tǒng):
- 使用的庫(Libraries): 調(diào)用次數(shù),成功數(shù),出錯(cuò)數(shù),調(diào)用的時(shí)延。
- 日志(Logging):計(jì)數(shù)每一條寫入的日志,從而可找到每條日志發(fā)生的頻率和時(shí)間。
- Failures: 錯(cuò)誤計(jì)數(shù)。
- 線程池:排隊(duì)的請求數(shù),正在使用的線程數(shù),總線程數(shù),耗時(shí),正在處理的任務(wù)數(shù)等。
- 緩存:請求數(shù),命中數(shù),總時(shí)延等。
選擇 Vector
選用 Vec 的原則:
- 數(shù)據(jù)類型類似但資源類型、收集地點(diǎn)等不同
- Vec 內(nèi)數(shù)據(jù)單位統(tǒng)一
例子:
- 不同資源對象的請求延遲
- 不同地域服務(wù)器的請求延遲
- 不同 http 請求錯(cuò)誤的計(jì)數(shù)
…
此外,官方文檔 中建議,對于一個(gè)資源對象的不同操作,如 Read/Write、Send/Receive, 應(yīng)采用不同的 Metric 去記錄,而不要放在一個(gè) Metric 里。原因是監(jiān)控時(shí)一般不會(huì)對這兩者做聚合,而是分別去觀測。不過對于 request 的測量,通常是以 Label 做區(qū)分不同的 action。
確定 Label
常見 Label 的選擇有:
- resource
- region
- type
…
確定 Label 的一個(gè)重要原則是:同一維度 Label 的數(shù)據(jù)是可平均和可加和的,也即單位要統(tǒng)一。如風(fēng)扇的風(fēng)速和電壓就不能放在一個(gè) Label 里。
此外,不建議下列做法:
my_metric{label=a} 1 my_metric{label=b} 6 my_metric{label=total} 7
即在 Label 中同時(shí)統(tǒng)計(jì)了分和總的數(shù)據(jù),建議采用 PromQL 在服務(wù)器端聚合得到總和的結(jié)果?;蛘哂昧硗獾?Metric 去測量總的數(shù)據(jù)。
命名 Metrics 和 Label
好的命名能夠見名知義,因此命名也是良好設(shè)計(jì)的一環(huán)。
Metric 的命名:
- prometheus_notifications_total
- process_cpu_seconds_total
- ipamd_request_latency
- 需要符合 pattern: a-zA-Z:
- 應(yīng)該包含一個(gè)單詞作為前綴,表明這個(gè) Metric 所屬的域。
如: - 應(yīng)該包含一個(gè)單位的單位作為后綴,表明這個(gè) 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ù)計(jì)算更加準(zhǔn)確。
理想情況下,桶會(huì)使得數(shù)據(jù)分布呈階梯狀,即各桶區(qū)間內(nèi)數(shù)據(jù)個(gè)數(shù)大致相同。
buckets 的設(shè)計(jì)可遵從如下經(jīng)驗(yàn):
- 需要知道數(shù)據(jù)的大致分布,若事先不知道可先用默認(rèn)桶 ({.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í)延數(shù)據(jù),一般具有長尾的特性,較適宜用指數(shù)形式的桶(ExponentialBuckets)。
- 初始桶上界一般覆蓋10%左右的數(shù)據(jù),若不關(guān)注頭部數(shù)據(jù)也可以讓初始上界更大一些。
- 若為了更準(zhǔn)確計(jì)算特定百分位數(shù),如90%,可在90%的數(shù)據(jù)處加密分布桶,即減少桶的間隔。
比如我在監(jiān)控我們某些任務(wù)耗時(shí)的時(shí)候,就是選根據(jù)實(shí)際情況估算出大致的 bucket 取值,上線后觀察數(shù)據(jù)和監(jiān)控再去調(diào)整 bucket, 這樣經(jīng)過幾次調(diào)整應(yīng)該就能調(diào)整到比較合適的 bucket。
Grafana 使用技巧
查看所有維度
如果你想知道是否還能按其它維度分組,并快速查看還有哪些維度,可采用以下技巧:在 query 的表達(dá)式上只保留指標(biāo)名稱,不做任何計(jì)算,Legend format 也留空。這樣就能顯示出原始的 metric 數(shù)據(jù)。如下圖所示
標(biāo)尺聯(lián)動(dòng)
在 Settings 面板中,有一個(gè) Graph Tooltip 設(shè)置項(xiàng),默認(rèn)使用 Default。
下面將圖形展示工具分別調(diào)整為 Shared crosshair 和 Shared Tooltip 看看效果??梢钥吹綐?biāo)尺能聯(lián)動(dòng)展示了,方便排查問題時(shí)確認(rèn) 2 個(gè)指標(biāo)的關(guān)聯(lián)性。
將圖形展示工具調(diào)整為 Shared Tooltip: