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

服务监控实践完整系列:

【升职加薪秘籍】我在服务监控方面的实践(1)-监控蓝图

【升职加薪秘籍】我在服务监控方面的实践(2)-监控组件配置

【升职加薪秘籍】我在服务监控方面的实践(3)-机器监控

【升职加薪秘籍】我在服务监控方面的实践(4)-日志监控

【升职加薪秘籍】我在服务监控方面的实践(5)-应用监控

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

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

【升职加薪秘籍】我在服务监控方面的实践(8)-elasticsearch 性能监控与分析手段

【升职加薪秘籍】我在服务监控方面的实践(9)-报警设计

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

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

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

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

github.com/HobbyBear/easymonitor

按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。

func (r *redisMonitor) AddRedisHook(client *redis.Client, redisInstanceName string) {  
   client.WrapProcess(func(oldProcess func(cmd redis.Cmder) error) func(cmd redis.Cmder) error {  
      return func(cmd redis.Cmder) error {  
         start := time.Now()  
         dealKey, match := matchKey(truncateKey(100, strings.TrimSuffix(strings.TrimLeft(fmt.Sprintf("%v", cmd.Args()), "["), "]")))  
         if match {  
            // 记录redis前缀key的访问次数
            RecordClientCount(TypeRedis, cmd.Name(), dealKey, redisInstanceName)  
         }  
         err := oldProcess(cmd)  
         cacheWrapper(cmd, start, err, redisInstanceName)  
         return err  
      }  
   })  
  
}

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

var (  
   monitorKeys = make([]string, 0, 100)  
)


func matchKey(key string) (string, bool) {  
   var (  
      matchKey string  
   )  
   for _, k := range monitorKeys {  
      if strings.Contains(key, k) {  
         matchKey = k  
         break  
      }  
   }  
   if len(matchKey) == 0 {  
      return "", false  
   }  
   return getCmdFromKey(key) + " " + matchKey, true  
}

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

infra.RedisMonitor.AddMonitorKey("webapp:login")

方式弊端

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