一、背景
一些老的监控系统,它常常会出现这样的问题:
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
}
}
]
网友评论