时序数据库OpenTSDB简介
一、背景
一些老的监控系统，它常常会出现这样的问题：
1）中心化数据存储进而导致单点故障。
2）有限的存储空间。
3）数据会因为时间问题而变得不准确。
4）不易于定制图形。
5）不能扩展采集数据点到100亿级别。
6）不能扩展metrics到K级别。
7）不支持秒级别的数据。
OpenTSDB解决上面的问题：
1、它用hbase存储所有的时序（无须采样）来构建一个分布式、可伸缩的时间序列数据库。
2、它支持秒级数据采集所有metrics，支持永久存储，可以做容量规划，并很容易的接入到现有的报警系统里。
3、OpenTSDB可以从大规模的集群（包括集群中的网络设备、操作系统、应用程序）中获取相应的metrics并进行存储、索引以及服务
从而使得这些数据更容易让人理解，如web化，图形化等。
对于运维工程师而言，OpenTSDB可以获取基础设施和服务的实时状态信息，展示集群的各种软硬件错误，性能变化以及性能瓶颈。
对于管理者而言，OpenTSDB可以衡量系统的SLA，理解复杂系统间的相互作用，展示资源消耗情况。集群的整体作业情况，可以用以辅助预算和集群资源协调。
对于开发者而言，OpenTSDB可以展示集群的主要性能瓶颈，经常出现的错误，从而可以着力重点解决重要问题。
二、OpenTSDB是什么
OpenTSDB是一个时间序列数据库。基于Hbase的分布式的，可伸缩的时间序列数据库。
主要用途，就是做监控系统；譬如收集大规模集群（包括网络设备、操作系统、应用程序）的监控数据并进行存储，它支持秒级数据采集所有metrics，支持永久存储，可以做容量规划，并很容易地接入到现有的报警系统里。OpenTSDB可以从大规模的集群（包括集群中的网络设备、操作系统、应用程序）中获取相应的metrics并进行存储、索引以及服务，从而使得 这些数据更容易让人理解，如web化，图形化等。
架构
在openTSDB中，TSD是hbase对外通信的daemon程序，没有master/slave之分，也没有共享状态，因此利用这点和hbase集群的特点就可以消除单点。用户可以通过telnet或者http协议直接访问TSD接口，也可以通过RPC访问TSD。每一个需要获取metrics的Servers都需要设置一个Collector用来收集时间序列数据。这个Collector就是你收集数据的脚本。
TSDB数据存储示例
三、名词解释
In OpenTSDB, a time series data pointconsists of:
A metric name.
A UNIX timestamp (seconds or millisecondssince Epoch).
A value (64 bit integer orsingle-precision floating point value), a JSON formatted event or ahistogram/digest.
A set of tags (key-value pairs) thatdescribe the time series the point belongs to.
{
"metric":"temperature",
"timestamp":1567675709879,
"value":20.5,
"tags":{
"host":"device-1"
}
}
四、数据查询
监控场景中，我们可以这样定义一个监控指标：
OpenTSDB支持的查询场景
指定指标名称和时间范围，给定一个或多个标签名称和标签的值作为条件，查询出所有的数据。
以上面那个例子举例，我们可以查询：
sys.cpu.user (host=,cpu=)(1465920000<= timestamp < 1465923600)
查询凌晨0点到1点之间，所有机器的所有CPU核上的用户态CPU消耗。
sys.cpu.user (host=10.101.168.111,cpu=*)(1465920000<= timestamp < 1465923600)
查询凌晨0点到1点之间，某台机器的所有CPU核上的用户态CPU消耗。
sys.cpu.user (host=10.101.168.111,cpu=0)(1465920000<= timestamp < 1465923600)
查询凌晨0点到1点之间，某台机器的第0个CPU核上的用户态CPU消耗。
存储优化
rowkey采用metricname + timestamp + tags的组合，唯一确定一个指标值。
核心优化：缩短rowkey
OpenTSDB采用的策略是：为每个metric、tag key和tagvalue都分配一个UID，UID为固定长度三个字节。
Rowley的长度大大的缩短了，好处：
- 节省存储空间
- 提高查询效率：减少key匹配查找的时间
- 提高传输效率：不光节省了从文件系统读取的带宽，也节省了数据返回占用的带宽，提高了数据写入和读取的速度。
- 缓解内存压力：String存储的metric name、tagkey或tag value，现在均可以用3个字节的byte array替换，大大节省了内存占用
其它存储优化：减少Key-Value数
合并行和列，进一步缩短存储量。
其它存储优化：并发写优化
进行预分桶，避免写热点
五、常用HTTP API
5.1 插入数据：/api/put
5.2 查询数据：/api/query
5.3其它HTTP API
具体参考官网：
http://opentsdb.net/docs/build/html/api_http/index.html
OpenTSDB安装
参考官网：
http://opentsdb.net/docs/build/html/installation.html
六、其它TSDB对比
TSDB Ranking
TSDB Ranking
OpenTSDB VS InfuxTSDB
七、OpenTSDB简单使用
7.1 创建metric
创建metric，两种方式，选择其一即可。不管何种导入方式都必须先设置metric。
- 事先在opentsdb中创建metric。如生成两个名为
mymetric.data_1和mymetric.data_2的metric。如下：
tsdb mkmetric mymetric.data_1 mymetric.data_21
2.设置自动生成metric。修改opentsdb.conf设置：
tsd.core.auto_create_metrics = true
7.2 数据写入
7.2.1 telnet方式
telnet localhost 4242
put sys.cpu.user 1436333416 23 host=web01 user=10001
7.2.2 API方式
URL：
http://192.168.0.1:4242/api/put?summary
参数：
[
{
"metric": "sys.cpu.nice",
"timestamp": 1502190111,
"value": 18,
"tags": {
"host": "web01",
"dc": "lga"
}
},
{
"metric": "sys.cpu.nice",
"timestamp": 1502190171,
"value": 26,
"tags": {
"host": "web02",
"dc": "lga"
}
}
]
返回：
{
"success": 2,
"failed": 0
}
7.2.3 import方式，批量导入
导入文件格式：
[root@test0926ryc001-master2 test]# cat opentsdb.txt
mymetric.test.data 1479303678 0.841470984808 host=xyd_host
mymetric.test.data 1479303679 0.909297426826 host=xyd_host
mymetric.test.data 1479303680 0.14112000806 host=xyd_host
mymetric.test.data 1479303681 -0.756802495308 host=xyd_host
mymetric.test.data 1479303682 -0.958924274663 host=xyd_host
执行命令：
/root/src/opentsdb-2.4.0RC2/build/tsdb import --config=/root/src/opentsdb-2.4.0RC2/opentsdb.conf opentsdb.txt
7.3 数据查询
7.3.1 返回metric=test的最近10秒的所有时序数据
7.3.1.1 Get方式
/api/query?start=10s-ago&m=test
7.3.1.2 Post方式
{
"start": "10s-ago",
"queries": [{
"aggregator": "none",
"metric": "test"
}]
}
返回：
[
{
"metric": "test",
"tags": {
"device": "D47899",
"label": "6015",
},
"aggregateTags": [],
"dps": {
"1525343027": 26.26,
"1525343032": 25.32
}
},
{
"metric": "test",
"tags": {
"device": "D47899",
"label": "6019",
},
"aggregateTags": [],
"dps": {
"1525343027": 25.32,
"1525343032": 26.74
}
},
……
{
"metric": "test",
"tags": {
"device": "D47899",
"label": "6010",
},
"aggregateTags": [],
"dps": {
"1525343027": 26.8,
"1525343032": 25.75
}
}
]
7.3.2 使用filters实现tags条件查询
7.3.2.1 Get方式：
/api/query?start=10s-ago&m=sum:test{device=*，label=1001|1002}
注：device和label都为tag
7.3.2.2 Post方式：
{
"start": "10s-ago",
"queries": [
{
"aggregator": "sum",
"metric": "test",
"filters": [
{
"type":"wildcard",
"tagk":"device",
"filter":"*",
"groupBy":true
},
{
"type":"literal_or",
"tagk":"label",
"filter":"1001|1002",
"groupBy":true
}
]
}
]
}
返回：
[
{
"metric": "test",
"tags": {
"label": "1001",
"device": "A11223",
"status": "0"
},
"aggregateTags": [],
"dps": {
"1525344862": 24.76,
"1525344867": 24.98
}
},
{
"metric": "app.services.temperature",
"tags": {
"label": "1002",
"device": "A11224",
"status": "0"
},
"aggregateTags": [],
"dps": {
"1525344862": 25.75,
"1525344867": 24.74
}
}
]
7.3.3 对每个时序最近两小时的数据点按小时分组计算(使用downsample)
7.3.3.1 Get方式：
/api/query?start=2h-ago&m=sum:1h-count：test{device=*，label=1001|1002}
7.3.3.2Post方式：
{
"start": "2h-ago",
"queries": [
{
"aggregator": "sum",
"metric": "test",
"downsample": "1h-count",
"filters": [
{
"type":"literal_or",
"tagk":"device",
"filter":"*",
"groupBy":true
},
{
"type":"literal_or",
"tagk":"label",
"filter":"1001|1002",
"groupBy":true
}
]
}
]
}
返回：
[
{
"metric": "test",
"tags": {
"label": "1001",
"device": "A11223",
"status": "0"
},
"aggregateTags": [],
"dps": {
"1525341600": 720,
"1525345200": 91
}
},
{
"metric": "test",
"tags": {
"label": "1002",
"device": "A11224",
"status": "0"
},
"aggregateTags": [],
"dps": {
"1525341600": 720,
"1525345200": 91
}
}
]
