Prometheus介紹

一、Prometheus介紹

Prometheus是一個開源的系統監控和報警系統，現在已經加入到CNCF基金會，成為繼k8s之后第二個在CNCF托管的項目，在kubernetes容器管理系統中，通常會搭配prometheus進行監控，同時也支持多種exporter采集數據，還支持pushgateway進行數據上報，Prometheus性能足夠支撐上萬台規模的集群。

二、Prometheus特點

2.1、prometheus特點

1）多維度數據模型

每一個時間序列數據都由metric度量指標名稱和它的標簽labels鍵值對集合唯一確定：這個metric度量指標名稱指定監控目標系統的測量特征（如：http_requests_total- 接收http請求的總計數）。labels開啟了Prometheus的多維數據模型：對於相同的度量名稱，通過不同標簽列表的結合, 會形成特定的度量維度實例。(例如：所有包含度量名稱為/api/tracks的http請求，打上method=POST的標簽，則形成了具體的http請求)。這個查詢語言在這些度量和標簽列表的基礎上進行過濾和聚合。改變任何度量上的任何標簽值，則會形成新的時間序列圖。

2）靈活的查詢語言（PromQL）：可以對采集的metrics指標進行加法，乘法，連接等操作；

3）可以直接在本地部署，不依賴其他分布式存儲；

4）通過基於HTTP的pull方式采集時序數據；

5）可以通過中間網關pushgateway的方式把時間序列數據推送到prometheus server端；

6）可通過服務發現或者靜態配置來發現目標服務對象（targets）。

7）有多種可視化圖像界面，如Grafana等。

8）高效的存儲，每個采樣數據占3.5 bytes左右，300萬的時間序列，30s間隔，保留60天，消耗磁盤大概200G。

9）做高可用，可以對數據做異地備份，聯邦集群，部署多套prometheus，pushgateway上報數據

2.2、什么是樣本

樣本：在時間序列中的每一個點稱為一個樣本（sample），樣本由以下三部分組成：

• 指標（metric）：指標名稱和描述當前樣本特征的 labelsets；
• 時間戳（timestamp）：一個精確到毫秒的時間戳；
• 樣本值（value）： 一個 folat64 的浮點型數據表示當前樣本的值。

表示方式：通過如下表達方式表示指定指標名稱和指定標簽集合的時間序列：<metric name>{<label name>=<label value>, ...}

例如，指標名稱為 api_http_requests_total，標簽為 method="POST" 和 handler="/messages" 的時間序列可以表示為：api_http_requests_total{method="POST", handler="/messages"}

三、Prometheus組件介紹

1）Prometheus Server: 用於收集和存儲時間序列數據。

2）Client Library: 客戶端庫，檢測應用程序代碼，當Prometheus抓取實例的HTTP端點時，客戶端庫會將所有跟蹤的metrics指標的當前狀態發送到prometheus server端。

3）Exporters: prometheus支持多種exporter，通過exporter可以采集metrics數據，然后發送到prometheus server端，所有向promtheus server提供監控數據的程序都可以被稱為exporter

4）Alertmanager: 從 Prometheus server 端接收到 alerts 后，會進行去重，分組，並路由到相應的接收方，發出報警，常見的接收方式有：電子郵件，微信，釘釘, slack等。

5）Grafana：監控儀表盤，可視化監控數據

6）pushgateway: 各個目標主機可上報數據到pushgateway，然后prometheus server統一從pushgateway拉取數據。

從上圖可發現，Prometheus整個生態圈組成主要包括prometheus server，Exporter，pushgateway，alertmanager，grafana，Web ui界面，Prometheus server由三個部分組成，Retrieval，Storage，PromQL

• Retrieval負責在活躍的target主機上抓取監控指標數據
• Storage存儲主要是把采集到的數據存儲到磁盤中
• PromQL是Prometheus提供的查詢語言模塊。

四、Prometheus工作流程

