prometheus github社區：https://github.com/prometheus-community/
【1】基本介紹
【1.0】Prometheus 與 其他監控產品的優劣
優點：
（1）監控數據的精細程度非常高，可以精確到1-5秒的采集精度
（2）軟件的部署非常快，大大縮減搭建時間成本
（3）周邊插件很豐富，比如 exporter pushgateway 大多數都步需要自己開發了
（4）基於數學計算模型（proMQL），大量的使用函數，可以實現很復雜規則的業務邏輯監控（比如QPS曲線，彎曲，凸起，下跌，比例等等模糊）
（5）可以嵌入很多開源工具的內部，比如nignx 、數據庫 等，進行監控，數據更准時更可信（其他監控比較難做到）
（6）結合grafana 圖形很高大上很美觀
不足：
（1）因為圖形菜雞經度，如果集群數據量太大，那么簡單監控有性能瓶頸。
（2）學習成本大，還有 proMQL，中文資料極少，沒有人教 官網英文資料也是比較難入門
（3）對磁盤資源消耗比較大，這個具體要看監控的集群數量 和 監控項的多少 以及保存時長的設置
（4）本身的使用，需要使用者數學不能太差，有一定的數據邏輯
【1.1】概念及特點
簡介：
Prometheus是一個最初在SoundCloud上構建的開源系統監控和警報工具包 。自2012年成立以來，許多公司和組織都采用 Prometheus，該項目擁有非常活躍的開發人員和用戶社區。
它現在是一個獨立的開源項目，並且獨立於任何公司。為了強調這一點，並澄清 項目的治理結構，Prometheus 於2016年加入 雲本地計算基金會，作為Kubernetes之后的第二個托管項目。
特點：
Prometheus 屬於一站式監控告警平台，依賴少，功能齊全。 Prometheus 支持對雲的或容器的監控，其他系統主要對主機監控。
Prometheus 數據查詢語句表現力更強大，內置更強大的統計函數。 Prometheus 在數據存儲擴展性以及持久性上沒有 InfluxDB，OpenTSDB，Sensu 好。
優質特性：
（1）基於 time series 時序模型，既使用時序數據庫存儲模型。什么是時序序列呢？就是（x,y）軸，x為時間，y為值
（2）使用 K/V 的數據模型，格式簡單，速度快，易維護開發
（3）采樣數據查詢：promQL，比如可以 （增量A+增量B）/ 總量C
（4）采用 HTTP pull /push 兩種對應的數據采集方式傳輸
（5）【開源，及大量插件】
（6）【本身自帶挺調試】、【秒級數據采樣頻率，秒級采樣間隔】
（7）通過服務發現或者靜態配置，來發現目標服務對象
（8）不依賴分布式存儲，單個服務器節點是自主的
不足：
（1）本身不支持集群化
（2）被監控集群過大后，本身可能會產生性能瓶頸
（3）中文支持不好，中文資料也少
【1.2】prometheus 基本組件
- Prometheus Server， 主要用於抓取數據和存儲時序數據，另外還提供查詢和 Alert Rule 配置管理。
- client libraries，用於對接 Prometheus Server, 可以查詢和上報數據。
- push gateway ，用於批量，短期的監控數據的匯總節點，主要用於業務數據匯報等。
- 各種匯報數據的 exporters ，例如匯報機器數據的 node_exporter, 匯報 MongoDB 信息的 MongoDB exporter 等等。
- 用於告警通知管理的 alertmanager 。
【1.3】基本原理
Prometheus基本原理是通過HTTP協議周期性抓取被監控組件的狀態，這樣做的好處是任意組件只要提供HTTP接口就可以接入監控系統， 不需要任何SDK或者其他的集成過程。
這樣做非常適合虛擬化環境比如VM或者Docker 。 Prometheus應該是為數不多的適合Docker、Mesos、Kubernetes環境的監控系統之一。
輸出被監控組件信息的HTTP接口被叫做exporter 。
目前互聯網公司常用的組件大部分都有exporter可以直接使用，比如Varnish、 Haproxy、Nginx、MySQL、Linux 系統信息 (包括磁盤、內存、CPU、網絡等等）
【1.4】監控的基本體系流程
【2】認識prometheus
【2.1】基本架構與模塊
從這個架構圖，也可以看出 Prometheus 的主要模塊包含， Server, Exporters, Pushgateway, PromQL, Alertmanager, WebUI 等。
【2.2】Promethues server 模塊
prometheus 本身是一個以進程方式啟動，之后以多進程和多線程實現監控數據收集、計算、查詢、更新、存儲的CS模型運行模式
默認為9090端口。
一、存儲模塊
（1）時序數據庫 tsdb 存儲
（2）TS格式以每2個小時間隔來分 block，每一個塊中又分為多個 chunk文件，chunk文件使用來存放 才寄過來的T-S數據，metadate和索引文件
（3）index文件，是對 metrics/prometheus 中 一次K/V菜雞數據叫做一個 metric 和 labels（標簽） 進行索引之后存儲在chunk中，chunk是作為存儲的基本單位，index and metadate 是作為自己。
（4）prometheus 平時是將才寄過來的數據 先都存放在內存中（prometheus對內存的消耗 還是不小的），以類似緩存的方式用於加快搜索和訪問
（5）當出現宕機時，prometheus 有一種保護機制，叫做 WAL（預寫式日志），可以將數據定期存入硬盤中，以chunk來表示，並在重啟時 用以恢復數據進入內存
二、http server
（1）有用http服務器，以便可以web頁面訪問，以及web方式 pull ；
【2.3】 service discovery（服務發現）
也就是自動把節點發現到 prometheus，而不是都需要手動配置 prometheus.yml 配置文件
【2.4】pull metrics（拉取監控指標信息）
（1）pull 主動拉取形式
pull：指定是客戶端（被監控的機器）先安裝各類已用的 采集器 ，比如 node_exporters （linux服務器采集器），之后exporters 以守護進程的方式運行 並開始采集數據。
同時 exporter 本身也是一個 http_server，可以對 http 請求做出響應，返回數據（K/V metrics），所以服務端才能以http的方式 pull 客戶端的指標信息
（2）push
其實這里就涉及到一個 pushgateway，這個東西類似於一個中轉站一樣。安裝好之后。
客戶端的相關job push數據（以K/V metrics形式）到 pushgateway（即客戶端主動發送數據到pushgateway），然后 pushgateway push 數據到 prometheus 服務器中去。
這是一種被動的數據模式。
【2.5】Alertmanager 監控
prometheus 服務器把報警信息=》 Alertmanager=》實際報警信息發送
【2.6】數據可視化界面
web界面 現在用的最多的是 Grafanna.
【3】prometheus 監控數據格式
【3.1】Metrics（Gauges,Counter,Histograms,Summary）
prometheus 監控中，對於采集過來的數據，統一稱為 metics數據
metrics 是一種對采集數據的總稱（metrics 並不代表某一種具體的數據格式，是一種對於度量單位和采集樣本的抽象描述）
它分為以下4種類型
（1）Gauge 類型
最簡單的度量指標，只有一個簡單的返回值，或者叫瞬時狀態，這個值是隨機、無規律的。
例如：
我們要監控硬盤容量或者內存使用量，那么就應該使用 Gauges 的 metrics 格式來度量。采集到當前值是多少就是多少
因為內存、硬盤容量的使用情況 是隨着時間的推移 不斷的隨機的瞬時的沒有規則的變化；（比如內存分配、內存釋放等無規律的操作.....）
CPU也是這樣。
采集數據樣例圖：
（2）Counter 類型
Counter 就是計數器，從數據量0開始累積計算，在理想狀態下 該值數據是永遠增長的，不會降低（一些特殊情況另說）
舉例：
對用戶訪問量的采樣數據，訪問量是只會增不會減的。
特例，特殊情況：
比如我每天晚上 2點 對訪問量做清理操作，這就另說了。
采集數據樣例圖：
（3）Histograms
翻譯過來大概是：比例型的估算數值
histogram 統計數據的分部情況。比如最小值，最大值，中間值，中位數，75百分位，90百分位，95/98/99/99.9百分位的值（percentlies）
這是一種特殊的 metrics 數據類型，代表的是一種 近似的百分比估算值
問題案例：
核心思路：
（4）Summary
Summary和Histogram十分相似，常用於跟蹤事件發生的規模，例如：請求耗時、響應大小。同樣提供 count 和 sum 全部值的功能。
例如：count=7次，sum=7次的值求值。 它提供一個quantiles的功能，可以按%比划分跟蹤的結果。例如：quantile取值0.95，表示取采樣值里面的95%數據。
【3.2】metrics K/V數據
我們在node_exporter 節點運行URL 訪問
curl http://localhost:9100/metrics
我們可以清楚的看到其返回類型
# TYPE process_cpu_seconds_total counter process_cpu_seconds_total 357.94 # HELP process_max_fds Maximum number of open file descriptors. # TYPE process_max_fds gauge process_max_fds 1024 # HELP process_open_fds Number of open file descriptors. # TYPE process_open_fds gauge process_open_fds 10
如上面代碼，我們可以看到 會有注釋 顯示 type，是gauge 還是 counter 等等
process_open_fds 10
這就表示 Key 是 process_open_fds Value 是 10
【4】pushgateway
【4.1】基本介紹
push的形式是把 pushgateway 安裝在 客戶端或者服務器端（其實都可以）
它本身也是一個http服務器
運維通過寫自己的腳本程序，抓自己想要的監控數據，轉換成 K/V 的形式，然后推送到 Pushgateway（HTTP POST） 再由 Pushgateway 推送到 Prometheus 服務器端
【4.2】exporter已經很豐富了，為什么還要 pushgateway？
（1）exporter 雖然采集很多數據，但是我們依然需要很多自制的監控數據，非規則化，自定制的
（2）exporter 由於數據類型采集量太大，其實很多數據 甚至對大部分數據都用不到，用pushgateway 是定義一項或者幾項數據，節約資源。
（3）一個新的自定義的 pushgateway 腳本開發，比開發一個新的 exporter 簡單快速的多的多的多！
（exporter 需要真正的變成語言，shell 之類的是不行的，而且exporter 還需要了解很多 prometheus自定的變成格式才能開始制作，工作量巨大）
（4）exporter 雖然已經很豐富了，但是依然有很多我們需要的采集形式，exporter無法提供，或者說現有的 exporter 還不支持，但是如果使用 pushgateway 的形式，就可以非常靈活 想采集什么樣的都可以，而且極快。
【4.3】圖解 pushgateway 和 常規 exporter 的流程形式
其他
默認端口
服務器端：
prometheus： 9090
node_exporter： 9100
mysqld_exporter：9104
Alertmanager： 9093
wmi-exporter： 9182
【告警模板】
【email】
{{- if gt (len .Alerts.Firing) 0 -}}{{ range $i, $alert :=.Alerts }}
{{- if eq $alert.Labels.severity "緊急" }}
========緊急告警==========<br>
{{- else }}
========監控告警==========<br>
{{- end }}
告警主機：{{ $alert.Labels.host_label }}<br>
告警級別：{{ $alert.Labels.severity }}<br>
告警狀態：{{ .Status }}<br>
告警類型：{{ $alert.Labels.alertname }}<br>
告警概述：{{ $alert.Annotations.summary }}<br>
告警取值：{{ $alert.Annotations.value }}<br>
告警時間：{{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}<br>
運營團隊: {{ $alert.Labels.team }}<br>
告警詳情：{{ $alert.Annotations.description }}<br>
========end=============
{{ end }}
{{ end -}}
{{- if gt (len .Alerts.Resolved) 0 -}}{{ range $i, $alert :=.Alerts }}
====告警恢復=====<br>
告警主機：{{ $alert.Labels.host_label }}<br>
告警狀態：{{ .Status }}<br>
告警類型：{{ $alert.Labels.alertname }}<br>
告警概述：{{ $alert.Annotations.summary }}-->恢復<br>
告警時間：{{ ($alert.StartsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}<br>
恢復時間：{{ ($alert.EndsAt.Add 28800e9).Format "2006-01-02 15:04:05" }}<br>
========end=============
{{ end }}
{{ end -}}
{{ end }}