计费监控优化系列: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 条评论
登录 后参与评论

相关文章

来自专栏Java技术

从分布式一致性谈到CAP理论、BASE理论!

在计算机科学领域,分布式一致性是一个相当重要且被广泛探索与论证问题,首先来看三种业务场景。

672
来自专栏云计算爱好者

云计算与虚拟化技术的关系

云计算只是概念,而不是具体技术。虚拟化是一种具体技术,指把硬件资源虚拟化,实现隔离性、可扩展性、安全性、资源可充分利用等特点的产品。但看似不相关...

1839
来自专栏Java架构师历程

优步微服务架构 – 构建和部署应用程序

从我之前的博客,你必须已经对微服务架构有了基本的了解。在本博客中,您将深入了解架构概念并使用优步案例研究来实现它们。

753
来自专栏企鹅号快讯

分布式架构的套路No.74

今天小蕉跟大伙一起聊聊分布式系统的架构的套路。在开始说套路之前,大家先思考一个问题,为什么要进行分布式架构? 大多数的开发者大多数的系统可能从来没接触过分布式系...

3579
来自专栏云计算D1net

如何借助云集群打造高性能计算

云计算一开始致力于为互动系统(systems of engagement)改善应用架构,而在高性能计算方面提供不了什么。而如今,领先的云服务提供商正在重构解决方...

2976
来自专栏织云平台团队的专栏

腾讯 SNG 监控数据的创新应用

本文将向大家分享SNG监控十年来变革背后的驱动因素和立体化的监控方案,最后给大家展示最新的智能监控的应用场景。

6.3K4
来自专栏腾讯技术工程官方号的专栏

鹅厂上万节点大规模集群的跨城自动迁移(下)

当上百P的数据,上万个节点的集群进行跨城迁移时,如何在有限的带宽下实现自动、高效、稳定地迁移?本文将跟你一一揭晓!

4082

容器时代的分布式记录(第二部分)

欢迎回到我们的系列。在第一部分中,我们谈到了微服务和容器的最近兴起。我们介绍了这种类型的体系结构引起的日志记录问题以及可能的解决方案 - 聚合。既然之前我们已经...

2008
来自专栏王小雷

Hadoop YARN学习之Hadoop框架演进历史简述

Hadoop YARN学习之Hadoop框架演进历史简述(1) 1. Hadoop在其发展的过程中经历了多个阶段: 阶段0:Ad Hoc集群时代 标志着H...

1727
来自专栏Java架构

“淘宝京东”构建流式计算卖家日志系统架构的应用实践

1477

扫码关注云+社区