1）Prometheus server可定期從活躍的（up）目標主機上（target）拉取監控指標數據，目標主機的監控數據可通過配置靜態job或者服務發現的方式被prometheus server采集到，這種方式默認的pull方式拉取指標；也可通過pushgateway把采集的數據上報到prometheus server中；還可通過一些組件自帶的exporter采集相應組件的數據；

2）Prometheus server把采集到的監控指標數據保存到本地磁盤或者數據庫；

3）Prometheus采集的監控指標數據按時間序列存儲，通過配置報警規則，把觸發的報警發送到alertmanager

4）Alertmanager通過配置報警接收方，發送報警到郵件，微信或者釘釘等

5）Prometheus 自帶的web ui界面提供PromQL查詢語言，可查詢監控數據

6）Grafana可接入prometheus數據源，把監控數據以圖形化形式展示出

五、Prometheus和zabbix對比分析

六、Prometheus的幾種部署模式

6.1、基本高可用模式

基本的HA模式只能確保Promthues服務的可用性問題，但是不解決Prometheus Server之間的數據一致性問題以及持久化問題(數據丟失后無法恢復)，也無法進行動態的擴展。因此這種部署方式適合監控規模不大，Promthues Server也不會頻繁發生遷移的情況，並且只需要保存短周期監控數據的場景。

6.2、基本高可用+遠程存儲

在解決了Promthues服務可用性的基礎上，同時確保了數據的持久化，當Promthues Server發生宕機或者數據丟失的情況下，可以快速的恢復。 同時Promthues Server可能很好的進行遷移。因此，該方案適用於用戶監控規模不大，但是希望能夠將監控數據持久化，同時能夠確保Promthues Server的可遷移性的場景。

6.3、基本HA + 遠程存儲 + 聯邦集群方案

Promthues的性能瓶頸主要在於大量的采集任務，因此用戶需要利用Prometheus聯邦集群的特性，將不同類型的采集任務划分到不同的Promthues子服務中，從而實現功能分區。例如一個Promthues Server負責采集基礎設施相關的監控指標，另外一個Prometheus Server負責采集應用監控指標。再有上層Prometheus Server實現對數據的匯聚。

七、Prometheus的四種數據類型

7.1、Counter

Counter是計數器類型：

• Counter 用於累計值，例如記錄請求次數、任務完成數、錯誤發生次數。
• 一直增加，不會減少。
• 重啟進程后，會被重置。

# Counter類型示例
http_response_total{method="GET",endpoint="/api/tracks"}  100
http_response_total{method="GET",endpoint="/api/tracks"}  160

Counter 類型數據可以讓用戶方便的了解事件產生的速率的變化，在PromQL內置的相關操作函數可以提供相應的分析，比如以HTTP應用請求量來進行說明

1）通過rate()函數獲取HTTP請求量的增長率：rate(http_requests_total[5m])

2）查詢當前系統中，訪問量前10的HTTP地址：topk(10, http_requests_total)

7.2、Gauge

Gauge是測量器類型：

• Gauge是常規數值，例如溫度變化、內存使用變化。
• 可變大，可變小。
• 重啟進程后，會被重置

# Gauge類型示例
memory_usage_bytes{host="master-01"}   100
memory_usage_bytes{host="master-01"}   30
memory_usage_bytes{host="master-01"}   50
memory_usage_bytes{host="master-01"}   80 

對於 Gauge 類型的監控指標，通過 PromQL 內置函數 delta() 可以獲取樣本在一段時間內的變化情況，例如，計算 CPU 溫度在兩小時內的差異：
dalta(cpu_temp_celsius{host="zeus"}[2h])

你還可以通過PromQL 內置函數 predict_linear() 基於簡單線性回歸的方式，對樣本數據的變化趨勢做出預測。例如，基於 2 小時的樣本數據，來預測主機可用磁盤空間在 4 個小時之后的剩余情況：predict_linear(node_filesystem_free{job="node"}[2h], 4 * 3600) < 0

7.3、Histogram

7.3.1、Histogram作用及特點

histogram是柱狀圖，在Prometheus系統的查詢語言中，有三種作用：

