prometheus 簡介
隨著容器技術的迅速發展，kubernetes 已然成為大家追捧的容器集群管理系統。
prometheus 作為生態圈 cloud native computing foundation（簡稱：cncf）中的重要一員,其活躍度僅次於 kubernetes, 現已廣泛用於 kubernetes 集群的監控系統中。
本文將簡要介紹 prometheus 的組成和相關概念。
prometheus 特點
作為新一代的監控框架，prometheus 具有以下特點：
●強大的多維度資料模型：
1.時間序列資料通過 metric 名和鍵值對來區分。
2.所有的 metrics 都可以設定任意的多維標籤。
3.資料模型更隨意，不需要刻意設定為以點分隔的字串。
4.可以對資料模型進行聚合，切割和切片操作。
5.支援雙精度浮點型別，標籤可以設為全 unicode。
●靈活而強大的查詢語句（promql）：在同乙個查詢語句，可以對多個 metrics 進行乘法、加法、連線、取分數字等操作。
●易於管理： prometheus server 是乙個單獨的二進位制檔案，可直接在本地工作，不依賴於分布式儲存。
●高效：平均每個取樣點僅佔 3.5 bytes，且乙個 prometheus server 可以處理數百萬的 metrics。
●使用 pull 模式採集時間序列資料，這樣不僅有利於本機測試而且可以避免有問題的伺服器推送壞的 metrics。
●可以採用 push gateway 的方式把時間序列資料推送至 prometheus server 端。
●可以通過服務發現或者靜態配置去獲取監控的 targets。
●有多種視覺化圖形介面。
●易於伸縮
需要指出的是，由於資料採集可能會有丟失，所以 prometheus 不適用對採集資料要 100% 準確的情形。
但如果用於記錄時間序列資料，prometheus 具有很大的查詢優勢，此外，prometheus 適用於微服務的體系架構。
prometheus 組成
prometheus 生態圈中包含了多個元件，其中許多元件是可選的：
●prometheus server:
用於收集和儲存時間序列資料。
●client library: 客戶端庫
為需要監控的服務生成相應的 metrics 並暴露給 prometheus server。
當 prometheus server 來 pull 時，直接返回實時狀態的 metrics。
●push gateway:
主要用於短期的 jobs。
由於這類 jobs 存在時間較短，可能在 prometheus 來 pull 之前就消失了。
為此，這次 jobs 可以直接向 prometheus server 端推送它們的 metrics。
這種方式主要用於服務層面的 metrics，對於機器層面的 metrices，需要使用 node exporter。
●exporters:
用於暴露已有的第三方服務的 metrics 給 prometheus
●alertmanager:
從 prometheus server 端接收到 alerts 後，會進行去除重複資料，分組，並路由到對收的接受方式，發出報警。
常見的接收方式有：電子郵件，pagerduty，opsgenie, webhook 等。
●一些其他的工具。
prometheus 架構圖
從上圖可以看出，prometheus 的主要模組包括：prometheus server, exporters, pushgateway, promql, alertmanager 以及圖形介面。
prometheus工作流程
1.prometheus server 定期從配置好的 jobs 或者 exporters 中拉 metrics，或者接收來自 pushgateway 發過來的 metrics，或者從其他的 prometheus server 中拉 metrics。
2.prometheus server 在本地儲存收集到的 metrics，並執行已定義好的 alert.rules，記錄新的時間序列或者向 alertmanager 推送警報。
3.alertmanager 根據配置檔案，對接收到的警報進行處理，發出告警。
4.在圖形介面中，視覺化採集資料。
prometheus 相關概念
下面將對 prometheus 中的資料模型，metric 型別以及 instance 和 job 等概念進行介紹。
資料模型
prometheus 中儲存的資料為時間序列，是由 metric 的名字和一系列的標籤（鍵值對）唯一標識的，不同的標籤則代表不同的時間序列。
●metric 名字：該名字應該具有語義，一般用於表示 metric 的功能。
例如：httprequests_total, 表示 http 請求的總數。
其中，metric 名字由 ascii 字元，數字，下劃線，以及冒號組成，且必須滿足正規表示式 [a-za-z:][a-za-z0-9_:]*。
●標籤：使同乙個時間序列有了不同維度的識別。
例如 httprequests_total 表示所有 http 請求中的 get 請求。
當 method=」post」 時，則為新的乙個 metric。
標籤中的鍵由 ascii 字元，數字，以及下劃線組成，且必須滿足正規表示式 [a-za-z:][a-za-z0-9_:]*。
●樣本：實際的時間序列，每個序列包括乙個 float64 的值和乙個毫秒級的時間戳。
●格式：，例如：http_requests_total。
四種 metric 型別
prometheus 客戶端庫主要提供四種主要的 metric 型別：
**1.**counter（計數器）
一種累加的 metric，典型的應用如：請求的個數，結束的任務數， 出現的錯誤數等等。
例如，查詢 http_requests_total 返回 8，10 秒後，再次查詢，則返回 14。
**2.**gauge（儀錶盤）
一種常規的 metric，典型的應用如：溫度，執行的 goroutines 的個數。
可以任意加減。
例如：go_goroutines 返回值 147，10 秒後返回 124。
**3.**histogram（直方圖）
可以理解為柱狀圖，典型的應用如：請求持續時間，響應大小。
可以對觀察結果取樣，分組及統計。
例如，查詢 http_request_duration_microseconds_sum 時，返回結果如下：
**4.**summary（摘要）
類似於 histogram, 典型的應用如：請求持續時間，響應大小。
提供觀測值的 count 和 sum 功能。
提供百分位的功能，即可以按百分比劃分跟蹤結果。
instance 和 jobs
instance: 乙個單獨 scrape 的目標， 一般對應於乙個程序。
jobs: 一組同種型別的 instances（主要用於保證可擴充套件性和可靠性）
Prometheus告警簡介
告警能力在prometheus的架構中被劃分成兩個獨立的部分。如下所示，通過在prometheus中定義alertrule 告警規則 prometheus會週期性的對告警規則進行計算，如果滿足告警觸發條件就會向alertmanager傳送告警資訊。在prometheus中一條告警規則主要由以下幾部分...
prometheus入門介紹
參考blog，入門以prometheus為中心的服務監控系統的運作流程，包括警告管理系統alertmanager 視覺化介面 push gateway 臨時任務和批處理任務的推送處理方式。prometheus官方文件 自動抓取資料到 自動報警 視覺化展示效果 prometheus是乙個開源的服務監控...
prometheus函式介紹
gauge型別的資料 屬於隨機變化數值，並不像counter那樣 是 持續增長 increase 函式 在promethes中，是 來 針對counter 這種持續增 長的數值，擷取其中 段時間的增量 increase node cpu 1m 這樣 就獲取了 cpu總使 時間 在1分鐘內的增量,得到...