概述
官方網站：https://prometheus.io/git
Github:https://github.com/prometheus/prometheusgithub
Prometheus 是一個開源監控系統，它前身是 SoundCloud 的告警工具包。從 2012 年開始，許多公司和組織開始使用 Prometheus。該項目的開發人員和用戶社區很是活躍，愈來愈多的開發人員和用戶參與到該項目中。目前它是一個獨立的開源項目，且不依賴於任何公司。爲了強調這點和明確該項目治理結構，Prometheus 在 2016 年繼 Kurberntes 以後，加入了 Cloud Native Computing Foundation。web
主要特性
- 多維度數據模型
- 靈活的查詢語言
- 不依賴任何分佈式存儲
- 常見方式是經過拉取方式採集數據
- 也可經過中間網關支持推送方式採集數據
- 經過服務發現或者靜態配置來發現監控目標
- 支持多種圖形界面展現方式
架構
Servicediscovery正則表達式
pagerdutyapi
Short-lived網絡
jobs架構
ile_sd分佈式
kubernetessvg
AIertmanager工具
pushmetrics
atexit
discover
notify
targets
Pushgateway
Prometheusserver
push
alerts
HTTP
pull
Retrieval
TSDB
server
metrics
Prometheus
webUi
Grafana
Node
HDD/SSD
Jobs/
exporters
APIclients
Prometheus Server 採用拉取方式從監控目標直接拉取數據，或者經過中間網關間接地拉取監控目標推送給網關的數據。它在本地存儲抓取的數據，經過必定規則進行清理和整理數據，而後把獲得的結果存儲起來，各類 Web UI 使用 PromQL 查詢語言來從 Server 裏獲取數據。當 Server 監測到有異常時會推送告警給 Alertmanager，Alertmanager 負責去通知相關人。
缺陷
普羅米修斯值的可靠性。您始終能夠查看有關係統的可用統計信息，即便在故障狀況下也是如此。若是您須要100%的準確性，好比根據每次請求計費，Prometheus不是一個好的選擇，由於收集的數據可能不夠詳細和完整。在這種狀況下，您最好使用其餘系統來收集和分析用於計費的數據，使用Prometheus來完成其餘的監控工做。
核心概念
數據模型
Prometheus從根本上存儲的全部數據都是時間序列: 具備時間戳的數據流只屬於單個度量指標和該度量指標下的多個標籤維度。除了存儲時間序列數據外，Prometheus也能夠利用查詢表達式存儲5分鐘的返回結果中的時間序列數據
度量指標(Metric names)和標籤(labels)
每一個時間序列Time Serie，簡稱時序）由度量指標和一組標籤鍵值對惟一肯定。
量指標名稱指定監控目標系統的測量特徵（如：http_requests_total- 接收http請求的總計數）. metric度量指標命名ASCII字母、數字、下劃線和冒號，他必須配正則表達式[a-zA-Z_:][a-zA-Z0-9_:]*。
標籤開啓了Prometheus的多維數據模型：對於相同的度量名稱，經過不一樣標籤列表的結合, 會造成特定的度量維度實例。(例如：全部包含度量名稱爲/api/tracks的http請求，打上method=POST的標籤，則造成了具體的http請求)。這個查詢語言在這些度量和標籤列表的基礎上進行過濾和聚合。改變任何度量上的任何標籤值，則會造成新的時間序列圖
標籤label名稱能夠包含ASCII字母、數字和下劃線。它們必須匹配正則表達式[a-zA-Z_][a-zA-Z0-9_]*。帶有__下劃線的標籤名稱被保留內部使用。
標籤labels值包含任意的Unicode碼。
採樣值Samples
有序的採樣值造成了實際的時間序列數據列表。每一個採樣值包括：
- 一個64位的浮點值
- 一個精確到毫秒級的時間戳
註解Notation
表示一個度量指標和一組鍵值對標籤，須要使用如下符號：
例如，度量指標名稱是api_http_requests_total， 標籤爲method="POST", handler="/messages" 的示例以下所示：
metrics類型
Prometheus客戶庫提供了四個核心的metrics類型。
Counter/計數器
counter 是一個累計度量指標，它是一個只能遞增的數值。計數器主要用於統計服務的請求數、任務完成數和錯誤出現的次數等等。計數器是一個遞增的值，也就是隻能只能增長不能減小。重啓進程後，會被重置。
Gauge/測量器
gauge是一個度量指標，它表示一個既能夠遞增, 又能夠遞減的值。計量器主要用於測量相似於溫度、內存使用量這樣的瞬時數據。
Histogram/柱狀圖
histogram，是柱狀圖，在Prometheus系統中的查詢語言中，有三種做用：
- 對每一個採樣點進行統計，打到各個分類值中(bucket)
- 對每一個採樣點值累計和(sum)
- 對採樣點的次數累計和(count)
度量指標名稱: [basename]的柱狀圖, 上面三類的做用度量指標名稱
- [basename]_bucket{le=「上邊界」}, 這個值爲小於等於上邊界的全部採樣點數量
- [basename]_sum
- [basename]_count
經常使用於跟蹤事件發生的規模，例如：請求耗時、響應大小。它特別之處是能夠對記錄的內容進行分組，提供 count 和 sum 所有值的功能。
Summary/總結
相似histogram柱狀圖，summary是採樣點分位圖統計，(一般的使用場景：請求持續時間和響應大小)。 它也有三種做用：
- 對於每一個採樣點進行統計，並造成分位圖。（如：正態分佈同樣，統計低於60分不及格的同窗比例，統計低於80分的同窗比例，統計低於95分的同窗比例）
- 統計班上全部同窗的總成績(sum)
- 統計班上同窗的考試總人數(count)
帶有度量指標的[basename]的summary 在抓取時間序列數據展現。
- 觀察時間的φ-quantiles (0 ≤ φ ≤ 1), 顯示爲
[basename]{分位數="[φ]"} [basename]_sum， 是指全部觀察值的總和[basename]_count, 是指已觀察到的事件計數值
任務(Jobs)和實例(Instances)
就Prometheus而言，pull拉取採樣點的端點稱之爲instance。爲了性能擴展而複製出來的多個這樣的實例造成了一個任務。
例如, 下面的api-server的任務有四個相同的實例。
當Prometheus拉取一個目標, 會自動地把兩個標籤添加到度量名稱的標籤列表中，分別是：
job: 目標所屬的配置任務名稱api-server。
instance: 採樣點所在服務: host:port 若是以上兩個標籤兩者之一存在於採樣點中，這個取決於honor_labels配置選項。
對於每一個採樣點所在服務instance，Prometheus都會存儲如下的度量指標採樣點：
- up{job=」[job-name]「, instance=「instance-id」}: up值=1，表示採樣點所在服務健康; 不然，網絡不通, 或者服務掛掉了
- scrape_duration_seconds{job=」[job-name]「, instance=」[instance-id]「}: 嘗試獲取目前採樣點的時間開銷
- scrape_samples_scraped{job=」[job-name]「, instance=」[instance-id]「}: 這個採樣點目標暴露的樣本點數量
up度量指標對服務健康的監控是很是有用的。
最佳實踐
官方還給出一些最佳實踐，能夠簡單瀏覽一下。主要是一些指標命名建議、監控指標類型的選擇、告警策略、採用Recording rules提早生成監控指標、什麼時候部署Pushgateway。
參考
https://prometheus.io/docs/introduction/overview/
https://github.com/1046102779/prometheus
https://prometheus.io/docs/practices/naming/
https://github.com/PierreVincent/prom-http-simulator/blob/master/cmd/main.go
本文同步分享在 博客「羊羽」（other）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。