专栏首页腾讯技术工程官方号的专栏计费监控优化系列:TDSQL监控优化
原创

计费监控优化系列:TDSQL监控优化

作者:吕越

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监控痛点,已能够经得住业务近期的增长和监控需求,但如何优化现有监控策略,提供更丰富的监控方法,如多指标的组合告警的策略,趋势性告警是否有效等,仍是下个阶段需要进行攻关的重点。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 微信基于时间序的海量存储扩展性与多机容灾能力提升

    ? 作者:jeryyzhang,腾讯 WXG 后台开发工程师 背景介绍 业务场景 作为以手机为主要平台的移动社交应用,微信内大部分业务生成的数据是有共性可言的...

    腾讯技术工程官方号
  • 从技术演变的角度看互联网后台架构

    ? 这是去年在部门内部做的一个面向后台开发新同学的课程,因为其他BG一些同学要求分享,所以发一下。 其实内容都是些常见开源组件的high level描述,比如...

    腾讯技术工程官方号
  • TDSQL 全时态数据库系统-理念与愿景

    ? 本文大纲: Abstract Introduction 研究动机 TDSQL整体架构 TDSQL对时态数据库的需求 T-TDSQL核心技术与系统的价值 T...

    腾讯技术工程官方号
  • 图神经网络入门(三)GAT图注意力网络

    注意机制已成功用于许多基于序列的任务,例如机器翻译,机器阅读等等。与GCN平等对待节点的所有邻居相比,注意力机制可以为每个邻居分配不同的注意力得分,从而识别出更...

    Houye
  • DDD-CQRS的落地案例

    在之前的文章DDD-CQRS能解什么问题中,阐述了什么是CQRS。但是并没有业务需求可以应用CQRS。最近需要处理一个文本增量更新的业务,经过需求分析后,尝试使...

    方丈的寺院
  • 文末福利-如何构建核心竞争力? | 25位技术大咖的通关秘籍在此

    ? 核心竞争力的概念首次出现是在1990年,将其定义为“是在组织内部经过整合了的技术、知识和技能,尤其是关于怎样协调多种生产机能和整合不同技术和技能”。概括地...

    腾讯大讲堂
  • Weex原理之带你去蹲坑

     本篇将节操满满的安利Weex(˶‾᷄ ⁻̫ ‾᷅˵),不一样的角度推荐你入坑,官网有的我们不拖泥,这里将给你补充官方没有的,深入到蹲坑给你排忧解难,总会给你点...

    恋猫
  • Weex原理之带你去蹲坑

     本篇将节操满满的安利Weex(˶‾᷄ ⁻̫ ‾᷅˵),不一样的角度推荐你入坑,官网有的我们不拖泥,这里将给你补充官方没有的,深入到蹲坑给你排忧解难,总会给你点...

    恋猫
  • Django 相关

    Web框架本质   其实所有的Web应用本质就是一个socket服务端,而用户的浏览器就是一个socket客户端。简单的socket代码如下: import s...

    新人小试
  • 什么是HDFS的纠删码

    Fayson在前面的文章中介绍过CDH6,参考《Cloudera Enterprise 6正式发布》和《如何在Redhat7.4安装CDH6.0》。CDH6主要...

    Fayson

扫码关注云+社区

领取腾讯云代金券