随着业务的快速发展，数据库实例的数量也呈指数级增长，用户需求变的越来越多，出现的问题也随之增多。纯靠人力处理线上运维问题已不现实了，同时dba根据需要更倾向于关注核心业务数据库；但众多刚上线且发展迅速的应用会造成长尾效应，这种实例更需人为关注，但是往往会被忽略，可能会造成巨大的影响。

我们团队运维过数量众多的数据库，遇到过许多的问题，积累了很多的经验，那么如何将我们的经验最大限度共享出去呢？如何更好的去摆脱长尾效应带来的危害呢？我们决定做这个Cleverdb的产品的初衷；目的就是帮助用户可以自主查看db出现了什么问题？是什么原因导致的？如何去优化改善这个问题？将经验产品化，将dba由繁重枯燥的解答问题、排查问题中解脱出来，去做更多的事情。

Cleverdb的具体功能点

总体上来说，Cleverdb平台要具备使用者通过平台能完整详尽的了解数据库的状态指标的功能。目前，平台可以提供以下具体功能：

大盘统计概览：包括主从延迟、topo结构、机房分布、热力图等
DB画像：实例健康评分、实例问题检测、实例参数展示、容量使用等
慢查询多维度分析：Top SQL、执行计划、慢SQL时间分布、索引建议等
性能曲线展示：实例级别、机器级别
会话事务分析：未提交事务、事务锁、MDL锁、活跃会话、多维度连接数展示
实例空间分析：空间使用量预测、空间碎片分析、无用冗余索引提示

实时监控等功能，用户可以通过平台迅速找到db的性能隐患，快速排查解决问题。

Cleverdb的整体架构

数据采集

针对数据库来讲，无论是诊断问题发生原因，还是优化一个待解决问题都需要完备的监控数据来支撑，很多时候还需要去对比之前的历史数据才能分析出结果。因此构建一个完善可靠的数据监控系统就是重中之重。以下是我们的监控数据采集上报系统的架构图：

秒级监控系统smonitor部署在每一台机器上，作为client端去定期采集数据（sys status & instance status），并添加进程级别的监控。针对单机多实例部署情况时，能精细化的采集到每一台实例的具体资源使用。数据部分采集到后经过处理落到本地磁盘，并主动post到server端。这么做的目的是确保不会因为网络的抖动或者其他原因导致部分监控数据没有保留到。

Smonitor web端设计为弹性扩展，作为数据接收端，同时肩负着数据清洗、评分计算、监控报警等功能。

Smonitor scheduler定制了一些任务并主动触发smonitor web去进行计算然后回写到存储数据库中。

因监控数据种类的不同将这些清洗后或计算好的数据存进了不同类型的db，并对接大数据集群对历史数据进行大数据分析，构建机器学习框架去预测未来的某种走势。例如我们会对不同类型的应用（计算密集型、io密集型、存储型等）去自适应的调整cpu或磁盘的权重比例，并根据过去一段时间的评分数值来预测未来一段时间的评分数值，当预测评分数值明显下跌时会触发预警机制，这样可以将危险扼杀在摇篮中而不是等待发生后再去解决。

评分系统

上面说到了对db实例进行打分，我们设计了一套评分系统，根据不同的db使用场景、不同的业务类型、不同的db分级去为每一台db实例进行评分，刻画画像。将数据库的核心指标（活跃连接数、总连接数、慢查询数、innodb_rows等）以及机器的核心指标（CPU、内存、磁盘、负载等）都纳入到了评分系统中，去为数据库的健康状态进行评分，并针对刚才说的不同的db类型设置不同的分数阈值，将db的健康状态更真实更完整的呈现给用户。

用户可以通过首页的评分热力图直接观察到哪个实例的总评分低于正常阈值，点到详情页中又可以通过各个评分项的雷达图清晰的发现哪一项指标出问题导致了总评分过低，这样就可以很快很精准的定位问题，并进行解决。评分系统的架构如下图所示：

慢查询分析

对于数据库的使用者来说，他们可能更关心的是慢查询的状况，例如查询时间，发生次数，扫描行数等。慢查询整体的架构功能图如下所示：

