共计 2552 个字符，预计需要花费 7 分钟才能阅读完成。
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！