1）在一段時間范圍內對數據進行采樣（通常是請求持續時間或響應大小等），並將其計入可配置的存儲桶（bucket）中. 后續可通過指定區間篩選樣本，也可以統計樣本總數，最后一般將數據展示為直方圖。

2）對每個采樣點值累計和(sum)

3）對采樣點的次數累計和(count)

度量指標名稱: [basename]上面三類的作用度量指標名稱

1）[basename]bucket{le="上邊界"}, 這個值為小於等於上邊界的所有采樣點數量
2）[basename]_sum_
3）[basename]_count

小結：如果定義一個度量類型為Histogram，則Prometheus會自動生成三個對應的指標

7.3.2、為什需要用histogram柱狀圖

​ 在大多數情況下人們都傾向於使用某些量化指標的平均值，例如 CPU 的平均使用率、頁面的平均響應時間。這種方式的問題很明顯，以系統 API 調用的平均響應時間為例：如果大多數 API 請求都維持在 100ms 的響應時間范圍內，而個別請求的響應時間需要 5s，那么就會導致某些 WEB 頁面的響應時間落到中位數的情況，而這種現象被稱為長尾問題。
​ 為了區分是平均的慢還是長尾的慢，最簡單的方式就是按照請求延遲的范圍進行分組。例如，統計延遲在 0~10ms 之間的請求數有多少，而 10~20ms 之間的請求數又有多少。通過這種方式可以快速分析系統慢的原因。Histogram 和 Summary 都是為了能夠解決這樣問題的存在，通過 Histogram 和 Summary 類型的監控指標，我們可以快速了解監控樣本的分布情況。

Histogram 類型的樣本會提供三種指標（假設指標名稱為 <basename>）：

1）樣本的值分布在 bucket 中的數量，命名為 <basename>_bucket{le="<上邊界>"}。解釋的更通俗易懂一點，這個值表示指標值小於等於上邊界的所有樣本數量。

# 1、在總共2次請求當中。http 請求響應時間 <=0.005 秒 的請求次數為0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.005",} 0.0

# 2、在總共2次請求當中。http 請求響應時間 <=0.01 秒 的請求次數為0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.01",} 0.0

# 3、在總共2次請求當中。http 請求響應時間 <=0.025 秒 的請求次數為0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.025",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.05",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.075",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.1",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.25",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.5",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="0.75",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="1.0",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="2.5",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="5.0",} 0.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="7.5",} 2.0

# 4、在總共2次請求當中。http 請求響應時間 <=10 秒 的請求次數為 2
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="10.0",} 2.0
io_namespace_http_requests_latency_seconds_histogram_bucket{path="/",method="GET",code="200",le="+Inf",} 2.0

2）所有樣本值的大小總和，命名為 <basename>_sum

# 實際含義： 發生的2次 http 請求總的響應時間為 13.107670803000001 秒
io_namespace_http_requests_latency_seconds_histogram_sum{path="/",method="GET",code="200",} 13.107670803000001

3）樣本總數，命名為 <basename>_count，值和 <basename>_bucket{le="+Inf"} 相同

# 實際含義： 當前一共發生了 2 次 http 請求
io_namespace_http_requests_latency_seconds_histogram_count{path="/",method="GET",code="200",} 2.0

注意：
1）bucket 可以理解為是對數據指標值域的一個划分，划分的依據應該基於數據值的分布。注意后面的采樣點是包含前面的采樣點的，假設 xxx_bucket{...,le="0.01"} 的值為 10，而 xxx_bucket{...,le="0.05"} 的值為 30，那么意味着這 30 個采樣點中，有 10 個是小於 0.01s的，其余 20 個采樣點的響應時間是介於0.01s 和 0.05s之間的。

2）可以通過 histogram_quantile() 函數來計算 Histogram 類型樣本的分位數。分位數可能不太好理解，你可以理解為分割數據的點。我舉個例子，假設樣本的 9 分位數（quantile=0.9）的值為 x，即表示小於 x 的采樣值的數量占總體采樣值的 90%。Histogram 還可以用來計算應用性能指標值（Apdex score）。

7.4、Summary

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

