基于表格存储的高性能监控数据存储计算方案概述需求定义.PDF

基于表格存储的高性能监控数据存储计算方案 @ 阿里云十品 概述 随着软件架构的愈发复杂，了解系统现状、调查问题的困难度也增加了很多。此时，一套完善的 监控方案能够让开发和运维工程师快速排查问题，更好的维护系统的稳定性。 开源监控方案中，Zabbix 、Nagios 都是不错的监控软件，可以针对数十万的设备监控数百万的指 标，强大的功能让开发和运维都很赞叹。但是，网上经常看到的抱怨是其写入和存储能力的不足，以 Zabbix 为例，文章[1]提到使用NoSQL 方案（HBase、Cassandra、Riak）比利用传统RDBMS 方案（MySQL、 PostgreSQL、Oracle ）其性能提高了 1.5-3 倍。如果考虑到架构的扩展性以及存储空间的成本，NoSQL 方案还会更有优势，因为一般来说，NoSQL 的压缩效果都会更好。 下面我们将基于一个实例案例，来讲解如何使用阿里云NoSQL 服务“表格存储”来进行监控数据 的处理。下面叙述的过程中，我们不会直接拿出最好的方案，而是将逐步优化的思路整理出来分享给 大家，期望大家跟我们一起寻求更优的解决方案。心急的同学可以直接跳到最后看结论。 需求定义 一个典型的监控系统包括数据的采集、计算（实时计算和离线计算）、存储和展示，采集和展示 是相对独立的模块，这里我们只以存储为重点，在必要的时候也会对计算做相应的说明。 从业务角度看，监控系统需要完成如下功能： 1. 任何时候都要求能写入，不得丢点； 2. 给定某个机器，某个指标，能够查询该机器该指标在一段时间内的连续的值； 3. 给定某个机器，查询该机器所有指标在一段时间内的连续的值； 4. 给定某个指标，查询所有机器在一段时间内的连续的值； 5. 以上三点，时间段可以任意指定，从分钟到月均支持； 从系统设计角度看，监控对存储系统的核心要求如下： 1. 在线变更表模式：监控指标变动频繁，表模式必须做到自由改变，同时不对线上业务产生任何影 响； 2. 写入性能高：一般批量写数百条数据延时在数百ms 内； 3. 高扩展性：随着监控的设备和指标越来越多，写入能力和存储能力需求越来越大，写入要支持每 秒千万行监控数据，存储系统要支持数十P 数据；扩容过程用户无感知； 4. 低存储成本：监控数据一般比较多，存储成本需要重点关注，存储系统要能够在满足访问需求的 前提下尽可能的降低成本； 5. 老数据自动清理：一段时间前的数据一般不再需要，为了节约成本需要系统自动删除，方便用户； 上面列的需求是从宏观层面上理解的，是架构师和 CTO 关心的事情。而作为一个干活的程序员， 我们需要从微观层面，从动手写代码的角度再一次细化需求。扩展、成本咱就不管了，这些老大都决 定好了 （关于成本最后有个具体的示例），我们就关心如何快速的构建系统。 1. 对某个机器的某个指标，采集间隔为5 秒，每行记录约100Byte；平均写入延时低于50ms； 2. 数据保留6 个月； 3. 机器个数可以数百万，指标个数可以数千万，数据量可能过P； 4. 典型指标查询的时间范围是最近10 分钟、1 小时、24 小时，亦可自定义起始和终止时间； 5. 对大范围数据做聚合：如果查询的时间范围太大，返回数据点不可太多，否则传输和展示都是负 担； 6. 查询要求，已知机器、指标，查询某个时间范围内的指标数据； 7. 查询要求，已知机器，查询某个时间范围内的所有指标数据； 8. 查询要求，已知指标，查询某个时间范围内所有机器的该指标数据； 9. 典型的业务查询操作，延时要求低于200ms ； 通用监控架构 下面图1 描述了通用的监控系统架构图，以方便继续讲解。监控系统是一个庞大复杂的体系，网 上找了个更完善的监控架构图，见[2]。 图1 通用报警系统架构，其中数据聚合任务亦可以使用流计算工具代替，道理类似。某些情况下，数据聚合任务也可以和采集代 理合并为一个进程，简化架构。 各个模块的作用大概如下： 1. 监控指标采集代理：部署在应用服务器上收集指标的软件，一些流行的开源软件比如MySQL/Nginx 等本身就有很多第三方的监控代理；对于自己开发的系统，可以在程序中埋点，定制化代理； 2. 数据聚合任务：上面需求里面提到需要看长时间周期的数据，如果查看过去一个月的监控图，需 要将所有秒级的数据直接拿出来