目錄

一、?Prometheus組件及架構

1.? Prometheus server 服務端

2.? Pushgateway?推送網關

3.? Alertmanager?警報管理器

4.? Prometheus targets 數據采集

5.? Data visualization and export?數據可視化和導出

6.? When does it fit? 適合場景

7.? When does it not fit? 不適合場景

二、?Prometheus數據模型

1. 時間序列數據（帶時間戳的數據）

2. 時間序列的數據庫

3. Prometheus的本地存儲

1. 數據流

2. 布局

4. Prometheus數據模型

1. 表示法

2. Metirc names

3. Metric Labels

4. Samples

三、?核心的指標

1. 什么是指標

2. 指標的類型-3種

1. Counter:（累加）統計

2. Gauge：測量

3. Histogram：柱狀圖

4. Summaries

四、?指標摘要及聚合

1. 指標的摘要

2. 指標聚合

?點擊進入課程目錄

---

一、?Prometheus組件及架構

官網：Prometheus - Monitoring system & time series database

1.? Prometheus server 服務端

????????作用：抓取和存儲時間序列數據

2.? Pushgateway?推送網關

????????作用：推送一些Prometheus無法抓取的數據

3.? Alertmanager?警報管理器

????????作用：警報閾值的設置與發送

4.? Prometheus targets 數據采集

5.? Data visualization and export?數據可視化和導出

• Prometheus web Ul：Prometheus 自帶數據可視化
• Grafana：數據可視化（推薦）
• API clients：

6.? When does it fit? 適合場景

????????Prometheus works well for recording any purely numeric time series. It fits both machine-centric monitoring as well as monitoring of highly dynamic service-oriented architectures. In a world of microservices, its support for multi-dimensional data collection and querying is a particular strength.

????????Prometheus is designed for reliability, to be the system you go to during an outage to allow you to quickly diagnose problems. Each Prometheus server is standalone, not depending on network storage or other remote services. You can rely on it when other parts of your infrastructure are broken, and you do not need to setup extensive infrastructure to use it.

7.? When does it not fit? 不適合場景

????????Prometheus values reliability. You can always view what statistics are available about your system, even under failure conditions. If you need 100% accuracy, such as for per-request billing, Prometheus is not a good choice as the collected data will likely not be detailed and complete enough. In such a case you would be best off using some other system to collect and analyze the data for billing, and Prometheus for the rest of your monitoring.

二、?Prometheus數據模型

????????我們需要了解是什么構成了時間序列以及如何存儲這些數據。

1. 時間序列數據（帶時間戳的數據）

????????時間序列數據通常可以定義為一個數字數據點的序列，這些數據點按時間順序從同一來源索引。在Prometheus的范用內這些數據點是在固定的時間間隔內收集的。因此，這種數據以圖形形式表示時，通常會繪制數據隨時間的演變，X軸表示時間，y軸表示數據值。

2. 時間序列的數據庫

????????在處理來自收集器和傳感器(如組成物聯網的那些)的大量數據時，如果數據庫沒有在設計時考慮到用例，那么查詢結果數據集的速度會非常慢。雖說可以使用其它的關系型數據庫，但是查詢速度往往不理想。

因此，現代時間序列數據庫存儲以下組件:
時間戳
值
關于值的一些上下文，以度量名稱或關聯的鍵/值對進行編碼

一個符合時間序列數據庫規范的抽象數據示例如下:

timestamp=1544978108，company=ACME，location=headquarters,beverage=coffee，walue=40172

3. Prometheus的本地存儲

????????本地存儲是在prometheus存儲數據的標準方法，因此，我們必須了解它的基礎知識。在一個非常高的層次上，Prometheus的存儲設計是一個索引實現的組合，它使用了所有當前存儲的標簽及其值的發布列表，以及它自己的時間序列數據格式

1. 數據流

????????prometheus 在本地存儲收集到的數據的方式可以被看作是一個分為三個部分的過程。下面的主題描述了數據在成功持久化之前所經歷的各個階段。

• 內存

????????最新鮮的一批數據保存在內存中長達兩個小時。這包括在兩個小時時間窗口期間收集的一個或多個數據塊。這種方法極大地減少了磁盤I/O的消耗;最新的數據存儲在內存中，查詢速度快得驚人;數據塊是在內存中創建的，避免了持續的磁盤寫操作。

• 預寫日志

????????而在內存中，數據不是持久的，如果進程非正常終止，數據可能會丟失。為了防止這種情況，磁盤上的write-ahead Iog(WAL)會保持內存數據的狀態，以便在prometheus 因任何原因崩潰或重新啟動時可以重播它。

• 磁盤

????????在兩個小時的時間窗口之后，塊被寫入磁盤。這些塊是不可變的，即使數據可以刪除，它也不是原子操作。相反,tombstone文件是用不再需要的數據信息創建的。

2. 布局

????????我們在下面的例子中可以看到，Prometheus中數據的存儲方式被組織到一系列目錄(塊)中，這些目錄(塊)包含了數據塊，這些數據的LeveIDB索引就是一個元數據。帶有人類可讀的關于塊的信息的json文件，以及不再需要的數據的tombstone。每個塊代表一個數據庫。

4. Prometheus數據模型

正如我們到目前為止所看到的，Prometheus將數據存儲為時間序列，其中包括稱為

• 度量名稱 :?Metirc names
• 標簽鍵值對
• 數據卷的范圍：<datapoint_numerical_value>

下面的主題將對這些組件進行擴展，并提供每個組件的基礎知識，我們將在第7章深入使用這些基礎知識，即Prometheus查詢語言一PromQL，專門用于PromQL。

