背景介绍
作为一名 infra，管理平台的各种基础组建以及基本的服务质量是必修的功课，而如何对复杂和繁多的基础平台，甚至包括上面运行的 ops 系统、业务系统，其稳定性的各项指标都是衡量 infra 是否称职的非常重要的标准。
单纯离散的指标本身是没有实际意义的，只有将离散的指标通过某种方式进行存储，并支持对终端用户友好的查询以及聚合，才会真正的有意义。因此，一个性能足够的，分布式的，用户友好且方便下面 devops 团队进行部署的 TSDB ( Time SeriesDatabase )就成了一个不可缺少的系统。
常见的 TSDB 包括 InfluxDB, OpenTSDB , Prometheus 等，其中，开源版本的 InfluxDB 虽然优秀，但并不支持集群部署，且 TICK STACK 本身对数据清洗的灵活性支持并不太好，直接使用开源版本，会有统计信息被收集并上报；而 OpenTSDB 由于基于 HBase ，在部署时成本过高，且本身并不是一套完整的监控系统，而基于 Prometheus 与 TiKV 进行开发的话，整个系统可在保持最简洁的同时，也有非常丰富的生态支持。
因此，基于实际情况，融云最终选择 TiPrometheus 作为 infra 部的监控平台存储方案。
项目简介
上图为 Prometheus 的官方系统架构图，而实现 TiPrometheus ，用到了上图中没有体现到的一个 Prometheus 的功能：remote storage ，如其名所示，其主要功能是给 Prometheus 提供了远程写的能力，这个功能对于查询是透明的，主要用于长存储。而我们当时的 TiPrometheus 实现了基于 TiKV 以及 PD 实现的 Prometheus 的 remote storage 。
核心实现
Prometheus 记录的数据结构分为两部分 label 及 samples 。 label 记录了一些特征信息，samples 包含了指标数据和 timestamp 。
"labels": [{
"job": "node",
"instance": "123.123.1.211:9090",
}]
"samples":[{
"timestamp": 1473305798
"value": 0.9
}]
label 和时间范围结合，可以查询到需要的 value。
为了查询这些记录，需要构建两种索引 label index 和 time index，并以特殊的 key 存储 value 。
label index
每对 label 为会以 index:label:<name>#<latency> 为 key ，labelID 为 value 存入。新的记录会 comma 分割追加到 value 后面。这是一种搜索中常用的倒排索引。
time index
每个 sample 项会以 index:timeseries:<labelID>:<splitTime> 为 key，timestamp 为 value，splitTime 为时间切片的起始点。追加的 timestamp 同样以 comma 分割。
doc 存储
我们将每一条 samples 记录以 timeseries:doc:<labelID>:<timestamp> 为 key 存入 TiKV，其中 labelID 是 label 全文的散列值。
下面做一个梳理：
写入过程
1. 生成 labelID
2. 构建 time index，index:timeseries:<labelID>:<splitTime>"ts,ts"
3. 写入时序数据 timeseries:doc:<labelID>:<timestamp> "value"
4. 写入时序数据 timeseries:doc:<labelID>:<timestamp> "value"
查询过程
1. 根据倒排索引查出 labelID 的集合，多对 label 的查询会对 labelID 集合求交集。
2. 根据 labelID 和时间范围内的时间分片查询包含的 timestamp。
3. 根据 labelID 和 timestamp 查出所需的 value。
Why TiPrometheus
该项目最初源于参加 PingCAP 组织的 Hackathon，当时希望与参与者一起完成大家脑海里的想法，其实最重要的事情就是，做出来的东西并不是为了单纯的 demo，而是要做一个在实际工作中应用于生产环境的实际能力，且能解决生产中的问题。
刚开始还有过各种奇思妙想，包括在 TiSpark 上做一套 ML ，Hadoop over TiKV等，不过这些想法实现起来都有些过于硬核，对于只有两天工作时间就需要完成的项目来说，可能性太小；或者说，如果希望实现 demo ，所需 hack 的点过多。而 geo 全文检索在融云现有的生产上，以及现有的系统中，也并没有需要去填补的大坑，因此，也就没有什么必要去在这方面花费力气去解决一个并不存在的问题。
由于 IM 服务是一种计算密集型的服务，且服务质量是融云的核心竞争力；而目前存储资源呈现出零散分布的节点，且每个节点的存储资源使用率并不高，为了最大化利用现有的闲置资源，融云最终设计并实现了这套 TiPrometheus 系统。
Result
打通了 TiKV 与 Prometheus ，为基于 K , V 存储的时序数据库设计提供了一个可行的思路。
为 Prometheus 的长存储提供了一套实用的解决方案。
已经在融云内部生产环境中进行部署与试用，并将逐步替换现有方案。
