更多技术干货请戳:听云博客

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

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

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

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

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

1、仪表盘

1.2233.jpg 

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

2、用户权限

1.2234.jpg 

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

1.2235.png 

3、主机管理

1.2236.jpg 

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

1.2237.jpg 

4、DB管理

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

1.2238.jpg 

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

1.2239.jpg 

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

1.2240.jpg 

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

1.2241.jpg 

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

1.2242.jpg 

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

1.2243.jpg

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

1.2244.jpg 

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

1.2245.jpg 

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

1.2246.jpg 

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

1.2247.jpg 

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

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

1.2248.jpg 

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

5、升级记录功能

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

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

1.2249.jpg 

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

1.2250.jpg 

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

1.2251.jpg

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

1.2252.jpg 

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

 

原文链接:http://blog.tingyun.com/web/article/detail/600

版权声明:本文为TingyunAPM原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/TingyunAPM/archive/2016/05/20/5511850.html