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

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

在上一节我们完成了对mysql的监控，这一节我们来讲讲如何对redis进行监控，同样的，我们需要让监控指标更好的反映业务情况，由于我们生产上的服务是部署到云环境的，常见的redis监控指标，云服务商已经提供了，所以没必要重读对其造轮子了。

我们新建立的指标是redis key维度的qps，这样在看到redis 总qps升高时，能一眼看出是哪些key造成的，并根据key定位到具体业务代码。

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

按key维度建立redis监控

要想让redis的监控指标能更好反映业务情况，那就只有按key维度建立监控指标，这样能知道是哪部分业务访问redis最频繁。

想想我们通常使用redis时，建立key的规范，是不是一般都是  服务名:业务名:业务key  这种形式，其中业务key可以是uid，也可以是其他类型id，如果按完整的key建立redis的qps监控，将会导致key维度过多，影响prometheus聚合性能，并且由于key维度过于分散，不好定位到具体业务，所以我们需要在记录指标时，需要将业务key去掉进行记录。比如对key webapp:login:uid1  和 webapp:login:uid2  的操作都将记为webapp:login 对redis的操作，这样便能很好的反映业务访问redis的情况。

下面，我们来看看如何实现这段逻辑。

实现方式

我们的项目用的是go-redis这个库，它提供了一个WrapProcess函数可以在命令执行前后添加一些自定义的操作。如下所示，我在命令执行前记录了对应key的访问次数。其中matchkey则是将应用程序的key排除掉业务key获得最终的只携带业务名的redis key。

matchKey  的实现逻辑是看应用服务传来的redis key是不是在监控的key范围内，是的话，才会对key访问次数进行监控，所有需要监控的key都是monitorKeys 这个切片里保存的。

应用服务会将它需要监控的key写入到monitorKeys 这个切片里，写入时只写业务前缀，像下面这样。

方式弊端

不过上面的方式弊端很明显，那就是需要业务方较大的改动，基本上每次定义redis  key时，都需要手动添加一下到monitor keys里，侵入性比较大，不过我目前还是没有想好特别好的方法让redis比较透明的按业务范围监控key的办法，如果你有任何新的点子，欢迎留言，我们一起探讨探讨。