【升职加薪秘籍】我在服务监控方面的实践(6)-业务维度的mysql监控

!! 大家好,我是蓝胖子，关于性能分析的视频和文章我也大大小小出了有一二十篇了，算是已经有了一个系列，之前的代码已经上传到github.com/HobbyBear/performance-analyze，接下来这段时间我将在之前内容的基础上，结合自己在公司生产上构建监控系统的经验，详细的展示如何对线上服务进行监控，内容涉及到的指标设计，软件配置，监控方案等等你都可以拿来直接复刻到你的项目里，这是一套非常适合中小企业的监控体系。

在上一节我们是讲解了如何对应用服务进行监控，这一节我将会介绍如何对mysql进行监控，在传统监控mysql(对mysql整体服务质量的监控)的情况下，建立对表级别的监控，以及长事务，复杂sql的监控，并能定位到具体代码。

监控系列的代码已经上传到github

无论是前文提到的 机器监控还是应用监控，我们都提到了四大黄金指标原则，对mysql 建立监控指标，我们依然可以从这几个维度去对mysql的指标进行分析。

!! 四大黄金指标是流量，延迟，饱和度，错误数。

对于流量而言可以体现在mysql数据库操作的qps，数据库服务器进行流量大小。对于延迟，可以体现在慢查询记录上，饱和度可以用数据库的连接数，线程数，或者磁盘空间，cpu，内存等各种硬件资源来反映数据库的饱和情况。错误数则可以用，数据库访问报错信息来反应，比如连接不足，超时等错误。

由于我们是用的云数据库，上面提到的这些监控维度以及面板在云厂商那里其实都基本覆盖了，我称这些监控面板或者维度是数据库的传统监控指标。 这些指标能够反应数据库监控状况，但对于开发来讲，去进行问题排查还远远不足的，下面我讲下如果只有此类型的监控会有什么缺点以及我的解决思路。

传统监控指标痛点

在使用它们对mysql进行监控时当异常发生时，不是能很好的确定是哪部分业务导致的问题。比如，当你发现数据库的qps突然升高，但是接口qps比较低的时候，如何确定数据库qps升高的原因呢？ 这中间存在的问题在于mysql的数据监控指标和应用服务代码逻辑没有很好的关联性，我们要如何去建立这种关联系？

答案就是建立表级别的监控，你可以发现传统的监控指标都是对mysql整体服务质量进行的监控，而应用业务逻辑代码本质上是对表进行操作，如果建立了表级别的监控，就能将业务与数据库监控指标联系起来。比如按表级别建立单个表的qps，当发现数据库整体的qps升高时，可以发现这是由于哪张表引起的，进而定位到具体业务，查看代码逻辑看看是哪部分逻辑会操作这张表那么多次。

下面我们就来看看如何建立表级别的监控。

建立表级别的监控

mysql的performance schema其实已经暴露了表级别的某些监控项，不过由于某些原因我们线上并没有开启它，并且由于直接使用performance schema暴露的监控指标不能定制化，所以我将介绍一种在应用服务端埋点的方式建立表级别的qps。我们生产上是golang的应用服务，所以我会用它来举例。

用github.com/go-sql-driver/mysql 在golang中开启一个mysql连接是这样做:

sql.Open的第一个参数是驱动名，默认的驱动名是mysql，这个驱动是引入github.com/go-sql-driver/mysql时自动去创建的。

所以，我们完全可以包装默认驱动，自定义一个自己的驱动，驱动实现了open接口返回一个连接Conn的接口类型。

自定义的驱动类型在实现Open方法时，也可以自定义一个Conn连接类型，然后再实现它的查询接口，进行sql语句分析，解析表名后进行埋点统计。

完整的定义驱动代码已经上传到文章开头的github地址，总之，你需要明白，通过对默认驱动的包装，我们可以在sql执行前后做一些自定义的监控分析。我们定义了3个钩子函数，分别针对sql执行前后以及报错做了监控分析。

!! 对于sql埋点的原理更详细的讲解可以参考go database sql接口分析及sql埋点实现

在sql执行前，通过SqlMonitor.parseTable对sql语句的分析，解析出当前sql涉及的表名，以及操作类型，是insert，select，delete，还是update，并且如果sql涉及到了多张表，那么会对其打上MultiTable的标签（这在下面讲sql审计时会提到），sql执行前的钩子函数如下所示：

分析出了表名并且记录上了sql的执行时长，我们可以利用prometheus的histogram 类型的指标建立表维度的p99延迟分位数，并且能够知道表级别的qps数量，如下，我们可以在sql执行后的钩子函数里完成统计，MetricMonitor.RecordClientHandlerSeconds封装了这个逻辑。

我们可以利用这个指标在grafana上完成表级别的监控面板。

Pasted image 20230803181121.png

对于数据库还有要需要注意的地方，那就是长事务和复杂sql，慢sql的监控，往往出现上述情况时，就容易出现数据库的性能问题。现在我们来看看如何监控它们。

长事务监控

首先，来看下长事务的监控，我们可以为连接类型实现BeginTx方法，对原始driver.ConnBeginTx 事务类型进行包装，让事务携带上开始时间。

接着，在提交事务的时候，判断时间是不是超过某个8s，超过了则记录一条错误日志，并把堆栈信息也打印出来，这样方便定位是哪段逻辑产生的长事务。由于我们的错误等级的日志会被收集起来自动报警，这样就完成了长事务的实时监控报警。

sql审计

接着，我们看下sql审计如何做，mysql可以打开sql审计的配置项，不过打开后将会采集所有执行的sql语句，这样会导致sql太多，我们往往只用关心那些影响性能的sql或者让数据产生变化的sql。

代码如下，我们在sql完成执行后，通过sql的执行时长，对慢sql进行告警出来，并且对涉及到两个表的sql进行日志打印，也会对修改数据的sql语句(insert,update,delete)进行记录，这对我们排查业务数据会很有帮助。

总结

这一节我们完成了对mysql的监控，不过这个监控指标是在传统数据库监控项基础上建立的，目的是为了让监控指标更加容易反映到业务上，方便问题定位，在下一节我将会演示如何对redis进行监控，与mysql监控类似，我们也需要从业务维度思考对redis的监控。