1. 表示法

Prometheus的時間序列如下:

<metric_name>[{<label_1="value_1">,<label_N="value_N">}] <datapoint_numerical_value>

如下案例:

api_http_requests_total{method="PosT",handler="/messages"}

????????如您所見，它表示為一個度量名稱，后跟一組或多組花括號內的標簽名稱/值，然后是度量的值。此外，樣本還具有亳秒精度的時間戳。

2. Metirc names

????????盡管這是一個實現細節，度量名稱只不過是一個名為“name”的特殊標簽的值。因此，如果您在內部有一個名為“beverages_total”的度量，它被表示為”_name=beverages_total”。請記住，被“"”包圍的標簽是Prometheus內部的，任何以“__”為前綴的標簽只在度量收集周期的某些階段可用。

標簽(鍵/值)和度量名稱的組合定義了時間序列的標識。

Prometheus中的每一個度量名稱都必須符合以下正則表達式

"[a-zA-Z_:][a-zA-Z0-9_:]*"

3. Metric Labels

????????標簽，或與某個度量相關的鍵/值對，向度量添加維度。這是普羅米修斯如此擅長對時間序列進行切片和切割的一個重要部分

????????雖然標簽值可以是完整的UTF-8，但標簽名稱必須與正則表達式匹配才能被認為是有效的;[例如,“-za-z0-9_:]*"

????????它們在度量名稱方面的主要區別是標簽名稱不允許冒號(:)。

4. Samples

????????樣本是采集的數據點，代表時間序列數據的數值。定義一個示例所需的組件是一個flIoat64值和一個精確到毫秒的時間戳。需要記住的是，不按順序收集的樣本會被普羅米修斯丟棄。同樣的情況也發生在具有相同度量單位和不同樣本值的樣本上.

三、?核心的指標

1. 什么是指標

? ? ? ? 軟件或硬件屬性的度量

2. 指標的類型-3種

1. Counter:（累加）統計

• Prometheus 實例接收的數據包總數:（網卡流出總量）

2. Gauge：測量

????????測量是一種度量，它在收集時對給定的測量進行快照，可以增加或減少

(例如溫度、磁盤空間和內存使用量).

如果刮擦失敗，您將丟失該樣本，因為下一次刮擦可能會遇到不同值(更高/更低)的度量。

為了幫助可視化這種類型的度量，下面是一些基于我們在前一章中創建的測試環境的量規及其圖形表示示例:

• Alertmanager實例上建立的TCP連接數量:

• grafana實例上的空閑內存量 一注意由實例重新啟動引起的中間空白，防止在此期間對可能的值進行任何假設

3. Histogram：柱狀圖

在大多數情況下人們都傾向于使用某些量化指標的平均值，例如 CPU 的平均使用率、頁面的平均響應時間。這種方式的問題很明顯，以系統 API 調用的平均響應時間為例:如果大多數 API 請求都維持在 100ms 的響應時間范圍內，而個別請求的響應時間需要 5s，那么就會導致某些 WEB 頁面的響應時間落到中位數的情況，而這種現象被稱為長尾問題。

Histogram常常用于觀察，一個Histrogram包含下列值的合并:

Buckets: 桶是觀察的計數器。它應該有個最大值的邊界和最小值的邊界。它的格式為《basename>_bucket{le=!<bound_value>"

觀察結果的和，這是所有觀察的和。針對它的格式是《basename>_sum

觀察結果統計，這是在本次觀察的和。它的格式為《basename>_count

• 一個普羅米修斯HTTP請求持續時間以秒為單位，分為桶。這是顯示在Grafana熱圖，以更好地說明桶的概念

4. Summaries

與Histogram 類型類似（占百分比），用于表示一段時間內的數據采樣結果(通常是請求持續時間或響應大小等)，但它直接存儲了分位數(通過客戶端計算，然后展示出來)，而不是通過區間來計算。

為了幫助可視化這種類型的度量，下面是一個基于我們在前一章中創建的測試環境的摘要及其圖形表示示例:

• 普羅米修斯規則組的最大持續時間(以秒為單位):

四、?指標摘要及聚合

1. 指標的摘要

????????通常來說，單個指標對我們價值很小，往往需要聯合并可視化多個指標(來定位或預判問題)，這其中需要一些數學變換，例如，我們可能會統計函數應用于指標或指標組，一些可能應用常見函數包括:

• 計數 : 計算特定時間間隔內的觀察點數。
• 求和 : 將特定時間間隔內所有觀察點的值累計相加。
• 平均值 : 提供特定時間間隔內所有值的平均值。
• 中間數 : 數值的幾何中點，正好50%的數值位于它前面，而另外50%則位于它后面。
• 百分位數?: 度量占總數特定百分比的觀察點的值。
• 標準差 : 顯示指標分布中與平均值的標準差，這可以測量出數據集的差異程度。標準差為0表示數據都等于平均值,較高的標準差意味著數據分布的范圍很廣,
• 變化率?: 顯示時間序列中數據之間的變化程度。

2. 指標聚合

????????除了上述的指標摘要外，你可能經常希望能看到來自多個源的指標的聚合視圖，例如所有應用程序服務器的磁盤空間使用情況。指標聚合最典型的樣式就是在一張圖上顯示多個指標，這有助于你識別環境的發展趨勢(如圖1-7所示)。例如,負載均衡器中的間歇性故障可能導致多個服務器的Web流量下降，這通常比通過查看每個單獨的指標更容易發現。

?點擊進入課程目錄

總結

以上是生活随笔為你收集整理的【运维】第二节 Prometheus 简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。