原文出自【听云技术博客】：http://blog.tingyun.com/web/article/detail/600

断断续续写了将近一个月，听云第一版数据库管理平台终于写完了，期间来来回回的改了好多次小毛病，现在已经部署到生产环境上去了。

在刚开始的时候，后端的数据库集群只有10多个节点组，日常的巡检工作并不会花费太多的时间和精力。随着业务的增长，在较短时间内后端集群扩展到数百节点时，这时的日常巡检如果还是人肉完成，讲道理，最终可能就是不做巡检或者是缘分巡检，哪天想起来了搞一下。显然这不是我们的风格。那么如何解放我们花在巡检上的时间和精力，我们决定写一个工具来帮我们完成巡检工作，我们要做的就是登陆上这个系统，look  and  check。 

在这个版本中实现的功能并不是很多，大都是针对目前工作中的痛点来开发的，架构也很简单，分为报表和数据收集两个部分，数据收集程序主要从两个地方收集数据，一个是线上的数据库中收集一些指标数据，一个是调用云厂商的api取DB的容量信息。 

该系统的开发语言是golang，netop是我们部门的简称，所以索性就叫NetopGO。前端页面是改的jumpserver的页面，数据搬运工真心写不动前端。

Web开发框架使用的beego。讲道理，jumpserver的前端模版真的是一款很优秀易上手的模版，beego就更不用说了，powerful、beautiful and amazing！直接上图，标清有码，嘿嘿嘿。

1、仪表盘

 这里主要是一些数据概览，各种总量、截至到当前的本月数据量变化趋势。每个业务库本月的数据容量变化情况，还有前一天慢查询数量排名top12。仪表盘上提供快速跳转的链接，只需要点击相关的数字即可。比如点击DB总数，就会跳转到DB列表的页面。

2、用户权限

 

划分三种权限：admin、dba和guest。如果当前用户的权限不足，访问受限页面会提示没有权限或页面上的部分按钮不可用。

 3、主机管理       这里主要是主机列表管理和业务组列表管理。主机列表依赖业务组列表。这部分对来宾和数据库管理员是有权限控制的，比如这个guest用户登录上来之后查看主机列表只有readonly用户的远程登录可用，其他功能受限，点击远程登陆会弹出一个webshell，如下图：       4、DB管理

DB管理是这个版本的重心，首先看DB列表 

这里有所有线上的实例，并且每个实例都有图表和慢sql的入口链接，点击图表，会跳转到图表的页面: 

图表目前只有数据量（每天统计）、QPS&TPS（每10分钟统计）和慢查询个数（每天统计）的变化曲线。监控不是这个系统的重点，目前基本上所有的生产环境监控都是另外一个平台再支撑。我希望系统能够为我展示所有实例的数据量变化趋势、qps&tps情况，当然最重要的是慢查询的详细情况。如果在列表中点击慢查询，就会跳转到慢查询列表页面，如下图： 

这个页面中会对慢sql做简单的汇总和统计，同时提供查看sql和具体执行计划的功能，比如点击查看执行计划，就会向生产环境的数据库做一个即时的执行计划分析并返回结果，这样抓到慢sql就不用打开黑窗口(xshell)登陆到后端数据库上去看执行计划，直接在前端页面就能查看。如下 

Schema列表，这个页面同样有比较大的信息量，包含了所有业务库的列表，这个列表主要是给数据查询窗口使用的，动态的增删schema列表，就相当于动态的增删数据源。同时展现了每个业务库当前的数据容量大小，非常直观。 

由于我们后端的数据库使用了分区表，分区是由存储过程自动维护的，所以我们对每个业务库后端的分区增删状态在这里做了展现，点击分钟按钮就会跳转到分区监控列表页面，能够清晰的看到哪些节点的添加分区没有成功，如果添加失败，就会显示红色的Failed字样。小时和天表也是一样的。 

平常的工作中会有很多数据查询的场景，研发和测试的同事那么多，如果所有的请求都对准dba一个人的话，也是一个头疼的问题，所以在NetopGO中开了一个查询的窗口，实现了权限划分、查询sql审计记录和自动后端识别的功能。动态增删数据源，Schema列表中添加一个数据源，在查询窗口里可以立即显示并进行查询。如果后端允许的话，dba可以做任何操作，比如 insert操作，如下 

如果后端是代理的话，即便是dba角色也只能支持查询，如下 

如果是来宾帐号，所有的数据库都只能是查询权限，如下 

如果查询成功，会跳转到结果页面，如果列很多，超出了表格的宽度，下方是会有滚动条出现的。如下 

目前，出于信息安全的考虑，并没有支持数据导出功能，不过正在考虑给dba视角添加一个结果导出功能。

在数据查询窗口中执行的sql，无论是否成功，都会被记录到审计日志里面，查看审计日志可以访问审计日志页面，如下： 

列表中会展示每条sql的执行用户、schema、状态和具体执行的sql。其他同事正在查询的时候你就看这个列表，十分有快感。

5、升级记录功能

升级记录功能并没有引入工作流，所以只是一个简单的记录，目前实现了应用升级记录、数据库升级记录和故障记录的功能，但是大家都希望不要手工录入，最好是提流程系统自己记录。这个从目前的环境来看，可能难以实现。       

不过从我自己的体验来说，这种记录方式相比之前已经有很大改善。以数据库升级记录为例，以前的升级记录是放在一个nfs共享目录下的一个excel表中，目录比较深，跟sql文件的存档目录不在一个目录下，每次记录需要翻两次n级的目录，而且如果要找之前的一个升级sql，也不太好找，因为文件比较多，所以DB升级记录功能是这样的 

在记录升级记录的时候直接把sql文件上传到服务器端的目录，然后列表中提供查看附件的入口，如下 

点击详细内容，会跳转到如下页面 

点击附件，如果是在Chrome浏览器上，会直接在一个新的窗口中显示出文本内容，如果是其他浏览器，会直接下载这个文件。附件直接在浏览器*问真的很方便。Chrome下点击附件 

这个版本实现的功能基本上就这些了，接下来打算在查询窗口的页面中支持对后端中间代理下的集群做DDL和DML的变更，中间件本身是没有办法支持这些的，所以我们实现的思路就是在查询窗口中选定schema之后，sql会被提交到代理后端所有的分片上去执行，并最终返回执行状态，从而达到验证的目的。目前我们是使用的脚本来完成，有点low。这个版本已经做了相当多的准备工作，所以实现这个功能并不会很难。目前来看NetopGO绑定了太多我们自己的业务场景，后续如果功能完善之后，会在通用性上下点功夫，做一个开源的版本出来。