OpenTSDB监控系统的研究和介绍

2022-02-11 00:00:00 数据 集群 时间 系统 据点

一、背景介绍

此次航天局为了让天宫一号与神舟九号载人交会顺利对接成功,采用了新一代数值天气预报系统为神九保驾护航。新一代数值天气预报系统是中国国内技术先进、分辨率高、预报时效长的数值天气预报系统。新系统在火箭燃料加注、飞船发射和返回、载人交会对接等关键节点发挥重要作用。 同样,作为后台系统或网站的运维,我们同样需要类似的监控或预报系统快速发现各种不稳定现象和解决性能问题以达到SLA(服务等级协议)的标准。

你有没有厌倦那个拥有10年以上寿命的监控系统?

它常常会出现这样的问题:

1)中心化数据存储进而导致单点故障。

2)有限的存储空间。

3)数据会因为时间问题而变得不准确。

4)不易于定制图形。

5)不能扩展采集数据点到100亿级别。

6)不能扩展metrics到K级别。

7)不支持秒级别的数据。

这里介绍一个开源监控系统OpenTSDB,它可以解决上面的问题:

  • 它用hbase存储所有的时序(无须采样)来构建一个分布式、可伸缩的时间序列数据库。
  • 它支持秒级数据采集所有metrics,支持存储,可以做容量规划,并很容易的接入到现有的报警系统里。
  • OpenTSDB可以从大规模的集群(包括集群中的网络设备、操作系统、应用程序)中获取相应的metrics并进行存储、索引以及服务,从而使得这些数据更容易让人理解,如web化,图形化等。


对于运维工程师而言,OpenTSDB可以获取基础设施和服务的实时状态信息,展示集群的各种软硬件错误,性能变化以及性能瓶颈。对于管理者而言,OpenTSDB可以衡量系统的SLA,理解复杂系统间的相互作用,展示资源消耗情况。集群的整体作业情况,可以用以辅助预算和集群资源协调。对于开发者而言,OpenTSDB可以展示集群的主要性能瓶颈,经常出现的错误,从而可以着力重点解决重要问题。

二、架构Overview



OpenTSDB使用hbase作为存储中心,它无须采样,可以完整的收集和存储上亿的数据点,支持秒级别的数据监控,得益于hbase的分布式列式存储,hbase可以灵活的支持metrics的增加,可以支持上万机器和上亿数据点的采集。在OpenTSDB中,TSD是hbase对外通信的daemon程序,没有master/slave之分,也没有共享状态,因此利用这点和hbase集群的特点就可以消除单点。用户可以通过telnet或者http协议直接访问TSD接口,也可以通过rpc访问TSD。每一个需要获取metrics的Servers都需要设置一个Collector用来收集时间序列数据。这个Collector就是你收集数据的脚本。

如果想快速地展示mysql中在一段时间内执行delete子句的数量,慢查询的数量,创建的临时文件数量以及99%的延迟数量等等。OpenTSDB则可以非常容易存储和处理百万级别以上的数据点,并能实时动态的生成对应的图,如下图



三、在hbase中存储时间序列

OpenTSDB使用async hbase ,这是个完全异步、非阻塞、线程安全、HBase api,使用更少的线程、锁以及内存可以提供更高的吞吐量,特别对于大量的写操作。下图(图三)为读写流程。



在hbase中,表结构的设计对性能具有很大的影响,其中tsdb-uid表和tsdb表见表一和表二。

表1、tsdb-uid



表2、tsdb



四、某公司的实例

随着业务的发展和扩张,使得流量快速增长以及业务逻辑变得越来越复杂。进而使得引擎随时都会出现各种瓶颈,因此提前知道引擎的变化状态显得尤为重要,如全量和增量的增长趋势图,见下图(图4)



在OpenTSDB,一个数据点可以表示为:

1)一个指标名称。

2)UNIX时间戳。

3)一个值(64位整数或双精度浮点值)。

4)标识这个数据点的一组标记tags(键-值对)。

下面四个数据点来源于图4,都是采集的metrics为index.full_count,代表引擎索引doc数;标记tags为来自哪个domain(代表机房),area和app代表应用,cluster代表索引表,partition代表列。Metrics和tags加起来就是一个时间序列。上图图3为一系列下面的数据点绘画而成(数据经过了处理,不代表真实数据)。

index.full_count 1341069600 156866750 domain=domain_E area=1 app=jqb cluster=epid partition=partition_16384_32767index.full_count 1341069600 155819640 domain=domain_E area=1 app=jqb cluster=epid partition=partition_32768_49151index.full_size 1341069000 18561 domain=domain_D area=1 app=jqb cluster=b2c partition=partition_0_16383index.full_size 1341069000 18554 domain=domain_D area=1 app=jqb cluster=b2c partition=partition_16384_32767index.full_count 1341069200 11421051 domain=domain_G area=1 app=jqb cluster=b2c partition=partition_16384_32767、

相关文章