大家好,我是蓝胖子，关于性能分析的视频和文章我也大大小小出了有一二十篇了，算是已经有了一个系列，之前的代码已经上传到github.com/HobbyBear/performance-analyze，接下来这段时间我将在之前内容的基础上，结合自己在公司生产上构建监控系统的经验，详细的展示如何对线上服务进行监控，内容涉及到的指标设计，软件配置，监控方案等等你都可以拿来直接复刻到你的项目里，这是一套非常适合中小企业的监控体系。
在上一节我们完成了对mysql的监控，这一节我们来讲讲如何对redis进行监控，同样的，我们需要让监控指标更好的反映业务情况，由于我们生产上的服务是部署到云环境的，常见的redis监控指标，云服务商已经提供了，所以没必要重读对其造轮子了。
我们新建立的指标是redis key维度的qps，这样在看到redis 总qps升高时，能一眼看出是哪些key造成的，并根据key定位到具体业务代码。
监控系列的代码已经上传到github
代码语言：shell复制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。
代码语言：go复制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 这个切片里保存的。
代码语言：go复制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 这个切片里，写入时只写业务前缀，像下面这样。
代码语言：go复制infra.RedisMonitor.AddMonitorKey("webapp:login")方式弊端
不过上面的方式弊端很明显，那就是需要业务方较大的改动，基本上每次定义redis key时，都需要手动添加一下到monitor keys里，侵入性比较大，不过我目前还是没有想好特别好的方法让redis比较透明的按业务范围监控key的办法，如果你有任何新的点子，欢迎留言，我们一起探讨探讨。
