阿里云TSDB在大数据集群监控中的方案与实战

96次阅读

共计 2962 个字符,预计需要花费 8 分钟才能阅读完成。

目前大部分的互联网企业基本上都有搭建自己的大数据集群,为了能更好让我们的大数据集群更加高效安全的工作,一个优秀的监控方案是必不可少的;所以今天给大家带来的这篇文章就是讲阿里云 TSDB 在上海某大型互联网企业中的大数据集群监控方案中的实战案例,希望能为感兴趣的同学提供一些帮助。
背景和需求
阿里云时序时空数据库 (原阿里云时间序列数据库, 简称 TSDB) 是一种高性能,低成本,稳定可靠的在线时序数据库服务;提供高效读写,高压缩比存储、时序数据插值及聚合计算,广泛应用于物联网(IoT)设备监控系统,企业能源管理系统(EMS),生产安全监控系统,电力检测系统等行业场景。TSDB 提供百万级时序数据秒级写入,高压缩比低成本存储、预降采样、插值、多维聚合计算,查询结果可视化功能;解决由于设备采集点数量巨大,数据采集频率高,造成的存储成本高,写入和查询分析效率低的问题。
Elastic MapReduce(EMR)是阿里云提供的一种大数据处理的系统解决方案。EMR 基于开源生态,包括 Hadoop、Spark、Kafka、Flink、Storm 等组件,为企业提供集群、作业、数据管理等服务的一站式企业大数据平台。
上海某大型互联网企业是阿里云 EMR 的 Top 客户,在阿里云上购买的 EMR 实例有近千台 hadoop 机器,这些机器目前除了阿里云本身 ECS 级别的监控以外,没有一套成熟的这对大数据的监控运维告警系统,对大数据业务来讲存在很大的风险。现在客户的需求是对购买的 EMR 集群做监控和告警,单台有 20 多个监控指标,采集精度可以根据客户需求调整,另外还要求对原有的业务无侵入,不需要业务层做太多的配置重启类操作。
痛点和挑战
该大型互联网企业客户最初计划采用的是 Prometheus 作为监控和告警解决方案,并且基于 Prometheus 的监控方案也在该企业内部其他系统应用了。
这里提到了 Prometheus,就多说几句。随着业内基于 Kubernetes 的微服务的盛行,其生态兼容的开源监控系统 Prometheus 也逐渐被大家热捧。
Prometheus 是一个开源监控系统,它前身是 SoundCloud 的监控系统,在 2016 年继 Kurberntes 之后,加入了 Cloud Native Computing Foundation。目前许多公司和组织开始使用 Prometheus,该项目的开发人员和用户社区非常活跃,越来越多的开发人员和用户参与到该项目中。
下图就是 prometheus 方案的架构:

这个方案在实际部署过程中发现 Prometheus 在存储和查询上存在性能的问题,主要是 Prometheus 本身采用的 local storage 方案在大数据量下的扩展性写入查询性能存在瓶颈。
另外在这个方案的适配性不强,要改很多参数重启才行,这对于线上正在运行的业务来说,是不可接受的,需要重新设计解决方案。
阿里云 TSDB 解决方案
监控和告警整体上来说包括三个环节:
1. 采集指标
2. 存储指标
3. 查询告警
因此基本方案就可以简化为:采集工具 + 数据库 + 查询告警。其中,数据库可以通过阿里云 TSDB 来解决存储和查询上的性能问题,查询告警可以通过成熟的开源工具 Grafana。由于该互联网企业客户的要求对原有的业务无侵入,不需要业务层做太多的配置重启类操作,因此解决方案的调研就重点落在了采集工具的调研上了。
对于采集工具而言,结合该互联网企业客户已经部署的 Prometheus,且阿里云 TSDB 兼容开源时序数据库 OpenTSDB 的写入和查询协议,因此从减少成本和工作量的角度来看,可以考虑的方式是有两种:
1. 使用 Prometheus 官方提供的开源的 OpenTSDB Adapter 对接原生的 Prometheus,实现数据写入到 TSDB。基本架构为:

这种方案和该互联网企业客户的开发同学沟通后,发现满足不了对业务无侵入,不重启的需求,因此选择放弃;
2. 采用其他开源工具,实现数据采集写入到 TSDB。开源社区较为活跃,已经提供了不少开源的采集工具,因此我门评估了以下几个开源的采集工具:

Collectd,https://collectd.org

telegraf, https://github.com/influxdata/telegraf

* statsd, https://github.com/etsy/statsd
tcollector, http://opentsdb.net/docs/build/html/user_guide/utilities/tcollector.html

从开发语言、部署方式以及是否支持定制开发等角度,我们初步选择 tcollector 作为采集工具。tcollector 是一个客户端程序,用来收集本机的数据,并将数据发送到 OpenTSDB。tcollector 可以为你做下面几件事:

运行所有的采集者并收集数据;
完成所有发送数据到 TSDB 的连接管理任务;
不必在你写的每个采集者中嵌入这些代码;
是否删除重复数据;
处理所有有线协议,以后今后的改进;

因此,基于 tcollector + TSDB + Grafana 的监控告警架构如下,其中 tcollector 以 http 协议从目标结点上拉取监控指标,并以 http 的 OpenTSDB 协议将指标推送至阿里云 TSDB。

这个方案在不修改 tcollector 源码的基础上,能够满足客户对 hadoop 的监控。但是在 PoC 后,客户增加了对 EMR 实例中其他大数据组件的监控需求,如 Hive, Spark, Zookeeper, HBase, Presto, Flink, azkaban, kafka, storm 等。
经过我们调研,tcollector 对于这些组件的支持程度如下:

原生支持:hbase;
需定制化开发,不重启实例:Hive, Spark, Zookeeper;
需定制化开发,需重启实例:Flink, azkaban, kafka, storm;

经过一定工作量的制化开发,基于 tcollector 的方案基本可以满足用户的需求。最终我们在该互联网企业客户的 EMR 大数据集群的监控告警方案架构为:

tcollector 非常简单易部署,可以简单高效地完成了客户的需求。而且配置部署时,可以不用区分大数据组件的角色,解决了之前开源采集工具需要针对不同角色,来手动配置并启动相应插件的问题。
至此,TSDB 完美得解决了该互联网企业客户大数据集群监控接入 TSDB 的案例,让 TSDB 在迈向完善生态的路上更进一步了。另外值得一提的是,为了解决目前广泛使用的 Prometheus 开源系统在大量时序数据的存储、写入和查询存在性能瓶颈问题,阿里云 TSDB 也已经开始兼容了 Prometheus 生态,并且已经在多个客户场景进行了实战。后面我们会推出针对 Prometheus 的系列文章,对 Prometheus 感兴趣或者已经是 Prometheus 用户但是遇到性能问题的同学可以持续关注我们。
阿里云时序时空数据库 TSDB 1 元购!立即体验:https://promotion.aliyun.com/ntms/act/tsdbtry.html?spm=5176.149792.775960.1.dd9e34e2zgsuEM&wh_ttid=pc

本文作者:焦先阅读原文
本文为云栖社区原创内容,未经允许不得转载。

正文完
 0