茁壮成长首选监测方案的定时数据库选择和登陆实践
为了保证互联网服务的高效和稳定,我们需要监控公司所有的节点服务器(包括云服务器)、交换机及路由器。我们需要通过实时产生的数据来判断设备是否工作、检测通讯是否延时、观测 SNMP OID 流量是否正常等,从而保障运维与网络人员及时发现问题并修复。
这类数据是非常典型的时序数据,应该如何高效地处理呢?现在市面上有几款非常流行的时序数据库(Time Series Database)产品。应该如何评估并选择适合我们业务场景的技术平台呢?
针对该业务场景,我们调研了如下几个产品:Elasticsearch、InfluxDB 和 TDengine。具体对比如下。
Elasticsearch
-
优点:可以分布式部署,可以无障碍插入,支持任意的字段类型,查询速度快。 -
缺点:只适合记录日志且并发数据量不大的情况,对于海量设备的时序数据写入有性能问题。
InfluxDB
-
优点:支持无模式(Schemaless 写入),限制较少。 -
缺点:当面对大批量的数据同时插入或读取时,内存容易被占满,导致死机。尤其是其中的轮询机制,在检验过期数据时,内存占用特别大。此外,在读取数据时,读出来的是列表,可读性差,解析比较麻烦。
TDengine
-
优点:列式存储以及“一个设备一张表”的模型与我们业务场景十分契合。此外,还可以兼容我们以前使用 InfluxDB 时所习惯的插入方式,代码可读性强,支持强绑定参数。在执行海量数据的查询时,响应速度比 InfluxDB 更快。 -
缺点:Schemeless 的支持还在持续完善之中。
接下来我们又继续对比了 InfluxDB 和 TDengine。InfluxDB 单节点性能不足,集群闭源且性能未知。反观 TDengine,其集群功能是开源的,且保留了企业版的部分核心功能。这让我们可以直接非常深入地了解 TDengine 的优劣。从这方面考虑,我们选择了 TDengine。而且在实际使用中,我们又发现了 TDengine 的一大优势,其“一个设备一张表”的模型十分契合我们的实际场景。
在引入 TDengine 之后,我们的系统架构如下图所示。
在该架构下,前端制定好规则下发(例如:流量阈值,延时阈值),后端看是否需要存储规则,或检查规则是否发生变化,然后把规则下发给 ETCD 来做定时任务调度。我们共有三个程序任务,通过 ETCD 管理,定时和各类设备通信,根据不同规则分别抓取各自需要的数据:
-
SNMP 引擎通过 OID 监控网络设备各项指标 -
TCPing 引擎用于监控服务器 TCP 端口状态 -
ICMP 引擎重点采集接收或返回数据的时间
在使用过程中,花时间相对较多的大概是无模式插入的摸索吧。
最后,TDengine 的支持团队相当负责,配合积极,让我们快速上手了这款轻便易用、性能超高的时序数据库。目前我们只接入了一部分服务器及设备,后续我们计划把公司全国范围内所有的服务器都接入进来,也会推荐公司更多部门使用。一切顺利的话,我们也会考虑包括仓库运货机器人,物流线设备等更多应用场景。