目前大部分的互联网企业基本上都有搭建自己的大数据集群，为了能更好让我们的大数据集群更加高效安全的工作，一个优秀的监控方案是必不可少的；所以今天给大家带来的这篇文章就是讲阿里云 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
本文作者：焦先阅读原文
本文为云栖社区原创内容，未经允许不得转载。