背景
對很多人來說雁竞，未知钦椭、不確定、不在掌控的東西浓领，會有潛意識的逃避。當我第一次接觸 Prometheus 的時候也有類似的感覺势腮。對初學者來說联贩， Prometheus 包含的概念太多了，門檻也太高了捎拯。
概念：Instance泪幌、Job盲厌、Metric、Metric Name祸泪、Metric Label吗浩、Metric Value、Metric Type（Counter没隘、Gauge懂扼、Histogram、Summary）右蒲、DataType（Instant Vector阀湿、Range Vector、Scalar瑰妄、String）陷嘴、Operator、Function
馬云說：“雖然阿里巴巴是全球最大的零售平臺间坐，但阿里不是零售公司灾挨，是一家數(shù)據(jù)公司”。Prometheus 也是一樣竹宋，本質(zhì)來說是一個基于數(shù)據(jù)的監(jiān)控系統(tǒng)劳澄。
日常監(jiān)控
假設需要監(jiān)控 WebServerA 每個API的請求量為例，需要監(jiān)控的維度包括：服務名（job）逝撬、實例IP（instance）浴骂、API名（handler）、方法（method）宪潮、返回碼(code)溯警、請求量（value）。
如果以SQL為例狡相，演示常見的查詢操作：
查詢 method=put 且 code=200 的請求量(紅框)
SELECT * from http_requests_total WHERE code=”200” AND method=”put” AND created_at BETWEEN 1495435700 AND 1495435710;
查詢 handler=prometheus 且 method=post 的請求量(綠框)
SELECT * from http_requests_total WHERE handler=”prometheus” AND method=”post” AND created_at BETWEEN 1495435700 AND 1495435710;
查詢 instance=10.59.8.110 且 handler 以 query 開頭 的請求量(綠框)
SELECT*fromhttp_requests_totalWHEREhandler=”query”ANDinstance=”10.59.8.110”ANDcreated_atBETWEEN1495435700AND1495435710;
通過以上示例可以看出梯轻，在常用查詢和統(tǒng)計方面，日常監(jiān)控多用于根據(jù)監(jiān)控的維度進行查詢與時間進行組合查詢尽棕。如果監(jiān)控100個服務喳挑，平均每個服務部署10個實例，每個服務有20個API滔悉，4個方法伊诵，30秒收集一次數(shù)據(jù)，保留60天回官。那么總數(shù)據(jù)條數(shù)為：100(服務) 10（實例） 20（API） 4（方法） 86400（1天秒數(shù)）* 60(天) / 30（秒）= 138.24 億條數(shù)據(jù)曹宴，寫入、存儲歉提、查詢?nèi)绱肆考壍臄?shù)據(jù)是不可能在Mysql類的關系數(shù)據(jù)庫上完成的笛坦。因此 Prometheus 使用 TSDB 作為存儲引擎区转。
存儲引擎
TSDB 作為 Prometheus 的存儲引擎完美契合了監(jiān)控數(shù)據(jù)的應用場景
存儲的數(shù)據(jù)量級十分龐大
大部分時間都是寫入操作
寫入操作幾乎是順序添加，大多數(shù)時候數(shù)據(jù)到達后都以時間排序
寫操作很少寫入很久之前的數(shù)據(jù)版扩，也很少更新數(shù)據(jù)废离。大多數(shù)情況在數(shù)據(jù)被采集到數(shù)秒或者數(shù)分鐘后就會被寫入數(shù)據(jù)庫
刪除操作一般為區(qū)塊刪除，選定開始的歷史時間并指定后續(xù)的區(qū)塊礁芦。很少單獨刪除某個時間或者分開的隨機時間的數(shù)據(jù)
基本數(shù)據(jù)大蜻韭，一般超過內(nèi)存大小。一般選取的只是其一小部分且沒有規(guī)律宴偿，緩存幾乎不起任何作用
讀操作是十分典型的升序或者降序的順序讀
高并發(fā)的讀操作十分常見
那么 TSDB 是怎么實現(xiàn)以上功能的呢湘捎？
"labels": [{"latency":"500"}]"samples":[{"timestamp":1473305798,"value":0.9}]
原始數(shù)據(jù)分為兩部分 label, samples。前者記錄監(jiān)控的維度（標簽:標簽值）窄刘，指標名稱和標簽的可選鍵值對唯一確定一條時間序列（使用 series_id 代表）窥妇；后者包含包含了時間戳（timestamp）和指標值（value）。
series^│. . . . . . . . . . . .? server{latency="500"}│. . . . . . . . . . . .? server{latency="300"}│. . . . . . . . . .? .? server{}│. . . . . . . . . . . . v<--------time---------->
TSDB 使用 timeseries:doc:: 為 key 存儲 value娩践。為了加速常見查詢查詢操作：label 和 時間范圍結(jié)合活翩。TSDB 額外構(gòu)建了三種索引：Series, Label Index 和 Time Index。
以標簽 latency 為例：
Series
存儲兩部分數(shù)據(jù)翻伺。一部分是按照字典序的排列的所有標簽鍵值對序列（series）材泄；另外一部分是時間線到數(shù)據(jù)文件的索引，按照時間窗口切割存儲數(shù)據(jù)塊記錄的具體位置信息吨岭，因此在查詢時可以快速跳過大量非查詢窗口的記錄數(shù)據(jù)
Label Index
每對 label 為會以 index:label: 為 key拉宗，存儲該標簽所有值的列表，并通過引用指向 Series 該值的起始位置辣辫。
Time Index
數(shù)據(jù)會以 index:timeseries:: 為 key旦事，指向?qū)獣r間段的數(shù)據(jù)文件
數(shù)據(jù)計算
強大的存儲引擎為數(shù)據(jù)計算提供了完美的助力，使得 Prometheus 與其他監(jiān)控服務完全不同急灭。Prometheus 可以查詢出不同的數(shù)據(jù)序列姐浮，然后再加上基礎的運算符，以及強大的函數(shù)葬馋，就可以執(zhí)行 metric series 的矩陣運算（見下圖）卖鲤。
如此，Promtheus體系的能力不弱于監(jiān)控界的“數(shù)據(jù)倉庫”+“計算平臺”畴嘶。因此蛋逾，在大數(shù)據(jù)的開始在業(yè)界得到應用，就能明白窗悯，這就是監(jiān)控未來的方向区匣。
一次計算，處處查詢
當然蟀瞧，如此強大的計算能力沉颂，消耗的資源也是挺恐怖的。因此悦污，查詢預計算結(jié)果通常比每次需要原始表達式都要快得多铸屉，尤其是在儀表盤和告警規(guī)則的適用場景中，儀表盤每次刷新都需要重復查詢相同的表達式切端，告警規(guī)則每次運算也是如此彻坛。因此，Prometheus提供了 Recoding rules踏枣，可以預先計算經(jīng)常需要或者計算量大的表達式昌屉，并將其結(jié)果保存為一組新的時間序列， 達到 一次計算茵瀑，多次查詢的目的间驮。
本文作者：cyningsun
本文地址：
https://www.cyningsun.com/02-22-2020/hidden-secret-to-understanding-prometheus.html
