作者：吕越
TDSQL作为金融级数据库，目前已大量应用部署在计平内部，业务伙伴，公有云以及私有云。随着业务增长，线上单一TDSQL集群的实例数最大可到1200+ SET，近3600+ MySQL instance，当初为快速实现监控覆盖的老TDSQL监控面临挑战，运行状况急需改善；同时为提升监控的有效发现能力，引入更适合的监控方法，对TDSQL的扩大应用也具有促进意义。
为此我们从两个阶段分别着手对TDSQL监控进行整合优化，阶段一：对现有的监控逻辑进行梳理，整理解决现有痛点。阶段二：引入新的监控算法，如趋势性算法、突变算法、推理算法等。本文主要对阶段一主要工作进行介绍。
问题
现有监控主要分3部分。工作图如下：
数据采集
数据采集当前包含有多个数据源，如zk、mysql、hdfs、oss server等。数据目前为1min采集粒度，采集回来之后写入存储。数据存储鉴于减少维护成本和取得收益的均衡性，仍采用MYSQL或TDSQL。目前数据采集的主要问题为：
1、采集并发度不高。数据量大时，部分数据源数据串行拉取，采集不过来，导致曲线掉点毛刺；
2、采集会有多个数据源和多个数据流向，相互之间会有影响。如入库监控存储和外部存储时，为同一线程,监控线程入库失败或延时，导致外部存储也掉点毛刺；
3、采集同多个数据源和存储之间链接多为短链接，无法复用性能不高；
4、数据入库io频度高，导致入库慢。
数据存储
数据存储面临的问题，更为迫切，由于是1min粒度，且业务增长块，采集的指标1min 有30W + 指标入库，老的表结构设计不满足现有监控存储的要求。主要面临问题如下：
1、存储占用空间大，有冗余字段。集群平均天20G+的存储消耗，目前容量下最大存储时长只能到1个月，即700G+。
2、数据查询慢。由于是月表设计量大索引大数据曲线展示时耗长，分析查询数据也受到影响。
3、不便管理。数据只能整月删除，或者按时间删除时需要扫描全表，影响监控。
分析&告警
分析告警也为1min 周期进行分析，拉取监控的数据，根据响应的监控策略进行分析，产生告警并发送。在现阶段分析告警机制相对简单，主要依赖采集和存储稳定性，避免误告。
解决
针对以上问题，我们针对向的对采集进行了重写，对存储进行了重新设计，对分析&告警也配合存储做了重写。具体方案如下：
采集优化
在采集优化上主要着重解决已存在的问题，如并发能力，持久化链接，入库瓶颈等。
1、提高并发度，将并发能力由之前实例级(实例数据拉取会有多次io串行拉取)，分解到io级别，提高并行能力；
2、多个数据源独立线程和任务。减少数据源及数据入库之间的相互干扰；
3、数据源和数据入库采用队列形式，并独立队列，避免相互影响；
4、数据入库优化为批量入库，减少io频率；
5、数据索引进行cache，减少io查询(索引部分见存储优化部分解释)；
6、连接复用。尤其是zk、http、mysql的链接复用。
优化效果如下，有效解决了数据采集掉点，曲线毛刺，以及CPU消耗高问题，新老对比如下图。
1、掉点优化新老对比
2、掉点优化后
3、曲线毛刺新老对比
4、毛刺优化后
5、CPU优化新老对比
6、优化后新采集
存储优化
为解决现存问题，在存储上我们也进行重新设计。鉴于维护成本，以及对相关TSDB的比较，我们仍选用TDSQL或MYSQL作为存储方案，并进行插件化替换，目前使用TDSQL GroupSharding的二级分区版本，分区规则为Hash+按日期分区。考虑到后续监控算法引入，会增加对数据查询压力。相关tsdb中主要比较了influxdb和opentsdb。influxdb写入性能优良，也足够的轻量，且有一定的高可用，但查询性能有瓶颈，opentsdb较重量，维护成本高。沿用TDSQL或MYSQL作为解决方案，我们主要做了如下优化：
1、引入索引表。将冗余字段进行了剥离，减少存储消耗；
2、时间序列分钟级转到小时级的60列。时序数据为相同的指标在不同时间的取值序列。这种方式一方面可以减少数据量，减少索引量，另一方面也可以减少存储消耗；
3、动态和静态指标分离。采集的指标并非所有均需要监控，降需要监控数据做历史存储，静态指标，存储当前值即可；
4、对历史数据表进行分区，表压缩；
5、历史数据按天分表方便进行滚动。
优化效果如下，节省空间近95%。
总结
现阶段主要是解决现网监控存在的问题，即在存储和性能上进行了改良，缓解了网TDSQL监控痛点，已能够经得住业务近期的增长和监控需求，但如何优化现有监控策略，提供更丰富的监控方法，如多指标的组合告警的策略，趋势性告警是否有效等，仍是下个阶段需要进行攻关的重点。
