背景介紹：
作為一名 Infra羹奉，管理平臺的各種基礎(chǔ)組建以及基本的服務(wù)質(zhì)量是必修的功課骑脱，而如何對復(fù)雜和繁多的基礎(chǔ)平臺渴庆，甚至包括上面運行的 Ops 系統(tǒng)、業(yè)務(wù)系統(tǒng)捺氢，其穩(wěn)定性的各項指標都是衡量 Infra 是否稱職的非常重要的標準藻丢。
單純離散的指標本身是沒有實際意義的，只有將離散的指標通過某種方式進行存儲摄乒，并支持對終端用戶友好的查詢以及聚合悠反，才會真正的有意義。因此馍佑，一個性能足夠的斋否，分布式的，用戶友好且方便下面 DevOps 團隊進行部署的 TSDB ( Time Series Database )就成了一個不可缺少的系統(tǒng)拭荤。
常見的 TSDB 包括 InfluxDB , OpenTSDB , Prometheus 等茵臭，其中，開源版本的 InfluxDB 雖然優(yōu)秀舅世，但并不支持集群部署旦委，且 TICK Stack 本身對數(shù)據(jù)清洗的靈活性支持并不太好，直接使用開源版本雏亚，會有統(tǒng)計信息被收集并上報缨硝；而 OpenTSDB 由于基于 HBase ，在部署時成本過高罢低，且本身并不是一套完整的監(jiān)控系統(tǒng)查辩，而基于 Prometheus 與 TiKV 進行開發(fā)的話，整個系統(tǒng)可在保持最簡潔的同時，也有非常豐富的生態(tài)支持宜岛。
因此长踊，基于實際情況，融云最終選擇 TiPrometheus 作為 Infra 部的監(jiān)控平臺存儲方案萍倡。
項目簡介：
上圖為 Prometheus 的官方系統(tǒng)架構(gòu)圖身弊，而實現(xiàn) TiPrometheus ，用到了上圖中沒有體現(xiàn)到的一個 Prometheus 的功能：Remote Storage 遣铝，如其名所示佑刷，其主要功能是給 Prometheus 提供了遠程寫的能力，這個功能對于查詢是透明的酿炸，主要用于長存儲。而我們當時的 TiPrometheus 實現(xiàn)了基于 TiKV 以及 PD 實現(xiàn)的 Prometheus 的 Remote Storage 涨冀。
核心實現(xiàn)
Prometheus 記錄的數(shù)據(jù)結(jié)構(gòu)分為兩部分 Label 及 Samples 填硕。 Label 記錄了一些特征信息，Samples 包含了指標數(shù)據(jù)和 Timestamp 鹿鳖。
Label 和時間范圍結(jié)合扁眯，可以查詢到需要的 Value 。
為了查詢這些記錄翅帜，需要構(gòu)建兩種索引 Label Index 和 Time Index 姻檀，并以特殊的 Key 存儲 Value 。
l Label Index
每對 Label 為會以 index:label:<name>#<latency> 為 key 涝滴，labelID 為 Value 存入绣版。新的記錄會 "," 分割追加到 Value 后面。這是一種搜索中常用的倒排索引歼疮。
l Time Index
每個 Sample 項會以 index:timeseries:<labelID>:<splitTime> 為 Key杂抽，Timestamp 為 Value ，SplitTime 為時間切片的起始點韩脏。追加的 Timestamp 同樣以","分割缩麸。
l Doc 存儲
我們將每一條 Samples 記錄以 timeseries:doc:<labelID>:<timestamp> 為 Key 存入 TiKV ，其中 LabelID 是 Label 全文的散列值赡矢。
下面做一個梳理：
寫入過程
1. 生成 labelID
2. 構(gòu)建 time index杭朱，index:timeseries:<labelID>:<splitTime>"ts,ts"
3. 寫入時序數(shù)據(jù) timeseries:doc:<labelID>:<timestamp> "value"
4. 寫入時序數(shù)據(jù) timeseries:doc:<labelID>:<timestamp> "value"
查詢過程
1. 根據(jù)倒排索引查出 labelID 的集合，多對 Label 的查詢會對 labelID 集合求交集吹散。
2. 根據(jù) labelID 和時間范圍內(nèi)的時間分片查詢包含的 Timestamp 弧械。
3. 根據(jù) labelID 和 Timestamp 查出所需的 Value 。
Why TiPrometheus
該項目最初源于參加 PingCAP 組織的 Hackathon 送浊，當時希望與參與者一起完成大家腦海里的想法梦谜，其實最重要的事情就是，做出來的東西并不是為了單純的 Demo ，而是要做一個在實際工作中應(yīng)用于生產(chǎn)環(huán)境的實際能力唁桩，且能解決生產(chǎn)中的問題闭树。
剛開始還有過各種奇思妙想，包括在 TiSpark 上做一套 ML 荒澡，Hadoop over TiKV 等报辱，不過這些想法實現(xiàn)起來都有些過于硬核，對于只有兩天工作時間就需要完成的項目來說单山，可能性太邪帧；或者說米奸，如果希望實現(xiàn) Demo 昼接，所需 Hack 的點過多。而 GEO 全文檢索在融云現(xiàn)有的生產(chǎn)上悴晰，以及現(xiàn)有的系統(tǒng)中慢睡，也并沒有需要去填補的大坑，因此铡溪，也就沒有什么必要去在這方面花費力氣去解決一個并不存在的問題漂辐。
由于 IM 服務(wù)是一種計算密集型的服務(wù)，且服務(wù)質(zhì)量是融云的核心競爭力棕硫；而目前存儲資源呈現(xiàn)出零散分布的節(jié)點髓涯，且每個節(jié)點的存儲資源使用率并不高，為了最大化利用現(xiàn)有的閑置資源哈扮，融云最終設(shè)計并實現(xiàn)了這套 TiPrometheus 系統(tǒng)纬纪。
Result
打通了 TiKV 與 Prometheus ，為基于 K , V 存儲的時序數(shù)據(jù)庫設(shè)計提供了一個可行的思路灶泵。
為 Prometheus 的長存儲提供了一套實用的解決方案育八。
