1. Prometheus的適合與不適合
Prometheus官網這樣描述它的適用場景：
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.
Prometheus的核心數據模型是時間序列，因此它非常適合記錄時間序列數據，並根據記錄的時間序列進行相關的聚合和分析操作。Prometheus使用定時採樣的方式來採集指標數據，因此非常適合於在服務集羣中採集實時監控數據，這也是被廣泛應用於kubernetes集羣監控中的一個原因。
由於Prometheus中的數據是採樣數據，因而也並非適用所有場景。Prometheus官網這樣描述它的不適合之處：
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.
即對於需要採集完整的數據，並保證100%數據精確的情況下，Prometheus並不是一個好的選擇。
對於這裏提到的100%數據精確，我的理解有兩方面：1.在prometheus的時序數據庫中查詢數據，並非在時序數據庫中去精確匹配查詢時間戳，而是選一個有效時間內（即時有效性，5分鐘內）最接近這個查詢時間戳的時間戳匹配。2.對於入庫指標的時間戳，常用方式是由prometheus服務器來打，若自己定義時間戳，在使用上有一些限制。
2. Prometheus相關知識
2.1. Prometheus知識導圖
Prometheus由服務器(server)，採集器(exporter)，推送網關(push gateway)和告警管理器(AlertManager)組成。實際上，服務器(server)，採集器(exporter)是必須的，推送網關和告警管理器可根據應用場景選用。
Prometheus的核心數據模型是基於指標數據的時間序列模型。在Prometheus中，每一個時間序列由指標名稱與其對應的標籤集合唯一標識，如“vehicle_passed_num{instance="viid",job="zhangkai",lane_no="1",tollgate_no="1"}”和“vehicle_passed_num{instance="viid",job="zhangkai",lane_no="1",tollgate_no="2"}”這兩個時間序列標識儘管指標名稱相同，但標籤值不同。因此可以視爲兩個不同的時間序列。
對於每個時間序列，在Prometheus中存儲的是一個二元組(時間戳，指標值)的列表，這裏時間戳爲毫秒級的UTC時間，指標值爲一個float64的值。
一個時間序列看起來就像下面這個樣子：
Prometheus採集數據的方式主要爲拉(pull)的方式，即使用HTTP接口定時從指定目標(Target)中獲取指標數據，採集目標提供的指標數據中包含自定義的時間戳，若不包含自定義的時間戳，則Prometheus在存入自己的時序數據庫時使用自身服務器的系統時間打上時間戳。
Prometheus提供推送網關(push gateway)實現一種僞“推數據”的方式，之所以說它是僞的方式，因爲推送網關只是將指標值暫存在內存中，最後還是由Prometheus服務器來定時拉取。推送網關有一些問題可能導致在某些情況下不適用：
- POST到推送網關的指標數據不能攜帶自定義的時間戳。
- 對於同一時間序列，推送網關只保留當前值：當Prometheus服務器的採集週期大於推送週期時，可能出現指標漏採的情況；當Prometheus服務器的採集週期小於推送週期時，可能出現指標重複採集的情況。
下圖顯示了Prometheus服務器自身提供的一些指標值，拉取地址爲“/metrics”。
2.2. 指標模型
在Prometheus中提供了四種指標模型，分別爲：Counter,Gauge,Histogram,Summary。
Counter：一種累加的指標，用於表示持續的計數。典型的應用如：請求的個數，結束的任務數， 出現的錯誤數等等。如下面的示例：
# TYPE go_memstats_alloc_bytes_total counter
go_memstats_alloc_bytes_total 1.639836264e+09
Gauge：一種標識即時測量值指標。如下面的示例：
# TYPE go_memstats_heap_alloc_bytes gauge
go_memstats_heap_alloc_bytes 1.9423568e+07
Histogram：直方圖對觀察結果(通常是請求持續時間或響應大小之類的東西)進行採樣，並在可配置的桶中計數。它還提供了所有觀測值的和。如下面的示例：
# TYPE prometheus_http_response_size_bytes histogram
prometheus_http_response_size_bytes_bucket{handler="/",le="100"} 1
prometheus_http_response_size_bytes_bucket{handler="/",le="1000"} 1
prometheus_http_response_size_bytes_bucket{handler="/",le="10000"} 1
prometheus_http_response_size_bytes_bucket{handler="/",le="100000"} 1
prometheus_http_response_size_bytes_bucket{handler="/",le="1e+06"} 1
prometheus_http_response_size_bytes_bucket{handler="/",le="1e+07"} 1
prometheus_http_response_size_bytes_bucket{handler="/",le="1e+08"} 1
prometheus_http_response_size_bytes_bucket{handler="/",le="1e+09"} 1
prometheus_http_response_size_bytes_bucket{handler="/",le="+Inf"} 1
prometheus_http_response_size_bytes_sum{handler="/"} 29
prometheus_http_response_size_bytes_count{handler="/"} 1
Summary： 與直方圖類似，摘要樣例觀察結果(通常是請求持續時間和響應大小之類的內容)。雖然它還提供了觀測值的總數和所有觀測值的和，但它計算了一個滑動時間窗口上的可配置分位數。如下面的示例：
# TYPE prometheus_notifications_latency_seconds summary
prometheus_notifications_latency_seconds{alertmanager="http://172.16.64.159:8081/api/v1/alerts",quantile="0.5"} 0.008799
prometheus_notifications_latency_seconds{alertmanager="http://172.16.64.159:8081/api/v1/alerts",quantile="0.9"} 0.0140762
prometheus_notifications_latency_seconds{alertmanager="http://172.16.64.159:8081/api/v1/alerts",quantile="0.99"} 0.065916
prometheus_notifications_latency_seconds_sum{alertmanager="http://172.16.64.159:8081/api/v1/alerts"} 17.340421599999974
prometheus_notifications_latency_seconds_count{alertmanager="http://172.16.64.159:8081/api/v1/alerts"} 1454
2.3. 查詢表達式
查詢表達式是Prometheus應用編程的核心概念。Prometheus提供了一種名爲PromQL (Prometheus查詢語言)的函數式查詢語言，允許用戶實時選擇和聚合時間序列數據。表達式的結果既可以顯示爲圖形，也可以在Prometheus的表達式瀏覽器中作爲表格數據查看，或者通過HTTP API由外部系統使用。
可使用查詢表達式實現時間序列即時數據和指定時間段數據的查詢。
假設採集器每分鐘採集每個卡口車道在這分鐘的過車數目。
如下圖所示，查詢卡口1車道1的即時過車數據：
也可使用查詢表達式查詢最近5分鐘內的過車數目明細，如下圖所示：
這兩種模式可使用下面的圖來表示：
針對這兩種模式的查詢，prometheus提供了HTTP API供使用：
Instant queries
格式：GET /api/v1/query
查詢參數：query=<string>，time=<rfc3339 | unix_timestamp>，timeout=<duration>
Range queries
格式：GET /api/v1/query_range
查詢參數：query=<string>，start=<rfc3339 | unix_timestamp>，end=<rfc3339 | unix_timestamp>，step=<duration | float>，timeout=<duration>
2.4. 告警管理
Prometheus可定義告警規則，並在告警條件達成告警。告警的觸發條件是一個查詢表達式。告警規則可配置在Prometheus服務端的配置文件中。
由下圖可以看到配置的告警規則中，我們將“sum_over_time(vehicle_passed_num{instance="viid",job="zhangkai"}[5m]) < 200”這個表達式作爲告警規則配置在服務器端，當5分鐘內所有車道的過車總數小於觸發告警。
在Prometheus的服務端配置文件中可設置告警觸發後發送的目標地址，如我們配置的告警發送地址爲“172.16.64.159:8081”。使用抓包工具抓取這個地址發送的告警，可以看到在URI爲“/api/v1/alerts”的地址上。
Prometheus服務器發送了告警的POST請求，請求消息體格式爲JSON格式，示例如下：
[
{
"labels": {
"alertname": "5分鐘內過車數據小於200",
"instance": "viid",
"job": "zhangkai",
"lane_no": "1",
"status": "warning",
"tollgate_no": "2",
"value": "129"
},
"annotations": {
"description": "viid:5分鐘內過車數據小於200:129",
"summary": "viid:5分鐘內過車數據小於200:129"
},
"startsAt": "2019-07-19T06:42:08.639138396Z",
"endsAt": "2019-07-19T06:45:08.639138396Z",
"generatorURL": "http://68724a9ce8bb:9090/graph?g0.expr=sum_over_time%28vehicle_passed_num%7Binstance%3D%22viid%22%2Cjob%3D%22zhangkai%22%7D%5B5m%5D%29+%3C+200\u0026g0.tab=1"
},
{
"labels": {
"alertname": "5分鐘內過車數據小於200",
"instance": "viid",
"job": "zhangkai",
"lane_no": "1",
"status": "warning",
"tollgate_no": "3",
"value": "193"
},
"annotations": {
"description": "viid:5分鐘內過車數據小於200:193",
"summary": "viid:5分鐘內過車數據小於200:193"
},
"startsAt": "2019-07-19T06:42:08.639138396Z",
"endsAt": "2019-07-19T06:45:08.639138396Z",
"generatorURL": "http://68724a9ce8bb:9090/graph?g0.expr=sum_over_time%28vehicle_passed_num%7Binstance%3D%22viid%22%2Cjob%3D%22zhangkai%22%7D%5B5m%5D%29+%3C+200\u0026g0.tab=1"
}
]