OpenTSDB是一个经典的时序数据库系统，它没有开发本人的存储引擎，而是基于HBase，对于曾经有HBase根底服务的企业而言，升高了门槛。而且得益于其先发劣势，OpenTSDB在运维监控畛域有不少利用。不过也因为要依赖HBase，零碎的性能、压缩效率逐步成为瓶颈。随着业务零碎规模的扩充，部署老本、运行效率等方面的问题日益严重。此外，OpenTSDB的性能降级也比拟迟缓。 与之相比，TDengine有着显著的劣势：

  • 数据写入和查问的性能远超OpenTSDB；
  • 针对时序数据的高效压缩机制，压缩后在磁盘上的存储空间不到OpenTSDB的1/5；
  • 装置部署非常简单，繁多安装包实现装置部署，除了taosAdapter须要依赖Go运行环境外，不依赖其余第三方软件，整个装置部署十分迅速;
  • 提供的内建函数笼罩OpenTSDB反对的全副查问函数，还反对更多的时序数据查问函数、标量函数及聚合函数，反对多种工夫窗口聚合、连贯查问、表达式运算、多种分组聚合、用户定义排序、以及用户定义函数等高级查问性能。采纳类SQL的语法规定，更加简略易学，基本上没有学习老本。
  • 反对多达128个标签，标签总长度可达到16KB；
  • 除HTTP之外，还提供Java、Python、C、Rust、Go等多种语言的接口。

如果咱们将本来运行在OpenTSDB上的利用迁徙到TDengine上，不仅能够无效升高计算和存储资源的占用、缩小部署服务器的规模，还可能极大缩小运行保护老本，让运维管理工作更简略、更轻松，大幅升高总领有老本。

本文将以“应用最典型并广泛应用的运维监控场景”来阐明，不必编写一行代码，如何将基于OpenTSDB的利用疾速、平安、牢靠地迁徙到TDengine之上。

1、典型运维监控利用场景

一个典型的运维监控利用场景的零碎整体的架构如下图（图1）所示。


图1.运维监控场景典型架构

在该利用场景中，蕴含了部署在应用环境中负责收集机器度量（Metrics）、网络度量（Metrics）以及利用度量（Metrics）的Agent工具，汇聚Agent所收集信息的数据收集器，负责数据长久化存储和治理的零碎以及监控数据可视化工具（例如：Grafana等）。

其中，部署在利用节点的Agent负责向collectd/Statsd提供不同起源的运行指标，collectd/StatsD则负责将汇聚的数据推送到OpenTSDB集群零碎，而后应用Grafana将数据以可视化的形式出现进去。

2、迁徙服务

  • TDengine装置部署

首先是TDengine的装置，从官网上下载TDengine最新稳定版，解压缩后运行install.sh进行装置。各种安装包的应用帮忙可参考《TDengine多种安装包的装置和卸载》。留神，装置实现当前，不要立刻启动taosd服务，在正确配置实现参数当前再启动。

  • 调整数据收集器配置

在TDengine 2.3版本中，在后盾服务taosd启动后，一个叫taosAdapter的HTTP的服务也会主动启用。利用taosAdapter，可能兼容Influxdb的Line Protocol和OpenTSDB的telnet/Json写入协定，所以咱们能够将collectd和StatsD收集的数据间接推送到TDengine。

如果应用collectd，批改其默认地位在/etc/collectd/collectd.conf的配置文件，使其指向taosAdapter部署的节点IP地址和端口。假如taosAdapter的IP地址为192.168.1.130，端口为6046，配置如下：

LoadPlugin write_tsdb<Plugin write_tsdb>    <Node>        Host "192.168.1.130"        Port "6046"        HostTags "status=production"        StoreRates false        AlwaysAppendDS false    </Node></Plugin>

这样collectd就能够通过taosAdapter将数据写入TDengine了。如果应用的是StatsD，能够相应地调整配置文件。

  • 调整看板（Dashborad）零碎

在数据可能失常写入TDengine后，能够调整适配Grafana，将写入TDengine的数据可视化出现进去。在TDengine的装置目录下有为Grafana提供的连贯插件（connector/grafanaplugin）。应用很简略：
首先将grafanaplugin目录下的dist目录整体拷贝到Grafana的插件目录（默认地址为/var/lib/grafana/plugins/），而后重启Grafana，即可在Add Data Source菜单下看见TDengine数据源。

此外，TDengine还提供了两套默认的Dashboard模板，供用户疾速查看保留到TDengine库里的信息。只须要其导入到Grafana中并激活。


图2.导入Grafana模板

至此，咱们就实现了将OpenTSDB替换成为TDengine的迁徙工作。能够看到整个流程非常简单，不须要写代码，只须要调整某个配置文件。

3、迁徙后架构

实现迁徙当前，此时的零碎整体的架构如下图（图3）所示，而整个过程中采集端、数据写入端、以及监控出现端均放弃了稳固，除了极少的配置调整外，不波及任何重要的更改和变动。


图3.迁徙实现后的零碎架构

OpenTSDB的次要利用场景就是运维监控，这种状况下咱们能够轻松实现向TDengine的迁徙，从而用上TDengine更加弱小的解决能力和查问性能。

在绝大多数运维监控场景中，如果领有一个小规模的OpenTSDB集群（3台及以下的节点）作为监控数据的存储端，依赖OpenTSDB所提供的数据存储和查问性能，那么能够平安地将其替换为TDengine，并节约更多的计算和存储资源。在等同计算资源配置状况下，单台TDengine即可实现3~5台OpenTSDB节点提供的服务能力。如果规模比拟大，那便须要采纳TDengine集群。

如果利用特地简单，或者应用领域并不是运维监控场景，你能够持续浏览下一篇文章，更加全面深刻地理解将OpenTSDB利用迁徙到TDengine的高级话题。

点击摸索taosAdapter！