将慢查询发到kafka中，使用sparkstreaming去对慢查询raw data进行清洗分析，对相同类别的SQL进行分组，并对统计数据进行分析，提供不同时间维度的SQL执行次数，扫描行数，执行时间等统计维度的数据。

针对慢查询，cleverdb提供查看当前的SQL执行计划。同时我们根据统计信息，提炼出了慢查询的时间分布情况，用户可以看到自己的慢查询都分布在哪些时间区间内，是0.1s-0.5s还是1s以上。并根据统计信息值提炼出Top SQL与急需优化的慢查询。

因为一个查询出现在慢查询中并不一定代表这个查询本身的效率低下，有可能是刚好处于当前实例资源较为紧张的情况下，平时很快的查询被某些critical级别的慢查询给拖累。为了方便用户定位问题，我们将这些warning级别和critical级别的慢SQL直接提炼出来展示给用户，这样也减少了用户去一个个翻阅慢查询并进行优化的时间耗费。

此外，并不一定所有的研发人员和用户对SQL的执行模式很精通，也不是所有的SQL都会走索引，我们根据经验会对SQL进行分解和改写并去探测在哪些列上添加索引会尽量减少扫描行数，并给出添加索引的优化建议，用户就可以直接根据提示添加索引。

会话分析与空间分析

一、会话分析：经常有研发同学来问我们，他们的库是不是锁了能不能帮忙看一下。因为框架原因或代码问题，数据库中经常会出现未提交的事务或者批量更新时造成的锁等待情况。Cleverdb平台提供了详尽的会话分析，用户可以查看当前db中有没有锁等待的语句，是事务锁还是表级锁还是MDL锁，还可以查看当前的长事务会话与未提交会话，并给用户kill权限，可自行kill掉需回滚的会话。

二、空间分析：用户对于空间信息的需求也很强烈，db的扩容不能像应用那样随时扩容，所以在磁盘使用空间达到报警阈值之前，需要提前准备扩容的事宜，如临近双十一临时准备扩容就很被动。平台对实例空间和实例所在物理机空间都做了详尽的分析，用户可以看到实例具体磁盘空间大小，所占当前物理机的磁盘空间比率大小，并能知道数据空间、日志空间、备份空间的大小。

另外因为频繁的插入删除会造成表空间出现大量的磁盘碎片，我们分析出了存在大量磁盘碎片的表，并提示给用户进行碎片回收可以回收多少空间，做到对空间的最大利用。

同时标记出了用户实例中未使用到的索引以及冗余索引，提示用户去将无用的索引进行删除，减少磁盘空间的占用。

最后我们赋权给用户自行回收碎片和临时清理binlog文件的功能，会有守护进程去监控回收空间的操作，避免造成因MDL锁导致实例无法提供访问的问题，也会检测binlog文件是否已备份、是否已被拉取到从库，提供给用户可以去purge的binlog，临时减轻机器的磁盘压力。

三、历史数据分析查询：刚说的大部分都是关于trouble shooting相关的使用情境，另外用户还有一大类使用情境是对于历史数据进行分析查阅，去进行性能上的优化。所以cleverdb平台也提供了详尽的历史信息曲线的查阅，例如tps/qps、innodb_rows、增删改查的次数、cpu使用率、网络使用率、io使用率、连接数和活跃连接数等历史曲线。用户可以在系统出现问题时，查看当时的数据库状态和机器性能状态，例如活跃连接数多可能是并发较高问题，磁盘io压力较大可能是写入量过大的问题等，通过对比查看能更好的分析出问题所在，并得出优化方案。

最后我们在平台里加了个小彩蛋就是dba小机器人，因为dba总会被人问各种各样类似的问题，我们将问题和答案整理出来，并对一些数据库开发规范和数据库基本的原理进行了简短的解释，用户可针对基本的问题提问机器人，减少了dba的重复回复工作。

结语

我们推出这个平台的初衷是为了减轻dba们的重复工作量，将更多的时间用到学习新技术与架构上。随着工作的深入，就愈发的偏向于更好的服务用户；更好的将我们的经验最大化；更好的帮助用户定位和解决问题；在减少用户精力投入的基础上，提供更好更完美的服务。

创作场景

数据库性能展示平台构建之路