1）對於每個采樣點進行統計，並形成分位圖。（如：正態分布一樣，統計低於60分不及格的同學比例，統計低於80分的同學比例，統計低於95分的同學比例）

2）統計班上所有同學的總成績(sum)

3）統計班上同學的考試總人數(count)

帶有度量指標的[basename]的summary 在抓取時間序列數據有如命名。

1、觀察時間的φ-quantiles (0 ≤ φ ≤ 1), 顯示為[basename]{分位數="[φ]"}

2、[basename]_sum， 是指所有觀察值的總和_

3、[basename]_count, 是指已觀察到的事件計數值

樣本值的分位數分布情況，命名為 <basename>{quantile="<φ>"}。

# 1、含義：這 12 次 http 請求中有 50% 的請求響應時間是 3.052404983s
io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantile="0.5",} 3.052404983

# 2、含義：這 12 次 http 請求中有 90% 的請求響應時間是 8.003261666s
io_namespace_http_requests_latency_seconds_summary{path="/",method="GET",code="200",quantile="0.9",} 8.003261666

所有樣本值的大小總和，命名為 <basename>_sum。

# 1、含義：這12次 http 請求的總響應時間為 51.029495508s
io_namespace_http_requests_latency_seconds_summary_sum{path="/",method="GET",code="200",} 51.029495508

樣本總數，命名為 <basename>_count。

# 1、含義：當前一共發生了 12 次 http 請求
io_namespace_http_requests_latency_seconds_summary_count{path="/",method="GET",code="200",} 12.0

Histogram 與 Summary 的異同：

它們都包含了 <basename>_sum 和 <basename>_count 指標，Histogram 需要通過 <basename>_bucket 來計算分位數，而 Summary 則直接存儲了分位數的值。

prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.5"} 0.012352463
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.9"} 0.014458005
prometheus_tsdb_wal_fsync_duration_seconds{quantile="0.99"} 0.017316173
prometheus_tsdb_wal_fsync_duration_seconds_sum 2.888716127000002
prometheus_tsdb_wal_fsync_duration_seconds_count 216

# 從上面的樣本中可以得知當前Promtheus Server進行wal_fsync操作的總次數為216次，耗時2.888716127000002s。其中中位數（quantile=0.5）的耗時為0.012352463，9分位數（quantile=0.9）的耗時為0.014458005s。

八、Prometheus能監控什么

# Databases---數據庫
    Aerospike exporter
    ClickHouse exporter
    Consul exporter (official)
    Couchbase exporter
    CouchDB exporter
    ElasticSearch exporter
    EventStore exporter
    Memcached exporter (official)
    MongoDB exporter
    MSSQL server exporter
    MySQL server exporter (official)
    OpenTSDB Exporter
    Oracle DB Exporter
    PgBouncer exporter
    PostgreSQL exporter
    ProxySQL exporter
    RavenDB exporter
    Redis exporter
    RethinkDB exporter
    SQL exporter
    Tarantool metric library
    Twemproxy
# Hardware related---硬件相關
    apcupsd exporter
    Collins exporter
    IBM Z HMC exporter
    IoT Edison exporter
    IPMI exporter
    knxd exporter
    Netgear Cable Modem Exporter
    Node/system metrics exporter (official)
    NVIDIA GPU exporter
    ProSAFE exporter
    Ubiquiti UniFi exporter
# Messaging systems---消息服務
    Beanstalkd exporter
    Gearman exporter
    Kafka exporter
    NATS exporter
    NSQ exporter
    Mirth Connect exporter
    MQTT blackbox exporter
    RabbitMQ exporter
    RabbitMQ Management Plugin exporter
# Storage---存儲
    Ceph exporter
    Ceph RADOSGW exporter
    Gluster exporter
    Hadoop HDFS FSImage exporter
    Lustre exporter
    ScaleIO exporter
# HTTP---網站服務
    Apache exporter
    HAProxy exporter (official)
    Nginx metric library
    Nginx VTS exporter
    Passenger exporter
    Squid exporter
    Tinyproxy exporter
    Varnish exporter
    WebDriver exporter
