目前大部分的互聯網企業基本上都有搭建自己的大數據集群，為了能更好讓我們的大數據集群更加高效安全的工作，一個優秀的監控方案是必不可少的；所以今天給大家帶來的這篇文章就是講阿里云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在大数据集群监控中的方案与实战的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。