大家好,我是蓝胖子,关于性能分析的视频和文章我也大大小小出了有一二十篇了,算是已经有了一个系列,之前的代码已经上传到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的办法,如果你有任何新的点子,欢迎留言,我们一起探讨探讨。