# APIs
    AWS ECS exporter
    AWS Health exporter
    AWS SQS exporter
    Cloudflare exporter
    DigitalOcean exporter
    Docker Cloud exporter
    Docker Hub exporter
    GitHub exporter
    InstaClustr exporter
    Mozilla Observatory exporter
    OpenWeatherMap exporter
    Pagespeed exporter
    Rancher exporter
    Speedtest exporter
# Logging---日志
    Fluentd exporter
    Google's mtail log data extractor
    Grok exporter
# Other monitoring systems
    Akamai Cloudmonitor exporter
    Alibaba Cloudmonitor exporter
    AWS CloudWatch exporter (official)
    Cloud Foundry Firehose exporter
    Collectd exporter (official)
    Google Stackdriver exporter
    Graphite exporter (official)
    Heka dashboard exporter
    Heka exporter
    InfluxDB exporter (official)
    JavaMelody exporter
    JMX exporter (official)
    Munin exporter
    Nagios / Naemon exporter
    New Relic exporter
    NRPE exporter
    Osquery exporter
    OTC CloudEye exporter
    Pingdom exporter
    scollector exporter
    Sensu exporter
    SNMP exporter (official)
    StatsD exporter (official)
# Miscellaneous---其他
    ACT Fibernet Exporter
    Bamboo exporter
    BIG-IP exporter
    BIND exporter
    Bitbucket exporter
    Blackbox exporter (official)
    BOSH exporter
    cAdvisor
    Cachet exporter
    ccache exporter
    Confluence exporter
    Dovecot exporter
    eBPF exporter
    Ethereum Client exporter
    Jenkins exporter
    JIRA exporter
    Kannel exporter
    Kemp LoadBalancer exporter
    Kibana Exporter
    Meteor JS web framework exporter
    Minecraft exporter module
    PHP-FPM exporter
    PowerDNS exporter
    Presto exporter
    Process exporter
    rTorrent exporter
    SABnzbd exporter
    Script exporter
    Shield exporter
    SMTP/Maildir MDA blackbox prober
    SoftEther exporter
    Transmission exporter
    Unbound exporter
    Xen exporter
# Software exposing Prometheus metrics---Prometheus度量指標
    App Connect Enterprise
    Ballerina
    Ceph
    Collectd
    Concourse
    CRG Roller Derby Scoreboard (direct)
    Docker Daemon
    Doorman (direct)
    Etcd (direct)
    Flink
    FreeBSD Kernel
    Grafana
    JavaMelody
    Kubernetes (direct)
    Linkerd

九、Prometheus對kubernetes的監控

對於Kubernetes而言，我們可以把當中所有的資源分為幾類：

• 基礎設施層（Node）：集群節點，為整個集群和應用提供運行時資源
• 容器基礎設施（Container）：為應用提供運行時環境
• 用戶應用（Pod）：Pod中會包含一組容器，它們一起工作，並且對外提供一個（或者一組）功能
• 內部服務負載均衡（Service）：在集群內，通過Service在集群暴露應用功能，集群內應用和應用之間訪問時提供內部的負載均衡
• 外部訪問入口（Ingress）：通過Ingress提供集群外的訪問入口，從而可以使外部客戶端能夠訪問到部署在Kubernetes集群內的服務

因此，如果要構建一個完整的監控體系，我們應該考慮，以下5個方面：

• 集群節點狀態監控：從集群中各節點的kubelet服務獲取節點的基本運行狀態；
• 集群節點資源用量監控：通過Daemonset的形式在集群中各個節點部署Node Exporter采集節點的資源使用情況；
• 節點中運行的容器監控：通過各個節點中kubelet內置的cAdvisor中獲取個節點中所有容器的運行狀態和資源使用情況；
• 如果在集群中部署的應用程序本身內置了對Prometheus的監控支持，那么我們還應該找到相應的Pod實例，並從該Pod實例中獲取其內部運行狀態的監控指標。
• 對k8s本身的組件做監控：apiserver、scheduler、controller-manager、kubelet、kube-proxy